Subject: Re: [Simple] IM transport

From: [email-masked]
Date: Wed, 3 Oct 2001 22:24:59 +0200

I wish we could forget about this but what about the IESG requirement sent
by Jon Paterson at 20 August 2001:

<<<
The IESG has some concerns that this mechanism constitutes the use of SIP
as a transport protocol. In other words, once the session has been
established
between the two endpoints by the INVITE, if the MESSAGEs can only go
directly end-to-end, then their headers and related protocol apparatus are
entirely superfluous and may do more harm than good. We saw during the
meeting last week that there were definitely some pitfalls to allowing
methods other than MESSAGE across the IM stream (as well as questions about
overlapping transactions, redirection, forking, and so forth), and it isn't
clear that the overhead is justified if MESSAGE is just an envelope for its
encapsulated MIME payload. The IESG was particularly concerned, in addition
to the protocol overhead, with congestion characteristics of the messaging
session and with the precedent that could be set by using SIP in this
fashion.

I am not sure what will be considered as superfluous headers.

avshalom
Sametime/Lotus/IBM

                    "Henning G. Schulzrinne"                                                                                    
                    <[email-masked]>             To:     Anders Kristensen <[email-masked]>                   
                    Sent by:                          cc:     "Petri K. Koskelainen" <[email-masked]>,                  
                    [email-masked]        [email-masked]                                            
                    icsoft.com                        Subject:     Re: [Simple] IM transport                                    

                    03/10/2001 21:51                                                                                            

Anders Kristensen wrote:
>
> Fair enough. Yours and Hennings points are well taken. Still, adding
> sender identification is a far cry from full fledged SIP. Presumably
> there's no need to send responses, to add Vias, to have CSeqs, to do
> routing, loop detection, retransmissions etc. etc.  If all that stuff
> goes we're arguably not even talking about SIP any longer.
>

As long as it's a valid SIP message, even a subset, you can re-use
existing parsers and existing specifications. This also makes message
relaying from UDP (paging mode) to TCP much easier.

Thus, while I wouldn't want to require that the MESSAGE-on-TCP has full
SIP headers, it should be permissible to stick a full page-mode MESSAGE
into TCP without the receiver losing its lunch.
--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 3 Oct 2001 18:41:40 -0500

A note about the 'MESSAGEs may traverse proxies so you probably need Vias
etc.' comment below.

I don't think the consenus to use INVITEs to establish sessions entails a
requirement that the session transport protocol used for the conveyence of
IMs can or should be sent through SIP proxy servers (and moreover that SIP
proxy servers would need to access headers to route IMs). 

Some time ago Jonathan sent out a list of requirements for this transport
protocol:

http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000583.html

I would suggest that we revisit these criteria to make sure this is what
we're looking for (I recall that conferencing was added as a requirement to
this list) and then attempt to find a protocol that satisfies these
requirements.

Initially I see no reason why all of the apparatus of SIP headers, much of
which is used for message routing, should be necessary in the transport
protocol. If we really need SIP proxies to route IMs, we should be sending
them in paging mode. The point of having an alternative to paging mode was,
as I understood it, precisely to enjoy the benefits of -not- sending IMs
through proxy servers.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

-----Original Message-----
From: Petri K. Koskelainen [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 12:46 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Simple] IM transport

> goes we're arguably not even talking about SIP any longer.

Hmm, we need responses (with the server) and retransmissions.
Having reliable TCP does not mean that we can forget application
level responses.
Also, MESSAGEs may traverse proxies so you probably
need Vias etc.

Basically, it is still a standard SIP transaction
even if it has been established with INVITE.

--
Petri

---

From: [email-masked]
Date: Wed, 3 Oct 2001 15:35:48 -0500

Anders wrote:

>> Umm, no. If the IM session has already been negotiated through an INVITE
>> there's no need to resend From and To in each MESSAGE. Seems to me that
>> only the ability to transport MIME bodies is really needed -- basically
>> MIME with the Content-* headers.

well for multi-person sessions via a Proxies you will need at least the
<From>
unless you base user-recognition on network layer information which is not
a
good idea.

I would recommend that we keep the MESSAGE-over-TCP stream as close as
possible
to MESSAGE-over-SIP, its the same software handling both after all.

- gur

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Thu, 4 Oct 2001 12:07:09 -0400

Hi, Paul:

My comments are provided below [RRR].

Best regards,
Radhika

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 11:48 AM
To: Roy, Radhika R, ALCTA
.
> ....
> 
> e2e acknowledgement can provide this if the conference server manages
> the acknowledgements properly. This could be a policy in the server. A
> different (store and forward) policy would ack before distributing when
> e2e is not important.
> 
> [RRR] If "message" is sent as "media" on e2e after establishing the
session,
> does the Ack not to be taken care of by the transport protocol itself
(e.g.,
> TCP)? (For signaling part, SIP's ACK is already taken care-of, I guess.)
Am
> I missing something?

Depends on what you mean by ACK and e2e.

When sip messages are sent over tcp explicit acks are still sent back.
When MESSAGEs are sent over sip in paging mode there is an explicit 200
OK. 

[RRR] Here, MESSAGE (in paging mode) is considered, as if, as a part of SIP
signaling messages.

A similar sort of explicit acknowledgement can be part of session
mode IM if we choose to make it so.

[RRR] It is also taken care-of when the session is established using usual
SIP signaling messages.

If this is done, then the definition of e2e becomes important. In a two
party session this may be fairly obvious. But if you establish a
conference using a conference mixer for the IM, there may be several
session legs. Then e2e may be defined to cover only a single leg, or it
may be defined to include all legs. It is up to the conference mixer to
decide this. If we have explicit acknowledgement of each message, then
the conference mixer can choose to do the acknowledgement either way.

[RRR] We probably do not need to take any extra precaution because SIP
signaling messages are good enough for this purpose as well. For example,
the draft (draft-khartabil-sip-conferencing-00.txt) shows how MESSAGE
conferencing can be established and, it appears that we do not need to do
anything extra.