Subject: RE: [Simple] Sessions of MESSAGEs

From: "Avshalom Houri" <[email-masked]>
Date: Thu, 6 Sep 2001 16:16:54 +0200

I think that you touch the point of difference in this long thread, what is
SIMPLE? Is it only an extension of SIP for IMPP which should support IMPP
with the minimal contradictions to SIP nature or should it be a protocol
that can support IMPP but in a way that is convenient to deploy and
requires less servers and other elements for scalability.

I also do not understand why a media of non-session MESSAGE is allowed on
the control connection while the media of MESSAGEs in a session are
prohibited. If MESSAGE is a media then go all the way. If not or a one-time
MESSAGE was allowed since there was no other choice I do not see the harm
in session of MESSAGEs.

avshalom
Sametime/Lotus/IBM

                    "Sean Olson
                    (EUS)"                 To:     "'Avshalom Houri'"
<[email-masked]>,
                    <sean.olson@eri        [email-masked]
                    csson.com>             cc:
                                           Subject:     RE: [Simple]
Sessions of MESSAGEs
                    05/09/2001
                    18:33

>I agree with Robert. Given the experience we had in implementing and
>deploying Sametime the concerns about firewalls are more then valid.
>
>I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE,
>given the detail/schema option and the human readable comment.
>We differ
>between NOTIFY and MESSAGE in that we allow a session of
>NOTIFYs (created by
>SUBSCRIBE) to be transferred over the same the control
>transport and not a
>session of MESSAGEs (created by INVITE).

Well, the NOTIFY is different than the INVITE
case. For the INVITE case, the MESSAGE is the media.
This is different from the NOTIFY case where the NOTIFY
is signalling.

>
>I think that we should define that the MESSAGE can be sent on
>the control
>transport as NOTIFY even when there is a session. We should
>also limit the
>size of the MESSAGE that can be sent and enable partial
>NOTIFYs as discussed
>in a separate tread.

Several comments on this:

1) The size of the MESSAGE should be as flexible as
   it is for any SIP Request. No special cases please.

2) The MESSAGE *can* be sent on the control transport.
   If you send a MESSAGE that has the same call leg
   information as a previously established call leg,
   then by default the MESSAGE will be routed on the same
   control transport (according to the Contact:/Record-Route:
   headers). Nothing special needed here. This is an
   alternative to the MESSAGE as media idea. Nest the
   messages within an INVITE or SUBSCRIBE session.

3) On the subject of partial NOTIFYs, what about a
   Last-Modified: header coupled with a "digest"
   sub-package? You could do a one-shot subscribe to
   the "digest" sub-package and receive a complete
   state update. Then subscribe to the base package
   and receive deltas.

>avshalom
>Sametime/Lotus/IBM

Sean Olson
Ericsson Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Sep 2001 10:51:13 -0400

I am reserving judgement on the basic point of this thread - whether it
is a good or bad thing to permit an IM session to be transported as a
series of SIP MESSAGEs. 

But I would like to propose some basic groundrules that any proposed
mechanism for IM sessions must follow:

-  An IM session must be initiated with a SIP INVITE transaction,
   using an SDP media description to request the IM session.

-  Like any other media session within a SIP call, it must be
   possible to add, drop, or redirect an IM session to a new
   destination through use of reINVITE, by exchanging revised SDP.

I am trying to avoid a solution where IM is treated differently than
other media, preventing reasonable management of multimedia calls. When
I receive an INVITE, I should have the opportunity to accept or refuse
any or all of the offered media by way of the SDP I return.

If a proposal doesn't meet these groundrules, then I don't believe it
belongs as a part of SIP. If it does, then of course it still must meet
all the other concerns that have been raised in this thread. These
groundrules are not a showstopper for using sessions of MESSAGEs -
Jonathon at one point floated a proposal for m=message that would
probably be adequate.

	Paul Kyzivat
	Cisco Systems