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

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Mon, 06 Nov 2006 21:31:04 +0200

Hi Paul,

thank you for the comments,
about the "disposition" values, the idea is to use it to suggest the
receiver what to do with the file he is receiving.
There could be situations where the sender wants the receiver shows
immediately what he is sending (e.g. have a look to this a photo). 
In other situation the sender just send a file without mind when the
receiver will show it (e.g. here the document I promise you to send!)

regards
Sal  

On Fri, 2006-10-20 at 10:38 -0400, Paul Kyzivat wrote:
> 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:
> > 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
> > 
> > ------------------------------------------------------------------------
> > 
> > Subject:
> > I-D ACTION:draft-garcia-mmusic-file-transfer-mech-01.txt
> > From:
> > "ext [email-masked]" <[email-masked]>
> > Date:
> > Thu, 19 Oct 2006 15:50:03 -0400
> > To:
> > [email-masked]
> > 
> > To:
> > [email-masked]
> > CC:
> > 
> > 
> > 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
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Tue, 07 Nov 2006 02:27:59 +0200

Hi Paul,

I agree with you that due to the split off of the msrp stream for file
transfer "inline" and "attachment" content-disposition value have lost
meaning in the transfer context and "render" and something new value
like "store" or similar might be to recommend.

Sal

On Mon, 2006-11-06 at 19:10 -0500, Paul Kyzivat wrote:
> I agree that there are different things that one might want to do with 
> the received file. What I don't see is a framework that helps interpret 
> the defined content-disposition values. When the value is "inline", what 
> is the content to be in line with? When the value is "attachment", then 
> what is the content to be attached *to*?
> 
> In the context of smtp there is an assumption that the message as a 
> whole is being presented, so "inline" and "attachment" have meaning 
> relative to that message being presented - either presented in line with 
> it, or attached to it.
> 
> If we were talking about multipart bodies being used for IM, where there 
> is a main body part that is being presented, and other associated body 
> parts, then "inline" and "attachment" would have the same meaning.
> 
> But here the msrp stream for file transfer has been split off. 
> Presumably the file is *not* to be presented. So how are these 
> dispositions to be interpreted?
> 
> At the very least, it might be better to recommend "render" than 
> "inline". And perhaps a new value: "save" or "file" or "store" might be 
>   better than "attachment".
> 
> 	Paul
> 
> Salvatore Loreto (JO/LMF) wrote:
> > Hi Paul,
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Nov 2006 20:55:30 -0500

I am not very well informed of common practice or requirements for email 
encoding. Is there a Content-Disposition that is used for the *main* 
body of an email? I looked at your email (the one I am replying to) and 
it had no Content-Disposition at all, so presumably it uses whatever is 
considered default for email.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Nov 2006 19:10:26 -0500

Paul

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Tue, 07 Nov 2006 20:01:54 +0200

I suppose that in email encoding, the Content-Disposition is only added
for carry *special content* like attachment, image in mail, or something
like that, instead for a only text mail, the Content-Disposition is not
inserted. Relying on the statement in RFC 2183 "In its absence, the MUA
may use whatever presentation method it deems suitable."

Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Nov 2006 13:40:30 -0500

> may use whatever presentation method it deems suitable."

Hmm. That is interesting. So for email there is no content disposition 
type that is equivalent to the absence of a content-disposition header.

In SIP and MSRP that isn't the case. The absence of a 
Content-Disposition results in a default being applied. ("session" if 
the Content-Type is "application/sdp", and "render" in all other cases.)

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 07 Nov 2006 22:49:31 +0200

So are we looking at two disposition types here: "render" and "save"

The former already exists. The latter does not, so in case we go into 
that direction, we would need to register with IANA.

About the default value, I think there shouldn't be a default value. If 
the file sender does not include the disposition, then there is not hint 
at the receiver of what to do with the file. At the end of the day, this 
disposition is just a hint from the file sender to the file receiver.

Comments?

/Miguel

Paul Kyzivat wrote:
>>> I am not very well informed of common practice or requirements for 
>>> email encoding. Is there a Content-Disposition that is used for the 
>>> *main* body of an email? I looked at your email (the one I am 
>>> replying to) and it had no Content-Disposition at all, so presumably 
>>> it uses whatever is considered default for email.
>>>
>>>     Paul
>>>
>>>>> I agree that there are different things that one might want to do 
>>>>> with the received file. What I don't see is a framework that helps 
>>>>> interpret the defined content-disposition values. When the value is 
>>>>> "inline", what is the content to be in line with? When the value is 
>>>>> "attachment", then what is the content to be attached *to*?
>>>>>
>>>>> relative to that message being presented - either presented in line 
>>>>> with it, or attached to it.
>>>>>
>>>>> If we were talking about multipart bodies being used for IM, where 
>>>>> there is a main body part that is being presented, and other 
>>>>> associated body parts, then "inline" and "attachment" would have 
>>>>> the same meaning.
>>>>>
>>>>> "inline". And perhaps a new value: "save" or "file" or "store" 
>>>>> might be   better than "attachment".
>>>>>
>>>>>     Paul
>>>>>
>>>>>>> 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:
>>>>>>>
>>>>>>> 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:
>>>>>>>> A new version of the file transfer draft is available now. We 
>>>>>>>> have captured the comments and discussions we had in the past.
>>>>>>>>
>>>>>>>> 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
>>>>>>>> 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".
>>>>>>>>
>>>>>>>> http://www.ietf.org/shadow.html or 
>>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>>
>>>>>>>>     "FILE 
>>>>>>>> /internet-drafts/draft-garcia-mmusic-file-transfer-mech-01.txt".
>>>>>>>>     

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Nov 2006 16:44:37 -0500

> that direction, we would need to register with IANA.

I already sent a note to the simple list. "render" is defined in the 
3261 extensions to Content-Disposition, but those aren't referenced by 
MSRP.

I'm far from certain, but I can find no IANA registry for content 
dispositions. 3261 just defines its own. It may be that other RFCs need 
to do likewise.

If there is no registry, then it may be that there are also other values 
defined somewhere. Maybe there are some other ones that are suitable.

> disposition is just a hint from the file sender to the file receiver.

At the moment, there are two precedents: apparently mail has no default, 
but SIP does have a default. And at the moment MSRP also specifies that 
it does have a default. If you want there to be no default, then MSRP 
will need to be revised. Practically speaking, I see little difference 
between having no default and having a special value that is the default.

	Paul

>>>>>> interpret the defined content-disposition values. When the value 
>>>>>> is "inline", what is the content to be in line with? When the 
>>>>>> value is "attachment", then what is the content to be attached *to*?
>>>>>>
>>>>>> In the context of smtp there is an assumption that the message as 
>>>>>> a whole is being presented, so "inline" and "attachment" have 
>>>>>> meaning relative to that message being presented - either 
>>>>>> presented in line with it, or attached to it.
>>>>>>
>>>>>>> immediately what he is sending (e.g. have a look to this a 
>>>>>>> photo). In other situation the sender just send a file without 
>>>>>>> mind when the
>>>>>>> Sal On Fri, 2006-10-20 at 10:38 -0400, Paul Kyzivat wrote:
>>>>>>>> I have a couple of small points and one somewhat more 
>>>>>>>> significant one. First the significant one:
>>>>>>>>
>>>>>>>> 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:
>>>>>>>>

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 07 Nov 2006 23:50:47 +0200

Paul:

The IANA registry you are looking for is:

http://www.iana.org/assignments/mail-cont-disp

With respect the default value, it is not the intention of this draft to 
revise MSRP, so if MSRP has a default, we would just refer to it.

/Miguel

Paul Kyzivat wrote:
>> About the default value, I think there shouldn't be a default value. 
>> If the file sender does not include the disposition, then there is not 
>> hint at the receiver of what to do with the file. At the end of the 
>> day, this disposition is just a hint from the file sender to the file 
>> receiver.
> 
>>> Hmm. That is interesting. So for email there is no content 
>>> disposition type that is equivalent to the absence of a 
>>> content-disposition header.
>>>
>>>>> replying to) and it had no Content-Disposition at all, so 
>>>>> presumably it uses whatever is considered default for email.
>>>>>
>>>>>     Paul
>>>>>
>>>>>>> with the received file. What I don't see is a framework that 
>>>>>>> helps interpret the defined content-disposition values. When the 
>>>>>>> value is "inline", what is the content to be in line with? When 
>>>>>>> the value is "attachment", then what is the content to be 
>>>>>>> attached *to*?
>>>>>>>
>>>>>>> If we were talking about multipart bodies being used for IM, 
>>>>>>> where there is a main body part that is being presented, and 
>>>>>>> other associated body parts, then "inline" and "attachment" would 
>>>>>>> have the same meaning.
>>>>>>>
>>>>>>>>> - 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:
>>>>>>>>>
>>>>>>>>> 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 
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Nov 2006 19:25:41 -0500

> http://www.iana.org/assignments/mail-cont-disp

Ah! I didn't find that one. Thank you.

Given that, then I think the trick is to find the best definition of the 
Content-Disposition header to reference - one that at least references 
the registry and so acknowledges all the defined values.

> revise MSRP, so if MSRP has a default, we would just refer to it.

Fine.

	Paul

>> dispositions. 3261 just defines its own. It may be that other RFCs 
>> need to do likewise.
>>
>> If there is no registry, then it may be that there are also other 
>> values defined somewhere. Maybe there are some other ones that are 
>> suitable.
>>
>>> If the file sender does not include the disposition, then there is 
>>> not hint at the receiver of what to do with the file. At the end of 
>>> the day, this disposition is just a hint from the file sender to the 
>>> file receiver.
>>
>> At the moment, there are two precedents: apparently mail has no 
>> default, but SIP does have a default. And at the moment MSRP also 
>> specifies that it does have a default. If you want there to be no 
>> default, then MSRP will need to be revised. Practically speaking, I 
>> see little difference between having no default and having a special 
>> value that is the default.
>>
>>     Paul
>>
>>> Comments?
>>>
>>> /Miguel
>>>
>>> Paul Kyzivat wrote:
>>>>
>>>>
>>>> Content-Disposition results in a default being applied. ("session" 
>>>> if the Content-Type is "application/sdp", and "render" in all other 
>>>> cases.)
>>>>
>>>>     Paul
>>>>
>>>>> Sal
>>>>>
>>>>>
>>>>>> email encoding. Is there a Content-Disposition that is used for 
>>>>>> the *main* body of an email? I looked at your email (the one I am 
>>>>>>>> I agree that there are different things that one might want to 
>>>>>>>> do with the received file. What I don't see is a framework that 
>>>>>>>> In the context of smtp there is an assumption that the message 
>>>>>>>> as a whole is being presented, so "inline" and "attachment" have 
>>>>>>>> other associated body parts, then "inline" and "attachment" 
>>>>>>>> would have the same meaning.
>>>>>>>>
>>>>>>>>>> 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 
>>>>>>>>>> - Figures 5/6: the file selector specifies a file of size 
>>>>>>>>>> 4096, but only 4092 bytes are transferred.
>>>>>>>>>>
>>>>>>>>>>     Thanks,
>>>>>>>>>>     Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Miguel Garcia wrote: