Subject: RE: [Simple] Comparing CPIM and SIP MESSAGE

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 5 Oct 2001 11:22:47 -0400

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Friday, October 05, 2001 10:55 AM
> To: Petri K. Koskelainen
> Cc: [email-masked]
> Subject: Re: [Simple] Comparing CPIM and SIP MESSAGE
> 
> 
> You comparison uses optional meta-data in the cpim example (not to 
> mention an xml body part), but only required headers in the MESSAGE 
> example, so it is hardly a fair comparison. A closer example 
> (I've taken 
> the liberty of removing the only Contact: from the SIP 
> example, since it 
> is the only header that I think is not required here):

First off, I think this particular debate is really about minutiae. The main
issue is what the underlying "switching" fabric for the transport is;
whether its SIP proxies, or something based on port mapping and IP address
logic. That is really the fundamental question. Those who favor SIP do so
because of the existence of a "routing fabric" of SIP proxies that can
easily get MESSAGE from A to B through various firewall and nat scenarios.
Doing such routing at a transport layer is perhaps newer and more difficult
to deploy; that remains to be determined precisely.

If we have decided that the underlying routing mechanism is not SIP, but
transport layer stuff, we are then free to decide what the format of the
messages is. We have requirements, and starting from that, we can do it with
a fairly small amount of overhead, compared to SIP and CPIM even. We can
choose to use all of the CPIM headers, some of them, or none of them. The
resulting thing could even be made to look like a sip fragment, so Henning
can reuse his parsers, and also look like a compliant CPIM message.
Something like:

From: sip:user@host
Content-Length: 12
Content-Type: text/plain

Hello world.

for example. This is the minimum to meet our requirements for framing,
content type identification and source identification.

So, I would rather focus on how the underlying forwarding is done rather
than on the header syntax.

-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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 05 Oct 2001 10:43:54 -0500

>>
> 
> First off, I think this particular debate is really about minutiae. The
> main issue is what the underlying "switching" fabric for the transport
> is; whether its SIP proxies, or something based on port mapping and IP
> address logic. That is really the fundamental question. Those who favor
> SIP do so because of the existence of a "routing fabric" of SIP proxies
> that can easily get MESSAGE from A to B through various firewall and nat
> scenarios. Doing such routing at a transport layer is perhaps newer and
> more difficult to deploy; that remains to be determined precisely.

Actually, Henning proposed we use MESSAGE, but without using the SIP 
routing fabric. Only some of the MESSAGE proponents expect to use SIP 
routing.

I propose that the method actually used for routing is dependent on the 
receiver implementation or local policy. The receiver may indeed use 
port mapping, or may choose to route based on a To: header or somesuch. 
The sender, however, must include enough information for a non-port 
mapping receiver.

The port-mapping approach has the advantage of being very easy to signal 
in SDP. Mapping based on a header value requires us to signal that 
header value in the INVITE somehow. We already ran into some issues of 
how to do that with a URL when we were considering sessions of SIP messages.

> messages is. We have requirements, and starting from that, we can do it
> with a fairly small amount of overhead, compared to SIP and CPIM even.
> We can choose to use all of the CPIM headers, some of them, or none of
> them. The resulting thing could even be made to look like a sip
> fragment, so Henning can reuse his parsers, and also look like a
> compliant CPIM message. Something like:
> 
> From: sip:user@host
> Content-Length: 12
> Content-Type: text/plain
> 
> Hello world.
> 
>