Subject: [Simple] MSRP first byte

From: Miguel Garcia <[email-masked]>
Date: Mon, 23 Oct 2006 10:15:32 +0300

A question about MSRP.

Paul was discussing the file transfer draft, and argues that standard 
MSRP (whatever that means) cannot start sending a file from an offset 
different than zero. See Paul's post to the MMUSIC list:
http://www1.ietf.org/mail-archive/web/mmusic/current/msg04739.html

We would like to get guidance from the MSRP authors to find out whether 
MSRP has a problem to send a collection of bytes that start (and end) in 
an offset different to zero (or end-of-file).

When we drafted the file transfer draft, we envision that the file 
transfer application provides MSRP with the stream of bytes to be sent. 
This stream of bytes may not correspond to a complete file, but MSRP 
shouldn't care. MSRP should just wrap them in CPIM and ship them. At 
least this is the initial idea.

Does anyone have comments?

The file transfer draft is:

http://www.ietf.org/internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt

/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: Ben Campbell <[email-masked]>
Date: Mon, 23 Oct 2006 08:24:26 -0500

A "standard" MSRP recipient--that is, one that does not implement the  
file-transfer draft, will assume that it has not received the first  
chunk, and will probably wait a while, then give up. It will not  
likely try to render the content,  unless it recognized the media  
type as something it makes sense to render partially.

Also, a relay that "rechunks" into larger chunks could hold the  
content indefinitely waiting for the missing first chunk. (I'm not  
saying that is a good implementation decision, but we don't forbid it.)

They byte-range is intended to describe the bytes in the _message_.  
The fact that the message being sent is a subset of a larger file  
does not change the fact that the first byte of the message is, well,  
the first byte of the message. If we need to indicate that this  
message is a subset of something bigger, I think we need another  
mechanism.

On Oct 23, 2006, at 2:15 AM, Miguel Garcia wrote:

> A question about MSRP.
>
> Paul was discussing the file transfer draft, and argues that  
> standard MSRP (whatever that means) cannot start sending a file  
> from an offset different than zero. See Paul's post to the MMUSIC  
> list:
> We would like to get guidance from the MSRP authors to find out  
> whether MSRP has a problem to send a collection of bytes that start  
> (and end) in an offset different to zero (or end-of-file).
>
> transfer application provides MSRP with the stream of bytes to be  
> sent. This stream of bytes may not correspond to a complete file,  
> but MSRP shouldn't care. MSRP should just wrap them in CPIM and  
> ship them. At least this is the initial idea.
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Oct 2006 07:01:47 -0700

Well, it's been a lot of drafts in the last 12 hours and I may not be  
thinking straight  but... Ben's explination matches how I was  
thinking about it.

On Oct 23, 2006, at 6:24 AM, Ben Campbell wrote:

> A "standard" MSRP recipient--that is, one that does not implement  
> the file-transfer draft, will assume that it has not received the  
> first chunk, and will probably wait a while, then give up. It will  
> not likely try to render the content,  unless it recognized the  
> media type as something it makes sense to render partially.
>
> does not change the fact that the first byte of the message is,  
> well, the first byte of the message. If we need to indicate that  
> this message is a subset of something bigger, I think we need  
> another mechanism.
>
>
>
>> whether MSRP has a problem to send a collection of bytes that  
>> start (and end) in an offset different to zero (or end-of-file).
>>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 23 Oct 2006 17:03:52 +0300

Hi Ben:

I think we have a problem with the terminology. You seem to understand 
by "standard MSRP" a recipient that does not implement the file transfer 
draft, but I understood Paul's words as "a standard MSRP implementation" 
that is complemented with the file transfer draft.

I think that if you have one file-transfer compliant endpoint, and 
another one that does not implement the file transfer draft, the 
scenario is detected by the file-transfer compliant endpoint once the 
offer/answer exchange is complete, and the file-transfer compliant 
endpoint can either proceed or abort, knowing the limitations of the 
other endpoint. So I am not worried about this scenario.

I understood Paul's words as: I have a standard MSRP implementation and 
I want to add the file transfer draft. I understood that the file 
transfer draft suggested violations to the MSRP draft.

Also, perhaps it is good to clarify something that probably is not 
clearly written: If and endpoint request bytes 2000 to 3000 of a file, 
then, from the point of view of MSRP, MSRP has to send 1000 bytes (+ 
CPIM overhead, which might be about 250 bytes). The idea is that the 
MSRP layer receives the 1000 bytes (perhaps plus the CPIM), and will 
range those bytes from 1 until 1250 (including CPIM), and this is what 
becomes visible in the Byte-Range header in MSRP. Then MSRP chunking can 
apply (especially if the portion of the file is larger than 1000 bytes).

This is the scenario we are looking at.

/Miguel

Ben Campbell wrote:
> chunk, and will probably wait a while, then give up. It will not likely 
> try to render the content,  unless it recognized the media type as 
> something it makes sense to render partially.
> 
> Also, a relay that "rechunks" into larger chunks could hold the content 
> indefinitely waiting for the missing first chunk. (I'm not saying that 
> is a good implementation decision, but we don't forbid it.)
> 
> They byte-range is intended to describe the bytes in the _message_. The 
> fact that the message being sent is a subset of a larger file does not 
> change the fact that the first byte of the message is, well, the first 
> byte of the message. If we need to indicate that this message is a 
> subset of something bigger, I think we need another mechanism.
> 
> 
> 
>> sent. This stream of bytes may not correspond to a complete file, but 
>> MSRP shouldn't care. MSRP should just wrap them in CPIM and ship them. 
>> At least this is the initial idea.
>>
>> --Miguel A. Garcia           tel:+358-50-4804586

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Oct 2006 07:35:06 -0700

That makes sense too - are we all saying the same thing here about  
how it should work?

On Oct 23, 2006, at 7:03 AM, Miguel Garcia wrote:

> Hi Ben:
>
> I think we have a problem with the terminology. You seem to  
> understand by "standard MSRP" a recipient that does not implement  
> the file transfer draft, but I understood Paul's words as "a  
> standard MSRP implementation" that is complemented with the file  
> transfer draft.
>
> scenario is detected by the file-transfer compliant endpoint once  
> the offer/answer exchange is complete, and the file-transfer  
> compliant endpoint can either proceed or abort, knowing the  
> limitations of the other endpoint. So I am not worried about this  
> scenario.
>
> I understood Paul's words as: I have a standard MSRP implementation  
> and I want to add the file transfer draft. I understood that the  
> file transfer draft suggested violations to the MSRP draft.
>
> clearly written: If and endpoint request bytes 2000 to 3000 of a  
> file, then, from the point of view of MSRP, MSRP has to send 1000  
> bytes (+ CPIM overhead, which might be about 250 bytes). The idea  
> is that the MSRP layer receives the 1000 bytes (perhaps plus the  
> CPIM), and will range those bytes from 1 until 1250 (including  
> CPIM), and this is what becomes visible in the Byte-Range header in  
> MSRP. Then MSRP chunking can apply (especially if the portion of  
> the file is larger than 1000 bytes).
>
>> They byte-range is intended to describe the bytes in the  
>> _message_. The fact that the message being sent is a subset of a  
>> larger file does not change the fact that the first byte of the  
>> message is, well, the first byte of the message. If we need to  
>> indicate that this message is a subset of something bigger, I  
>> think we need another mechanism.
>>> When we drafted the file transfer draft, we envision that the  
>>> file transfer application provides MSRP with the stream of bytes  
>>> to be sent. This stream of bytes may not correspond to a complete  
>>> file, but MSRP shouldn't care. MSRP should just wrap them in CPIM  
>>> and ship them. At least this is the initial idea.
>>>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Oct 2006 10:03:46 -0500

It's still possible that a relay in the path could get confused by  
not seeing a "first chunk".

> limitations of the other endpoint. So I am not worried about this  

It's still possible that a relay in the path could get confused by  
not seeing a "first chunk".

> the file is larger than 1000 bytes).

I think so. In  your example, the byte-range header would show  
1-1250/1250, right?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Oct 2006 11:29:15 -0400

First, from their responses it appears that Ben and Cullen are thinking 
the same way that I was when I wrote the comment. But I think there may 
still be some confusion. More below.

> that is complemented with the file transfer draft.

I consider the file transfer to be an application riding on top of a 
basic msrp implementation. It should not require any change to that msrp 
implementation to support this file transfer application.

> transfer draft suggested violations to the MSRP draft.

I thought so. But your words below put a different light on it.

> becomes visible in the Byte-Range header in MSRP.

This isn't what I thought you intended. If this is what you meant, then 
I think there is no problem, except perhaps for terminology.

In this case the Byte-Range in your sdp and the Byte-Range in the MSRP 
mean very different things. To avoid this sort of confusion, I suggest 
you use a different term. Perhaps File-Range.

	Paul

> Then MSRP chunking can 
>> likely try to render the content,  unless it recognized the media type 
>> as something it makes sense to render partially.
>>
>> The fact that the message being sent is a subset of a larger file does 
>> not change the fact that the first byte of the message is, well, the 
>> first byte of the message. If we need to indicate that this message is 
>> a subset of something bigger, I think we need another mechanism.
>>
>>
>>
>>> MSRP shouldn't care. MSRP should just wrap them in CPIM and ship 
>>> them. At least this is the initial idea.
>>>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Oct 2006 10:36:33 -0500

On Oct 23, 2006, at 10:29 AM, Paul Kyzivat wrote:

> First, from their responses it appears that Ben and Cullen are  
> thinking the same way that I was when I wrote the comment. But I  
> think there may still be some confusion. More below.
>
> Miguel Garcia wrote:
>> Hi Ben:
> I consider the file transfer to be an application riding on top of  
> a basic msrp implementation. It should not require any change to  
> that msrp implementation to support this file transfer application.
>
>> I understood Paul's words as: I have a standard MSRP  
>> implementation and I want to add the file transfer draft. I  
>> understood that the file transfer draft suggested violations to  
>> the MSRP draft.
>
>> CPIM), and this is what becomes visible in the Byte-Range header  
>> in MSRP.
>
> This isn't what I thought you intended. If this is what you meant,  
> then I think there is no problem, except perhaps for terminology.
>
> In this case the Byte-Range in your sdp and the Byte-Range in the  
> MSRP mean very different things. To avoid this sort of confusion, I  
> suggest you use a different term. Perhaps File-Range.

I suspect I got caught in the same confusion. If we were talking  
about byte-range in the SDP rather than in the MSRP SEND request,  
then my comment about confused relays does not apply, since a relay  
would not care about the SDP.

>
> 	Paul
>
>> Then MSRP chunking can apply (especially if the portion of the  
>> file is larger than 1000 bytes).
>>> first chunk, and will probably wait a while, then give up. It  
>>> will not likely try to render the content,  unless it recognized  
>>> the media type as something it makes sense to render partially.
>>>
>>> content indefinitely waiting for the missing first chunk. (I'm  
>>> not saying that is a good implementation decision, but we don't  
>>> forbid it.)
>>>
>>>> from an offset different than zero. See Paul's post to the  
>>>> MMUSIC list:
>>>> to be sent. This stream of bytes may not correspond to a  
>>>> complete file, but MSRP shouldn't care. MSRP should just wrap  
>>>> them in CPIM and ship them. At least this is the initial idea.
>>>>

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 24 Oct 2006 08:56:39 +0300

Hi all, and thanks for the discussion.

It is clear that:
- We all agree on how this should work.
- The file transfer draft is misleading, specially the byte-range SDP 
attribute, because it is NOT the same thing as the MSRP Byte-Range header.

So, MSRP does not require any further clarification, but the 
file-transfer draft ought to use precise terminology and have further 
discussion.

        Miguel

Ben Campbell wrote:
>> thinking the same way that I was when I wrote the comment. But I think 
>> there may still be some confusion. More below.
>>
>> Miguel Garcia wrote:
>>> Hi Ben:
>>> understand by "standard MSRP" a recipient that does not implement the 
>>> file transfer draft, but I understood Paul's words as "a standard 
>>> MSRP implementation" that is complemented with the file transfer draft.
>>
>> basic msrp implementation. It should not require any change to that 
>> msrp implementation to support this file transfer application.
>>
>>> and I want to add the file transfer draft. I understood that the file 
>>> bytes (+ CPIM overhead, which might be about 250 bytes). The idea is 
>>> that the MSRP layer receives the 1000 bytes (perhaps plus the CPIM), 
>>> and will range those bytes from 1 until 1250 (including CPIM), and 
>>> this is what becomes visible in the Byte-Range header in MSRP.
>>
> I suspect I got caught in the same confusion. If we were talking about 
> byte-range in the SDP rather than in the MSRP SEND request, then my 
> comment about confused relays does not apply, since a relay would not 
> care about the SDP.
> 
> 
>>
>>     Paul
>>
>>> Then MSRP chunking can apply (especially if the portion of the file 
>>> is larger than 1000 bytes).