Subject: RE: [Simple] IM over the signaling connection

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Oct 2001 21:13:55 -0400

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 7:29 PM
> To: [email-masked]
> Cc: Jonathan Rosenberg; [email-masked]; Ben Campbell; 'Rosen,
> Brian'; Henning Schulzrinne; 'Christian Huitema'; Peterson, Jon; Roy,
> Radhika R, ALCTA; [email-masked];
> [email-masked]; Vasilis Polychronidis
> Subject: Re: [Simple] IM over the signaling connection
> 
> 
> In addition to <Message-ID> and <Thread-ID>, it would be 
> useful to have
> an <In-Reply-To> header, so that proper message ordering can be
> achieved. In theory the <In-Reply-To> is sufficient to define 
> a thread,
> but in practice it probably isn't, so having both is useful.

SIP actually has an In-Reply-To, which lists the call-id of the message that
this request is "replying" to. Effectively, this means that the call-id acts
as our message ID in the paging model. Based on the sip definition, call-id
is globally unqiue for each request outside of a call-leg. Since paging mode
doesn't set up a leg, this has the desired property.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Oct 2001 22:49:15 -0400

One thing I do want to note.... I think that whatever we do for thread IDs,
in-reply-to's or whatever should not hold up the basic paging model. All of
those things are primarily needed to facilitate integration with a session
model, and therefore we should worry about those things later. Lets get the
basic paging model done. 

-Jonathan R.

---

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 8:53 PM
> To: Paul Kyzivat
> Cc: [email-masked]; Ben Campbell; 'Rosen, Brian'; Henning
> Schulzrinne; 'Christian Huitema'; Jonathan Rosenberg; Peterson, Jon;
> Roy, Radhika R, ALCTA; [email-masked];
> Paul -
> not having the Session-ID and only relaying on the <In-Reply-To> has
> some increased statfullness requirements on proxies - and again, my
> original
> point that while we --hope-- many IM sessions will be end2end, in
> reality many inter-domain IM sessions will traverse some DMZ
> IM or SIP proxy that will provide authentication and authorization -
> domain policy ("this user is blacklisted", "translate between 
> English and
> French")
> should be done when entering the network, not by the UA.
> 
> And of course if the proxy is no longer needed it can replace 
> the u2p2u
> session
> with an u2u one - another advantage of using standard SIP setup for IM
> sessions.
> 
> Also - I believe messages, regardless if sent using pages or 
> in sessions,
> should be associated with a "thread-of-messages ID" - this 
> makes for a much
> cleaner design - not needed in every case mind you, but in many
> person2person
> scenarios.  Also this provides a stateless way for both UAs 
> and Proxies
> to continue past sessions - just choosing some arbitrary time 
> for a session
> to expire -because the transport closed- or -some timer fired- is less
> then optimal.  I may, as a user, as I do many times, continue a
> conversation
> I finished last night - and it should contextually be the 
> same "thread" -
> while clearly the transport will be replaced and a new 
> session created.
> 
> so while I am not objecting to an additional optional 
> <in-reply-to> header,
> I dont think it replaced <Thread-ID>.
> 
> - gur
> 
> > Paul Kyzivat Wrote:
> >
> > achieved. In theory the <In-Reply-To> is sufficient to 
> define a thread,
> > On the other hand, having <Thread-ID> might encourage abuse 
> of paging
> > mode by providing another way to implement sessions. Just having
> > <Message-ID> and <In-Reply-To> would be sufficient to tie a 
> new session
> > to a preceding page mode message.
> >
> >
> >> [email-masked] wrote:
> >>
> >> Providing messages with two optional headers: <Message-ID> and
> <Thread-ID>
> >> allows the sender to choose to
> >>
> >> (1) provide message identification for later processing 
> (if this is not
> >> clear then imagine some message indexing at the server to 
> allow message
> >> access by non-SIP elements, like web-browsers via an App 
> Server, WAP
> etc)
> >>
> >> and
> >>
> >> (2) to associate a specific message with a 
> thread-of-messages - this way
> >> if a message arrives using page mode, and a later session 
> is established
> >> and a new message arrives with the same Thread-ID, the UA 
> knows it is
> part
> >> of the same session - this also allows muxing multiple 
> threads within a
> >> session without any transport muxing.
> >>
> >> (of course both IDs are generated by the originating UA, 
> the two headers
> >> should
> >> be optional - many apps do not need them).
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2001 16:53:56 -0500

If we had those headers, would you expect them to be in SIP headers or 
in the meta-data of message/cpim? It seems to me the second makes more 
sense, as this is information that may need to be delivered end-to-end 
across a CPIM boundery.

[email-masked] wrote:

> Jonathan -
> 
> I agree we should not hold up the basic page mode - but I feel the ability
> to associate MESSAGEs with a "thread of MESSAGES" is needed regardless if
> it in a page or in an INVITE-established session - again I am not asking
> for
> anything mandatory - but I do feel unique optional <Message-ID> and
> <Thread-ID>
> headers should be in the draft now.
> 
> I think the use of these optional headers (+In-Reply-To) is obvious, and
> documenting them should not be controversial - but I have been wrong
> before...
> 
> at the same time, I have not heard an objection yet to their inclusion.
> 
> - gur
> 
> 
>>>-Jonathan R. Wrote:
>>>
>>>One thing I do want to note.... I think that whatever we do for thread
>>>
> IDs,
> 
>>>in-reply-to's or whatever should not hold up the basic paging model. All
>>>
> of
> 
>>>those things are primarily needed to facilitate integration with a
>>>
> session
> 
>>>model, and therefore we should worry about those things later. Lets get
>>>
> the
> 
>>>basic paging model done.
>>>
> 
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2001 17:09:48 -0500

I think I should have said "series" of messages, rather than "stream" of 
messages, because I think I conveyed the wrong idea. The current draft 
assumes a one to one correspondence between MESSAGE requests and IMs. It 
does mention that if you want to send something larger than the maximum 
UDP size, you should use TCP.

If we are talking about MESSAGE as a file transfer protocol, I think 
this would be better modeled using an INVITE initiated file transfer 
session of some sort.

Michael Hammer wrote:

> Ben,
> 
> Whether a message appears as a single IM or a stream of IM right now 
> appears to be more of an implementation detail, absent a maximum IM 
> size.  (Did I miss that definition?) Given that an application may send 
> a 1 Mbyte message as:
> 
> 1) one 1 M IM,
> 2) two 512 K IMs,
> 3) four 256 K IMs,
> ...
> n-2) 256 4 K IMs
> n-1) 512 2 K IMs
> n) 1024 1K IMs
> 
> Does IM size count at all or just message and response counts?
> Do we care that SIP may need to segment to some max message size, say 
> 1500 bytes?
> Do we care that a lower layer may need to segment the message prior to 
> transmission?
> Do we care if the IP layer has to fragment during transmission?
> Are there some unstated assumptions in your calculation?
> 
> Mike
> 
> 
> At 02:39 PM 10/9/2001 -0500, Ben Campbell wrote:
> 
>> I agree with Christian here--I really want to discourage session mode 
>> unless one expects a stream of messages. One shot text messages should 
>> normally be page mode.
>>
>> Christian Huitema wrote:
>>
>>> Note that my point was not to ignore the lessons of the past, but to 
>>> point out that widely deployed systems such as SMS are not going to 
>>> disappear in a day, or in a year -- they are with us for at least one 
>>> or two upgrade cycles, i.e. at least 4 to 6 years.
>>>
>>> Also note that if the usage is actually a page, then a "message" is 
>>> less taxing on the infrastructure than an "invite" + the necessary 
>>> session clean-up. Let's compare:
>>>
>>> 1) Message: one signalling message + one response per IM.
>>>
>>> 2) Session: INVITE + response; ACK; BYE+response; + additional cost 
>>> of setting the message channel; IM messages on channel.
>>>
>>>  From a pure signalling point of view, the session mode is only 
>>> beneficial when there are at least 3 IM exchanged in a session.
>>>
>>> -- Christian Huitema
>>>
>>> *From:* Roy, Radhika R, ALCTA [mailto:[email-masked]]
>>> *Sent:* Tuesday, October 09, 2001 6:23 AM
>>> *To:* Vasilis Polychronidis; Christian Huitema
>>> *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; 
>>> Peterson, Jon; [email-masked]; [email-masked]
>>> *Subject:* RE: [Simple] IM over the signaling connection
>>>     Hi, Vasilis:
>>>
>>>     Good that you have reminded the very important lesson from the past.
>>>
>>>     Would please let us know your opinion what do we do in the case of
>>>     "Paging" in SIP?
>>>
>>>     Of course, we have another scheme: MESSAGE as session.
>>>
>>>     Radhika
>>>         *From:* Vasilis Polychronidis
>>>         [mailto:[email-masked]]
>>>         *Sent:* Monday, October 08, 2001 4:43 PM
>>>         *To:* Christian Huitema
>>>         *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
>>>         Peterson, Jon; [email-masked]; 
>>>         *Subject:* Re: [Simple] IM over the signaling connection
>>>         Christian Huitema wrote:
>>>             There are two points that I keep in mind in this debate:
>>>             1) SMS, the messaging service of cell phones, uses the page
>>>             mode and is
>>>             carried at least in part over the signaling channel.
>>>         Correct. However Operators realized that SMS was the wrong (was
>>>         very successful financially) technical solution for messaging.
>>>         Remind you that when the people designed (late 80s) SMS they did
>>>         not have any idea of how successful commercial service will be.
>>>         That is why the next generation of multimedia messaging is using
>>>         HTTP as the transport.
>>>         I understand that this is a difficult point to understand with
>>>         some people in the list.
>>>         Let me remind you that the telephony people with more than
>>>         hundred years of experience realized in the late seventies that
>>>         in order to scale and have very reliable networks you had to
>>>         separate signaling from transport (initially signaling was mixed
>>>         with transport -
>>>         that is the current case for all the analog lines going from
>>>         home to the local switch --> DTMF) and they created SS7 and 
>>> ISUP.
>>>         Actually people invented SIP using ISUP as their guide.
>>>         That was one of the initial arguments of SIP: separate proxies
>>>         from transport of user data.
>>>         It seems to me that certain people want to regress in time and
>>>         mix signaling and user data.
>>>         Let us please learn from the history and lets try not to repeat
>>>         the same mistakes.
>>>
>>>             2) CPIM's Message function looks a lot like the page mode.
>>>             It seems that the first step forward is to recognize this
>>>             and assume
>>>             that we will indeed use "MESSAGE over SIP" in the page mode
>>>             for a
>>>             significant fraction of our exchanges. I suggest that the
>>>             first order
>>>             action of SIMPLE is to just nail this one, so it be 
>>> behind us.
>>>             The page mode has well known limitations: it creates a lot
>>>             of overhead
>>>             in long sessions, and it does not extend easily to 
>>> multi-party
>>>             operation. This is the rationale for the "IM session"
>>>             extensions, i.e.
>>>             IM after INVITE. However, whatever we do in the session
>>>             mode, we will
>>>             have to go on interworking with SMS and with CPIM; this
>>>             means that we
>>>             will have to bring in the session some members who can only
>>>             use the page
>>>             mode. Obviously, a "session of messages" makes this very 
>>> easy.
>>>             -- Christian Huitema

---

From: [email-masked]
Date: Thu, 25 Oct 2001 01:47:17 +0200

>> Ben Campbell Wrote:

out of the two choices It does makes more sense to put it into the
individual
cpim header - with multipart mime I could see multiple messages in one
MESSAGE body
(think forwarding/aggregating proxy).

>> Ben Campbell Wrote:

>> this would be better modeled using an INVITE initiated file transfer

There is no problem limiting the size of IMs to some very small size-
the usual solution when needing to send large amounts of data is to send
"by reference" - e.g. send a URL to the file you want the other side to
get,
instead of the file itself.  I see no problem with limiting sizes of IMs to
under
512 bytes, allowing both UDP and TCP to be used.

remember that on the largest IM system in the world (GSM-SMS) the maximum
size
is 160 chars - I dont think we are here to solve file/image/XYZ transfer
problems,
if you want to send anything that is not an IM (and the definition is
clear) -
INVITE to a specific-media session or MESSAGE a URL of where the resource
can be found.

(http://www1.ics.uci.edu/pub/ietf/uri/draft-antti-gsm-sms-url-04.txt)

- gur