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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 4 Oct 2001 16:11:23 -0500

Just to be clear about this, I don't think the IESG has expressed disfavor
with the paging model (i.e. sending MESSAGEs outside the context of a
session over the traditional SIP signaling stream). I believe they have
objected to the creation of an explicit session which then uses SIP MESSAGE
as a transport mechanism. I think there is a clear difference between these
alternatives; however, that difference has been obscured by some of the
hybrid architectures that have been proposed on this list.

Initially, there was the concept of paging (which operated over the
signaling network) and chat (which went directly end-to-end). I think there
was a clear consensus to allow the paging model, and a great deal of
subsequent discussion about the form that the chat model should take.

In the midst of this discussion, firewall/NAT traversal and middlebox
concerns were raised, pointing out correctly that chat would not always be
end-to-end. I think that a great deal of confusion has arisen from the
notion that a 'proxy,' either in the sense of a SIP proxy or in the sense of
a middlebox or stun server or some conflation of these roles, would act as
an intermediary in chat sessions, modifying and/or re-routing IMs. This has
led to an argument for sending SIP MESSAGEs in IM sessions in order to use
their routing headers (like Vias) to navigate network intermediaries.

Frankly, it has never really been clear to my why, if network conditions
adverse to the creation of a chat session exist, an IM client can't just
default to the paging method. If the performance requirements of the network
make paging infeasible, then something like a stun server could be
introduced with minimal, if any, impacts to the construction of SIMPLE
messages. Either way, I haven't yet understood the justification for some
sort of hybrid chat-of-MESSAGEs-through-proxies session.

So if there is a need to keep the sort of information you might have found
in MESSAGE headers in chat-based IMs, I would argue it should only be for
session correlation, sequencing and so forth, rather than routing. Perhaps
all of the information we need here is available (or should be available) in
the message/cpim MIME type.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 1:19 PM
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [Simple] IM over the signaling connection

We have got the following wording:

<<<
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 if the IESG objects to the use of SIP as transport due to:
1. The signalling connection is for signalling only and not for any media.
2. The overhead it will cause to the protocol.
3. The superfluos headers.

If it is 1, then why a single MESSAGE is allowed? if it 2 or 3, then we can
limit the usage when the
session is held over the signaling connection.

avshalom
Sametime/Lotus/IBM

                    Ben Campbell

                    <bcampbell@dynami        To:     [email-masked]

                    csoft.com>               cc:
[email-masked]                                    
                                             Subject:     Re: [Simple] IM
over the signaling connection                
                    04/10/2001 17:28

It is not so much that it is being ignored as that the IESG has told us
they will not approve it.

[email-masked] wrote:

> It seems that the possibility of sending MESSAGEs of sessions over the
> signaling connection is being ignored.
> I am not sure that there is a consensus not to use it.
>
> It think that we can agree on sending MESSAGEs of sessions on the control
> connection. We should keep the
> header of the MESSAGEs to a necessary minimum and agree on a maximum
length
> of MESSAGEs to be sent
> on the signaling connection. Given this, the impact on the control
> connection will not be different from a one time
> MESSAGE and NOTIFYs.
>
> avshalom
> Sametime/Lotus/IBM
>
>
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Oct 2001 13:10:43 +0900

> objected to the creation of an explicit session which then uses SIP MESSAGE

My understanding was that the problem was the use of a non-congestion
controlled delivery mechanism for delivering data of unknown rate and
packet size.

> sort of hybrid chat-of-MESSAGEs-through-proxies session.

If you mean chat-of-MESSAGE-through-SIP-proxies, I agree. If there's a
problem getting direct connectivity, this is a problem for all TCP (and
presumably even more so, UDP-based media). One of the strengths of the
SIP model is the idea that I can transition from a pure MESSAGE chat to
something else, e.g., adding voice. It is very confusing if MESSAGE
works, but then there's no way to set up additional media, some of the
time.

> the message/cpim MIME type.

The argument for using a SIP MESSAGE format in a session (NOT routed via
proxies) is at least two-fold:

- any implementation already has the SIP parser (and maybe the
compression engine, if needed);

- bridging between page mode and session-mode is very easy (e.g., at a
conference server), without loss of information.  I suspect that this
will be much more common than CPIM, even though this is probably
politically incorrect to say. If you don't have this, you lose
information, as some non-standard headers (or even standard SIP headers,
such as the various *-Info thingies) won't be translatable into CPIM.

A third concern, which may be a non-issue, is whether CPIM is
sufficiently well-specified at this point to actually write parsers.

If you ignore political correctness, what is the advantage of using the
CPIM format? Is it only the extra header overhead and how big,
percentage-wise, would this be? Maybe we should draw up the minimum SIP
MESSAGE format and the corresponding CPIM version to get a better feel
for the trade-offs.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 05 Oct 2001 09:28:34 -0500

[snip]

> sufficiently well-specified at this point to actually write parsers.

It better be, as it is a must-implement feature for a SIMPLE IM end-point.

> MESSAGE format and the corresponding CPIM version to get a better feel

Considering that the SIP MESSAGE message is likely to carry a 
message/cpim body, then it is by definition larger.