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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 5 Oct 2001 03:25:56 -0500

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, October 04, 2001 9:11 PM
> To: Peterson, Jon
> Cc: [email-masked]'; Ben Campbell; 
> [email-masked]
> Subject: Re: [Simple] IM over the signaling connection
> 
> 
> 
> 
> "Peterson, Jon" wrote:
> > 
> > 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
> 
> 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.
> 
>

I think that's only part of it. I hesitate to put words in the IESG's mouth,
but in addition to this issue the transport ADs were also concerned about
the presence of unnecessary headers (just inefficient protocol design) and
as well about the overall precedent set by the use of SIP as a transport
protocol. I think the specter of foo-over-HTTP lampooned in a recent April
fool's RFC (co-authored by one of the transport ADs) suggests something of
the perceived dangers of this sort of precedent. For those that haven't seen
it:

http://www.ietf.org/rfc/rfc3093.txt

Hybrid paging/chat arguments that suggest the use of the MESSAGE method as
transport to aid in firewall traversal are in some respects reminiscent of
the thrust of that document. Once SIP MESSAGEs can be used as transport to
allow IMs to cross network intermediaries, possibly other sorts of
applications could be piggybacked on SIP MESSAGE or INFO methods, and so on.
I believe the IESG doesn't want this sort of law on the books.

Jon Peterson
NeuStar, Inc

<snip>

---

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

I'm not proposing to use SIP as "transport", but simply as a message
format, carried over TCP or similar reliable, congestion-controlled
protocol. The SIP transport properties (retransmission, etc.) do not
apply here. I fail to see why CPIM-over-TCP is any different in this
regard than MESSAGE-over-TCP.