Subject: [MMUSIC] [Fwd: I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt]

From: Miguel Garcia <[email-masked]>
Date: Fri, 20 Oct 2006 09:59:10 +0300

A new version of the file transfer draft is available now. We have 
captured the comments and discussions we had in the past.

Please review it and comment it. Please copy the authors and the list.

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

Subject: I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt
From: "ext [email-masked]" <[email-masked]>
To: [email-masked]
Date: Thu, 19 Oct 2006 15:50:03 -0400
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
	Author(s)	: M. Garcia-Martin, et al.
	Filename	: draft-garcia-mmusic-file-transfer-mech-01.txt
	Pages		: 31
	Date		: 2006-10-19
	
This document provides a mechanism to negotiate the transfer of one
   or more files between two endpoints by using the Session Description
   Protocol (SDP) offer/answer model specified in RFC 3264.  SDP is
   extended to describe the attributes of the files to be transferred.
   The offerer can either describe the files it wants to send, or the
   files it would like to receive.  The answerer can either accept or
   reject the offer separately for each individual file .  The transfer
   of one or more files is initiated after a successful negotiation.
   The Message Session Relay Protocol (MSRP) is defined as the default
   mechanism to actually carry the files between the endpoints.  The
   conventions on how to use MSRP for file transfer are also provided in
   this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-garcia-mmusic-file-transfer-mech-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Oct 2006 10:38:27 -0400

Miguel and all the authors,

This looks good to me.

I have a couple of small points and one somewhat more significant one. 
First the significant one:

- When byte-range is used in a file selector, you call for using the 
msrp byte-range mechanism for file chunking to send only the selected 
portion of the file. I think this is a violation of the MSRP protocol. 
It requires that the first chunk sent always start at 1. If all the 
expected chunks are not received, the msrp implementation is going to 
think there was some sort of error or premature termination of a 
transfer. Since I believe this file transfer mechanism is intended to 
operate over a "standard" msrp, rather than extend it, I don't think you 
can do this. Instead, I think for purposes of msrp, the requested byte 
range must be transmitted as a message that always starts with byte 1. 
The recipient may then interpret the result as replacing the selected 
portion of a file. Because of this difference in semantics, it might 
also be less confusing if the selector used a different name.

Now the small ones:

- You specify the use of email "disposition" values, especially 
highlighting "inline" and "attachment" as meaningful. When used with 
email, there is an understood context for interpretting these. In 
particular, they mostly make sense in the context of a multipart body, 
where the "outer" or "first" part is "inline" or "message". Other parts 
are then related to that. So in particular, with "attachment", there is 
something to attach it to, and for "inline" there is something to inline 
it with. I don't understand what the analogous context is here. Is there 
some assumption that there is a relationship to some msrp stream in the 
same session that is being used for "normal" IM? Some guidance on how to 
interpret this would be helpful.

- Figures 5/6: the file selector specifies a file of size 4096, but only 
4092 bytes are transferred.

	Thanks,
	Paul

Miguel Garcia wrote:
> ------------------------------------------------------------------------
> 
> Subject:
> I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt
> From:
> "ext [email-masked]" <[email-masked]>
> Date:
> To:
> [email-masked]
> To:
> [email-masked]
> CC:
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 23 Oct 2006 09:55:55 +0300

Hi Paul:

Thanks for your comments. See inline discussion.

> also be less confusing if the selector used a different name.

It is certainly not the intention of the draft to violate MSRP. I am not 
convinced that we are mandating something against MSRP, we are just 
providing a mechanism to indicate to the "MSRP application client" that 
it should start and stop the transfer at a certain offset, so MSRP 
thinks that the offset is his byte 1, but it is not the real byte 1 of 
the the file. So, it is about telling the MSRP protocol stack that what 
it considers a file is just a portion of it. I think MSRP should not be 
impacted. At least, I haven't seen where such violation in the MSRP draft.

I believe we need to consult the MSRP authors about this issue. I will 
be posting a separate e-mail in SIMPLE and try to get an answer.

As for the naming issue, if you think "selector" is a bad term, we are 
open to assign any other term that better reflects the semantics.

> interpret this would be helpful.

I think I see your point. Perhaps Gonzalo or Sal can comment on this issue.

> 4092 bytes are transferred.

There are a few oversights in the size of these figures, but I think is 
a bit more complicated. The are 3 sizes to consider:

- Figures 4 and 5 contain the file size int he file-selector attribute 
of the SDP. It currently says 4096 bytes. This refers to the file 
excluding cpim overhead.

- Figure 6 contains a 'size' parameter in the Content-Disposition header 
of the CPIM overhead. It currently reads 3996. This ought to be the same 
value as in the SDP in Figures 4 and 5, since it refers to the file size.

- Figures 7, 8, 9, and 10 contain an MSRP Byte-Range header with a 
current value of 4092. This refers to what is transferred in the MSRP 
SEND request, so this includes the message/cpim overhead.

So, in conclusion: Figures 4, 5, and 6 ought to have the same file size. 
Figures 7, 8, 9, and 10 must have a slightly bigger number (exactly 293 
bytes more), since they include the cpim overhead.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 24 Oct 2006 09:28:52 +0300

Miguel Garcia wrote:
>> operate over a "standard" msrp, rather than extend it, I don't think 
>> you can do this. Instead, I think for purposes of msrp, the requested 
>> byte range must be transmitted as a message that always starts with 
>> byte 1. The recipient may then interpret the result as replacing the 
>> selected portion of a file. Because of this difference in semantics, 
>> it might also be less confusing if the selector used a different name.
> 
> 

We had a discussion with the MSRP authors in the SIMPLE mailining list, 
and we concluded that:

- The terminology of the file transfer draft is misleading. The draft 
should not use the term "byte-range" for a new SDP attribute, because if 
the confusion with the MSRP Byte-Range header. Those are different 
things. It is suggested to use the term file-range instead.

- It is possible to use a standard MSRP implementation for file 
transfer, and still have this suspend/resume feature (in essence, use 
the file-range attribute). However, the draft has to include some words 
about this use case clarifying the relation between the SDP attribute 
file-range and the MSRP header Byte-Range.

Example: if I want to send or receive a file whose size is 40,000 bytes, 
but I just want to send or receive bytes 30,001 to 40,000, the SDP 
attribute will be a=file-range:30001-40000. Then, from the point of view 
of MSRP, there is a stream of bytes ranging from byte 1 to 10,000, so 
the MSRP Byte-Range header of the first chunk will be Byte-Range: 
1-1024/10000; the second chunk 1025-2048/10000, etc. (assuming no CPIM 
and 1K chunks).

The next version of the draft will have these changes in.

/Miguel