Subject: [Simple] message/cpim in chunked MSRP SEND requests

From: Miguel Garcia <[email-masked]>
Date: Thu, 12 Oct 2006 16:04:06 +0300

Hi:

On drafting examples for the file transfer draft, we (the authors of the 
file transfer draft) found some lack of clarifications in the MSRP draft 
regarding handling of chunks that contain message/cpim messages. 
Hopefully the authors of the MSRP draft can clarify this and update the 
draft before it is published as an RFC, if we want to achieve 
interoperability.

So, here is the story: Assume you have a content that must be chunked. 
According to the example in Section 5.1, every chunk will contain a 
Content-Type header.

     MSRP dkei38sd SEND
     Message-ID: 456
     Byte-Range: 1-4/8
     Content-Type: text/plain

     abcd
     -------dkei38sd+

     MSRP dkei38ia SEND
     Message-ID: 456
     Byte-Range: 5-8/8
     Content-Type: text/plain

     EFGH
     -------dkei38ia$

I think the example should show a message/cpim wrapper, since it is 
quasi-MUST for MSRP. So, if I am sending the same above content in 
message/cpim, I don't know if a have to put a message/cpim wrapper in 
the second chunk or not.

So, the first chunk is something like this:

     MSRP dkei38sd SEND
     Message-ID: 456
     Byte-Range: 1-124/248
     Content-Type: message/cpim

     To: Bob <sip:[email-masked]>
     From: Alice <sip:[email-masked]>
     DateTime: 2006-05-15T15:02:31-03:00
     Content-Type text/plain

     abcd
     -------dkei38sd+

Now, I can think of 3 options for the second chunk. Here is option 1 for 
the second chunk: it repeats the message/cpim header.

     MSRP dkei38ia SEND
     Message-ID: 456
     Byte-Range: 125-248/248
     Content-Type: text/plain

     To: Bob <sip:[email-masked]>
     From: Alice <sip:[email-masked]>
     DateTime: 2006-05-15T15:02:31-03:00
     Content-Type text/plain

     EFGH
     -------dkei38ia$

And here is option 2 for the second chunk. There is no cpim wrapper. The 
content-type header is text/plain, which is the content below.

     MSRP dkei38sd SEND
     Message-ID: 456
     Byte-Range: 125-129/129
     Content-Type: text/plain

     EFGH
     -------dkei38ia$

Still a third option: it considers the message/cpim a whole chunk, so 
from the MSRP point view, there is only a nessage/cpim content, which is 
split, so the second chunk still has a Content-Type of message/cpim, in 
spite it is nothing of cpim in the body.

     MSRP dkei38sd SEND
     Message-ID: 456
     Byte-Range: 125-129/129
     Content-Type: message/cpim

     EFGH
     -------dkei38ia$

Please notice the difference in the cpim headers, and the Byte-Range and 
Content-Type headers.

1) Which one is correct? The draft says nothing

Option 2 would look more reasonable to me, however, it is kind of 
asymmetrical. I think it ought to be the 3rd option, but it is a big odd 
to have the Content-Type: message/cpim with a plain/text in there.

So, I think MSRP has to clarify this point and provide examples of 
chunked messages containing cpim wrappers.

Any immediate thought?

2) Section 7.1 in MSRP says:

    "If the request has a body, it MUST contain a Content-Type header 
field.  "

But I think it does not say anything with respect any of the chunks. I 
assume that according to the examples and the above general statement 
about SEND requests, every chunk has to contain a Content-Type header.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Oct 2006 10:34:10 -0400

Miguel,

You seem to have a valid concern here. Of the options you present, I 
think option 3 is the most appropriate.

It might be better if subsequent chunks didn't have a content-type 
header at all.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Oct 2006 10:32:09 -0500

Option 3 is the intent. You have one message/cpim document split into  
parts.

I don't think that message/cpim is special here--it would be treated  
the same as any other content-type for the purposes of chunking. I  
_thought_ we had language indicating that you do your MIME formating  
prior to splitting into chunks--I will verify. (I know we have  
language to that effect for s/mime processing.)

On Oct 12, 2006, at 9:34 AM, Paul Kyzivat wrote:

> Miguel,
>
> You seem to have a valid concern here. Of the options you present,  
> I think option 3 is the most appropriate.
>
>> On drafting examples for the file transfer draft, we (the authors  
>> of the file transfer draft) found some lack of clarifications in  
>> the MSRP draft regarding handling of chunks that contain message/ 
>> cpim messages. Hopefully the authors of the MSRP draft can clarify  
>> this and update the draft before it is published as an RFC, if we  
>> want to achieve interoperability.
>> So, here is the story: Assume you have a content that must be  
>> chunked. According to the example in Section 5.1, every chunk will  
>> contain a Content-Type header.
>>     MSRP dkei38sd SEND
>>     Message-ID: 456
>>     Byte-Range: 1-4/8
>>     Content-Type: text/plain
>>     abcd
>>     -------dkei38sd+
>>     MSRP dkei38ia SEND
>>     Message-ID: 456
>>     Byte-Range: 5-8/8
>>     Content-Type: text/plain
>>     EFGH
>>     -------dkei38ia$
>> I think the example should show a message/cpim wrapper, since it  
>> is quasi-MUST for MSRP. So, if I am sending the same above content  
>> in message/cpim, I don't know if a have to put a message/cpim  
>> wrapper in the second chunk or not.
>> Now, I can think of 3 options for the second chunk. Here is option  
>> 1 for the second chunk: it repeats the message/cpim header.
>>     MSRP dkei38ia SEND
>>     Message-ID: 456
>>     Byte-Range: 125-248/248
>>     Content-Type: text/plain
>> And here is option 2 for the second chunk. There is no cpim  
>> wrapper. The content-type header is text/plain, which is the  
>> content below.
>>     MSRP dkei38sd SEND
>>     Message-ID: 456
>>     Byte-Range: 125-129/129
>>     Content-Type: text/plain
>>     EFGH
>>     -------dkei38ia$
>> Still a third option: it considers the message/cpim a whole chunk,  
>> so from the MSRP point view, there is only a nessage/cpim content,  
>> which is split, so the second chunk still has a Content-Type of  
>> message/cpim, in spite it is nothing of cpim in the body.
>>     MSRP dkei38sd SEND
>>     Message-ID: 456
>>     Byte-Range: 125-129/129
>> Please notice the difference in the cpim headers, and the Byte- 
>> Range and Content-Type headers.
>> asymmetrical. I think it ought to be the 3rd option, but it is a  
>> big odd to have the Content-Type: message/cpim with a plain/text  
>> in there.
>>    "If the request has a body, it MUST contain a Content-Type  
>> header field.  "
>> But I think it does not say anything with respect any of the  
>> chunks. I assume that according to the examples and the above  
>> general statement about SEND requests, every chunk has to contain  
>> a Content-Type header.
>> /Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Oct 2006 12:59:19 -0400

Ben,

This is consistent with what I was thinking. It does however leave a 
question as to the purpose of the Content-Type header in the subsequent 
chunks. Its at best redundant info. OTOH, its not really worth the 
trouble to fix.

	Paul

Ben Campbell wrote:
> The conventions section of the draft says the following:
> 
>>    This document consistently refers to a "message" as a complete unit
>>    of MIME or text content.  In some cases, a message is split and
>>    delivered in more than one MSRP request.  Each of these portions of
>>    the complete message is called a "chunk".
> 
> All the sections that talk about chunking refer to splitting a "message" 
> into "chunks". Since a message/cpim document is a "complete unit of 
> MIME" content, it seems to me that this situation is covered, although 
> it could perhaps be a emphasized a little more.
> 
> On Oct 12, 2006, at 10:32 AM, Ben Campbell wrote:
> 
>>>> On drafting examples for the file transfer draft, we (the authors of 
>>>> the file transfer draft) found some lack of clarifications in the 
>>>> MSRP draft regarding handling of chunks that contain message/cpim 
>>>> messages. Hopefully the authors of the MSRP draft can clarify this 
>>>> and update the draft before it is published as an RFC, if we want to 
>>>> achieve interoperability.
>>>> message/cpim, I don't know if a have to put a message/cpim wrapper 
>>>> in the second chunk or not.
>>>> Now, I can think of 3 options for the second chunk. Here is option 1 
>>>> for the second chunk: it repeats the message/cpim header.
>>>>     MSRP dkei38ia SEND
>>>>     Message-ID: 456
>>>>     Byte-Range: 125-248/248
>>>>     Content-Type: text/plain
>>>> And here is option 2 for the second chunk. There is no cpim wrapper. 
>>>> The content-type header is text/plain, which is the content below.
>>>>     MSRP dkei38sd SEND
>>>>     Message-ID: 456
>>>>     Byte-Range: 125-129/129
>>>>     Content-Type: text/plain
>>>>     EFGH
>>>>     -------dkei38ia$
>>>> Please notice the difference in the cpim headers, and the Byte-Range 
>>>> and Content-Type headers.
>>>> asymmetrical. I think it ought to be the 3rd option, but it is a big 
>>>> odd to have the Content-Type: message/cpim with a plain/text in there.
>>>> But I think it does not say anything with respect any of the chunks. 
>>>> I assume that according to the examples and the above general 
>>>> statement about SEND requests, every chunk has to contain a 
>>>> Content-Type header.
>>>> /Miguel
>>
>>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Oct 2006 12:55:14 -0500

I agree it is not worth changing. I suppose it might be useful to an  
implementation if it receives chunks out of order.

On Oct 12, 2006, at 11:59 AM, Paul Kyzivat wrote:

> Ben,
>
> This is consistent with what I was thinking. It does however leave  
> a question as to the purpose of the Content-Type header in the  
> subsequent chunks. Its at best redundant info. OTOH, its not really  
> worth the trouble to fix.
>
> 	Paul
>
> Ben Campbell wrote:
>> All the sections that talk about chunking refer to splitting a  
>> "message" into "chunks". Since a message/cpim document is a  
>> "complete unit of MIME" content, it seems to me that this  
>> situation is covered, although it could perhaps be a emphasized a  
>> little more.
>>> Option 3 is the intent. You have one message/cpim document split  
>>> into parts.
>>>
>>> I don't think that message/cpim is special here--it would be  
>>> treated the same as any other content-type for the purposes of  
>>> chunking. I _thought_ we had language indicating that you do your  
>>> MIME formating prior to splitting into chunks--I will verify. (I  
>>> know we have language to that effect for s/mime processing.)
>>>
>>>
>>>> You seem to have a valid concern here. Of the options you  
>>>> present, I think option 3 is the most appropriate.
>>>>
>>>> It might be better if subsequent chunks didn't have a content- 
>>>> type header at all.
>>>>
>>>>     Paul
>>>>
>>>> Miguel Garcia wrote:
>>>>> Hi:
>>>>> On drafting examples for the file transfer draft, we (the  
>>>>> authors of the file transfer draft) found some lack of  
>>>>> clarifications in the MSRP draft regarding handling of chunks  
>>>>> that contain message/cpim messages. Hopefully the authors of  
>>>>> the MSRP draft can clarify this and update the draft before it  
>>>>> is published as an RFC, if we want to achieve interoperability.
>>>>> chunked. According to the example in Section 5.1, every chunk  
>>>>> will contain a Content-Type header.
>>>>>     MSRP dkei38sd SEND
>>>>>     Message-ID: 456
>>>>>     Byte-Range: 1-4/8
>>>>>     Content-Type: text/plain
>>>>>     abcd
>>>>>     -------dkei38sd+
>>>>>     MSRP dkei38ia SEND
>>>>>     Message-ID: 456
>>>>>     Byte-Range: 5-8/8
>>>>>     Content-Type: text/plain
>>>>>     EFGH
>>>>>     -------dkei38ia$
>>>>> I think the example should show a message/cpim wrapper, since  
>>>>> it is quasi-MUST for MSRP. So, if I am sending the same above  
>>>>> content in message/cpim, I don't know if a have to put a  
>>>>> message/cpim wrapper in the second chunk or not.
>>>>> Now, I can think of 3 options for the second chunk. Here is  
>>>>> option 1 for the second chunk: it repeats the message/cpim header.
>>>>>     MSRP dkei38ia SEND
>>>>>     Message-ID: 456
>>>>>     Byte-Range: 125-248/248
>>>>>     Content-Type: text/plain
>>>>> Still a third option: it considers the message/cpim a whole  
>>>>> chunk, so from the MSRP point view, there is only a nessage/ 
>>>>> cpim content, which is split, so the second chunk still has a  
>>>>> Content-Type of message/cpim, in spite it is nothing of cpim in  
>>>>> the body.
>>>>>     MSRP dkei38sd SEND
>>>>>     Message-ID: 456
>>>>>     Byte-Range: 125-129/129
>>>>> Option 2 would look more reasonable to me, however, it is kind  
>>>>> of asymmetrical. I think it ought to be the 3rd option, but it  
>>>>> is a big odd to have the Content-Type: message/cpim with a  
>>>>> plain/text in there.
>>>>> So, I think MSRP has to clarify this point and provide examples  
>>>>> of chunked messages containing cpim wrappers.
>>>>> Any immediate thought?
>>>>> general statement about SEND requests, every chunk has to