[Simple] Re: MSRP, CPIM and MIME content

[Ben Campbell <[e-mail]>]

Pekka Pessi wrote:

> Ben Campbell <[e-mail]> writes:
> 
>>As far as mandating that we always use message/cpim, we did require that at
>>one time, but the wg consensus was for the protocol to allow any mime type.
> 
> 
> 	According to my recollection the WG consensus was to proceed
> 	with both campbell drafts as WG items (im-sessions aka msrp and
> 	cpimmsg-sessions). cpimmsg-sessions was killed because of
> 	comedia, I think. But they are your drafts, not mine.
> 
> 	Again, it would be very beneficial and practically free to have
> 	CPIM container in SEND messages. Having that does not prevent
> 	anyone from sending any MIME type they want, they just have to
> 	add an empty CPIM container there. Receivers can ignore CPIM
> 	containers, unless there is a Requires header.

The current draft allows message/cpim, and provides a way that either 
endpoint may insist on it. But considering that our preferred use-case 
is end-to-end with no intervening relays, and that endpoints may insist 
on using TLS, requiring all sessions to use mesage/cpim seems very heavy 
weight.


> 
> 	As the MSRP stands now, we need to have a Content-Type with evil
> 	inner quoting rules (which need to be added to the ABNF). That
> 	would be fifth Content-Type header in our implementation, all
> 	those five headers having slightly different quoting rules.
> 

Can you elaborate on the required quoting rules?

> 	What about including MIME object in MSRP, just like a MIME
> 	object is included in CPIM? We could even save extra CR-LF and
> 	define that line starting with "Content-" will start a MIME
> 	object.

We already support including any MIME object. We do still require the 
crlf. I am not sure saving the two bytes is worth the change.


> 
> 	BR,
> 					Pekka
> 
> 
>>>Hi,
>>>First, I've a problem with SDP usage by MSRP.
>>>The format parameters on SDP media line should be tokens, and "/" is not
>>>allowed within an SDP token. The token issue was discussed in MMUSIC wg,
>>>and the wg consensus was to keep definition of token as is (and fix the
>>>comment in sdp-new).
>>>So, the top-level media types should be put into an SDP attribute just
>>>like accept-wrapped-types. Example:
>>>   m=message 9999 msrp/tcp *
>>>   a=msrp-accept:message/cpim text/plain, text/html
>>>Alternatively, we could mandate that the MSRP content should always be
>>>Message/CPIM. The message/cpim itself mandates one header, Requires. So,
>>>instead of
>>>   m=message 9999 msrp/tcp message/cpim text/plain text/html
>>>we would have something like this
>>>   m=message 9999 msrp/tcp cpim
>>>   a=msrp-accept: text/plain, text/html
>>>So, what would change at MSRP level? Currently we can have an MSRP message
>>>like this:
>>>    MSRP xx SEND
>>>    TR-ID: 123
>>>    Content-Type: text/plain
>>>    Hi, I'm Alice!
>>>Instead of that, we could have a CPIM message with implied MIME type
>>>message/cpim (so, no Content-Type header in MSRP). Here we have CPIM
>>>message without any CPIM headers:
>>>   MSRP xx SEND
>>>   TR-ID: 123
>>>   Content-Type: text/plain
>>>   Hi, I'm Alice!
>>>So, we pay two extra pairs of CR-LF for CPIM support.
>>>Sender can always include CPIM headers, like From and To,
>>>   MSRP xx SEND
>>>   TR-ID: 123
>>>   From: Alice <sip:[e-mail]>
>>>   To: Bob <sip:[e-mail]>
>>>   Content-Type: text/plain
>>>   Hi, I'm Alice!
>>> but the recipient can safely ignore them. The only exception is Requires
>>>header. In order to properly process Requires, we need 420 Not
>>>Supported, too. Then it might be possible to extend MSRP using CPIM
>>>Requires header. Perhaps the supported or required extensions could be
>>>indicated as SDP
>>>attributes, too.
>>>What about signed CPIM messages? The could be sent inside another one
>>>   MSRP xx SEND
>>>   TR-ID: 123
>>>   My-Own-CPIM-Header: please see secured content
>>>   Content-Type: multipart/signed; boundary=boundary;
>>>                 micalg=sha1;
>>>                 protocol=application/pkcs7-signature
>>>      --boundary
>>>   Content-Type: message/cpim
>>>    From: Alice <sip:[e-mail]>
>>>   To: Bob <sip:[e-mail]>
>>>   Content-Type: text/plain
>>>   Hi, I'm Alice!
>>>   --boundary
>>>   Content-Type: application/pkcs7-signature
>>>   (lots-of-binary-signature-here)
>>>   --boundary--
>>>The real issue of CPIM is that it is just a wrapper around a MIME
>>>object. This is not a problem with most SIP implementations, as they
>>>already support MIME, but there may be some use of MSRP outside SIP?
>>>we could reuse CPIM header structure (quoting, line ending, etc) in
>>>MSRP, if we choose to always have a message/cpim wrapper. I don't mean
>>>that MSRP headers would be part of CPIM message, but that they reuse the
>>>Header ABNF from CPIM.
>>>--Pekka
>>>_______________________________________________
>>>Simple mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/simple
> 
> 
> 
> 
>>_______________________________________________
>>Simple mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/simple



_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple