Subject: [MMUSIC] File-transfer issue 30: file disposition values

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 16:36:37 +0300

Paul Kyzivat wrote:
 > Section 7:
 >
 >    To indicate that a file should be automatically rendered, this memo
 >    uses the existing 'render' value of the Content Disposition type in
 >    the new 'file-disposition' attribute in SDP.  To indicate that a file
 >    should not be automatically rendered, this memo defines a new value
 >    'not-render' of the Content Disposition type.  The default value is
 >    'render', i.e., the absence of a 'file-disposition' attribute in the
 >    SDP has the same semantics as 'render'.
 >
 > The "not-render" disposition seems strange, because it is a negative.
 > IMO something positive would be preferable - perhaps "storage" or
 > "recipient-discretion".

I am fine with the suggestion. I went to the IANA registry once more,
and evaluate the possibility of reusing an existing disposition type.

So, what about the "attachment" disposition type? Its definition in
RFC 2183 says:

    Bodyparts can be designated `attachment' to indicate that they are
    separate from the main body of the mail message, and that their
    display should not be automatic, but contingent upon some further
    action of the user.

I think it meets our requirements, so my proposal is to replace the
existing "not-render" by "attachment". Any views?

/Miguel
-- 
Please note my new e-mail address: miguel.garcia at nsn.com
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Helsinki, Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 May 2007 13:20:16 -0400

I know this one is coming full circle, since I was the one who 
originally objected to "attachment". More inline.

	Paul

- In the file transfer

> and evaluate the possibility of reusing an existing disposition type.

I looked again too, and didn't find anything *clearly* applicable.

>    display should not be automatic, but contingent upon some further

I do think that the kind of behavior you desire is somewhat similar to 
what happens for "attachment" with emails. But there are some 
significant differences:

- in the case of email, the message itself is typically stored, and the 
attachment stays with it by default. Typically it takes an overt action 
by the user to extract the attachment from the message and put it 
somewhere else. (I do think that "attachment" could be used in an MSRP 
stream as part of a multipart/mixed IM message. But that wouldn't be 
quite the semantics you are looking for.)

- When used as you are proposing, the above definition is problematic 
because there is no email message (nor an IM message) as the main body 
for this to be attached to.

New values that come to mind (more than before): "save", "store", "ask", 
"prompt", "storage".

(I'm not clear on what UI action is expected in this case. I'm imagining 
some sort of popup saying "You have a File" or something like that. If 
the sip session that contains this file transfer also has another MSRP 
session used for interactive IM, I guess the request could be 
interspersed with the display of IM messages. But if there was no IM 
session then that wouldn't work. I realize this could be done a lot of 
ways and we don't need to standardize them, but I'm just trying to have 
at least one workable use case in mind. The use case would help motivate 
naming a new disposition.)

At the end of the day, if you want to use "attachment", then as long as 
the draft has a clear description of how it is interpreted in this case, 
and how it differs from the registered definition, then I won't complain.

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 21:41:44 +0300

Yeah, I remember that you objected to "attachment". The reason I am 
coming back to it is not because of the e-mail experience, but because 
of the definition of the "attachment" disposition in RFC 2183, which I 
copy here once more:

So, there are two aspects in the definition of "attachment":
a) what it indicates
b) how they are displayed

In file transfer, a) is different, because it does not indicate 
something separate from the main body of the mail message. However, b) 
is the same: "their display should not be automatic, but continget upon 
some further actions of the user."

I don't have a strong opinion to lean towards one or the other side. I 
just thought that if someone were checking the IANA table of registered 
disposition values, would ask what is the difference between 
"attachment" and "whatever-name-we-defined-for-file-transfer".

Do we have any other opinions who can guide us?

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 May 2007 16:11:47 -0400

We need a MIME expert here. Who do we have who qualifies? Eric?

	Paul

Miguel Garcia wrote:
>> - in the case of email, the message itself is typically stored, and 
>> the attachment stays with it by default. Typically it takes an overt 
>> action by the user to extract the attachment from the message and put 
>> it somewhere else. (I do think that "attachment" could be used in an 
>> MSRP stream as part of a multipart/mixed IM message. But that wouldn't 
>> be quite the semantics you are looking for.)
>>
>> New values that come to mind (more than before): "save", "store", 
>> "ask", "prompt", "storage".
>>
>> (I'm not clear on what UI action is expected in this case. I'm 
>> imagining some sort of popup saying "You have a File" or something 
>> like that. If the sip session that contains this file transfer also 
>> has another MSRP session used for interactive IM, I guess the request 
>> could be interspersed with the display of IM messages. But if there 
>> was no IM session then that wouldn't work. I realize this could be 
>> done a lot of ways and we don't need to standardize them, but I'm just 
>> trying to have at least one workable use case in mind. The use case 
>> would help motivate naming a new disposition.)
>>
>> At the end of the day, if you want to use "attachment", then as long 
>> as the draft has a clear description of how it is interpreted in this 
>> case, and how it differs from the registered definition, then I won't 
>> complain.
>>