Hi all, and thanks for the discussion.
Miguel
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 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 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 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.
I thought so. But your words below put a different light on it.
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.
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).
This is the scenario we are looking at.
/Miguel
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.
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:
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:miguel.garcia at neonsite.net Nokia Research Center Helsinki, Finland
-- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia at neonsite.net Nokia Research Center Helsinki, Finland
_______________________________________________ Simple mailing list Simple at ietf.org https://www1.ietf.org/mailman/listinfo/simple