Subject: [Simple] IM over the signaling connection

From: "Petri K. Koskelainen" <[email-masked]>
Date: Fri, 5 Oct 2001 10:12:05 -0400 (EDT)

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

>I don't think this is a very strong argument. IM needs so few 
>headers that the parsing is not a major issue. 
>Also, do note that a CPIM message can be parsed by a 
>SIP parser, as its a valid sip-frag. This was quite on purpose.

Actually, they have same header names in CPIM and SIP but different
syntax (like Date and Subject, probably others too). CPIM is rather
complex and big format.

Also, what is the difference between CPIM and SIP if they are used
only as an encapsulation format?

SIP has some extra features and some people have proposed to use those
features also, but we don't have to use them..

>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

As said earlier, you don't have to use every header from SIP spec.
Comparing mandatory CPIM headers and SIP headers for IM seems to
indicate that CPIM has more overhead than SIP.

>Also consider that an IM endpoint _must_ already have a 
>CPIM parser, since message/cpim is a 
>required-to-implement feature

I'm not sure at all if this means that all terminals must implement CPIM.
They have SIP there already. No need for CPIM.

--
Petri

---

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

[snip]

> They have SIP there already. No need for CPIM.

The simple-im (page model, not session) draft says that an IM endpoint 
MUST be prepared to receive message/cpim, and MAY send message/cpim. I 
think that is pretty clear.

---

From: "Petri K. Koskelainen" <[email-masked]>
Date: Fri, 5 Oct 2001 11:49:22 -0400 (EDT)

> think that is pretty clear.

Yep, it may receive it and respond with 415 Unsupported Media Type.
 
I'm not convinced that CPIM will ever be used in real world
even if one day CPIM format (or the proposed new CPIM-based 
SIP-like format for instant messages) is ready.
In most cases, text/plain will do the job without extra overhead
in SIP payload and the need to create and test yet another format. 

--
Petri

---

From: Ben Campbell <[email-masked]>
Date: Fri, 05 Oct 2001 15:08:49 -0500

As the writer of the draft, that was not the interpretation I intended, 
nor do I think it was the consensus at the time. In fact, it does not 
distinguish it in any way from saying it needs to be able to receive "foo."

That requirement was in the draft to reflect the requirement that any 
endpoint should be able to handle messages that came via a CPIM 
compliant gatway in a useful way. I believe we had a clear consensus on 
that point; perhaps the chairs could clarify.