Subject: [Simple] MSRP, SDP and CPIM

From: Pekka Pessi <[email-masked]>
Date: Tue, 21 Oct 2003 02:35:04 +0300

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:[email-masked]>
   To: Bob <sip:[email-masked]>

   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:[email-masked]>
   To: Bob <sip:[email-masked]>

   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
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Oct 2003 12:57:05 -0500

Hi Pekka.

Someone mentioned the "/" issue to me in at the WG meeting. Was that 
you? We have had some discussion between the authors on how to deal with 
this. I plan to have something in the next update. I think your approach 
is as good as anything we have come up with so far.

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.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Oct 2003 12:57:05 -0500

Hi Pekka.

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 20 Oct 2003 14:00:18 +0300

Ben Campbell <[email-masked]> 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.

	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.

	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.

	BR,
					Pekka

>> Requires header. Perhaps the supported or required extensions could be
>> indicated as SDP
>> attributes, too.

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 20 Oct 2003 13:43:11 +0300

Ben Campbell <[email-masked]> writes:
>Someone mentioned the "/" issue to me in at the WG meeting. Was that you? We
>have had some discussion between the authors on how to deal with this. I
>plan to have something in the next update. I think your approach is as good
>as anything we have come up with so far.

	Yes, that is me. We disscussed this in last IETF, and the
	top-level-accept was actually your idea.

						Pekka

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 20 Oct 2003 14:00:18 +0300

BR,
					Pekka

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 20 Oct 2003 13:43:11 +0300

Pekka

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2003 08:26:49 -0500

> 	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.

> 	those five headers having slightly different quoting rules.

Can you elaborate on the required quoting rules?

> 	define that line starting with "Content-" will start a MIME

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.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2003 08:26:49 -0500

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 20 Oct 2003 19:15:22 +0300

Ben Campbell <[email-masked]> writes:
>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.

	Now I *think* I understand your point. Because we can not know
	if there is a relay, and if end-to-end security is required,
	impp-im mandates us to use S/MIME?

	But the same document mandates us to use message/cpim is
	end-to-end security is required. If you just use message/cpim it
	does not mean that you have to us S/MIME.

>Can you elaborate on the required quoting rules? 

	I'm sorry, I've probably have been working a bit too closely
	with evil MIME things lately.

	So, MSRP Content-Type is defined as 

"Content-Type" ":" quoted-string

	Which definition of quoted-string you use, RFC 2046 / RFC 2822,
	HTTP, SIP, CPIM? Your own? On a gateway, can we map any
	Content-Type header to an MSRP Content-Type and vice versa?

	IOW, what we do with an incoming header

Content-Type: multipart/mixed; boundary="asdfjklö"; description="This is a
  \"MIME\" message."

	??

>We already support including any MIME object. 

	I was trying to say that we should include MIME objects in MSRP
	like Message/CPIM does. In message/cpim MIME headers are
	separated from the CPIM headers by an empty line.

	But in any case, currently MSRP does not have MIME-Version
	header, which is a MUST thing by RFC 2045.

					Pekka

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 20 Oct 2003 19:15:22 +0300

??

					Pekka