Subject: Re: [MMUSIC] file transfer, moving forward

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Oct 2006 13:17:37 +0300

Hi Aki,

I find the MIME-based proposal technically more elegant. However, you 
are probably right that it raises the bar for implementers a little 
higher than the solution based on SDP attributes.

We would like to hear further opinions on this. So far there has not 
been support for the new approach. We would like to start working on a 
new revision of the draft shortly and we need to know which approach to use.

Cheers,

Gonzalo

Aki Niemi wrote:
> Inline.
> 
> ext Miguel Garcia kirjoitti:
>> We discussed the file transfer draft in Montreal, and Dan was
>> commenting about the possibility of using message/external-body (RFC
>> 2046) as an external reference to the file (see the thread starting
>> at http://www1.ietf.org/mail-archive/web/mmusic/current/msg04367.html
>> ).
>>
>> So, we (the authors) went through Dan's suggestion, and here is an
>> example of how a file transfer offer in SDP would look like if we use
>> message/external-body. I have highlighted where new tokens or
>> extended values are needed, to differentiate them from already
>> existing parameters.
>>
>> We like this idea, because it outsources from SDP the file
>> descriptor, besides, it reuses most of the Content-Disposition
>> already existing stuff.
> 
> The problem I see is, you now only reuse the syntax, not the actual
> semantics of message/external-body. Normally, if I receive a MIME object
> with message/external-body, it will tell me what method to use for
> fetching the actual content of that object.
> 
> In file transfer, this is not the case, since it's a push instead of a
> pull operation. So even if you had support for multipart and
> message/external-body, you'd need to implement totally new functionality.
> 
>> We are looking for opinions and consensus of whether this is the way
>> to proceed.
> 
> I don't like it. This change seems to only save a few lines of RFC text
> by referencing some already defined header fields, instead of defining
> them itself.
> 
> But writing specifications is a sunk cost anyway, and we should not
> optimize that. instead we should optimize following these criteria:
> 
> a) minimizing the lines of code required to implement the specification
> b) maximizing the probability that interop is achieved by implementors
> of the specification
> 
> This new approach, IMHO, does neither.
> 
> Also, I suspect that using MIME multipart all but guarantees no existing
> middle box will work, and very few SIP implementations will know where
> to look for the SDP. In other words, this is not backwards-compatible
> (MIME multipart support is a SHOULD in SIP).
> 
>> Here is the example. It is as complete as possible, so, in many
>> cases, we woon't be signaling all these metadada:
>>
>> INVITE ... Content-Type: multipart/related; boundary=ABC
>>
>> --ABC Content-Type: application/sdp
>>
>> v=0 ... m=message 7654 TCP/MSRP *
>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
>> a=file-descriptor:cid:[email-masked]        <---------- extension
> 
> Since you already need to define at least one new SDP attribute, and
> there's no way around that, then one way to limit this number is by
> reusing some of the already defined SDP fields to serve your purpose.
> 
> For instance, the suggested file name could be carried in the s=field.
> AFAIK, nobody uses it to really set the subject of the session; here,
> you could make it useful again.
> 
> Also, the name file-descriptor is a terrible name, since that already
> has a well-defined meaning in computer programming.
> 
> Cheers,
> Aki
> 
>> --ABC Content-type: message/external-body; access-type="MSRP"
>> <----------- new token Content-ID: <[email-masked]>
>>
>> Content-type: image/jpeg Content-ID: <[email-masked]>
>> Content-Disposition: inline; filename="My cool picture.jpg";
>> size=98320932; byte-range=80-100                         <----
>> extension creation-date="Mon, 15 May 2006 15:01:31 +03:00";
>> modification-date="Mon, 16 May 2006 15:01:31 +03:00"; read-date="Mon,
>> 18 May 2006 15:01:31 +03:00"; icon="cid:[email-masked]";
>> <----------- extension
>> hash=sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E  <----- ext
>>
>> --ABC Content-type: image/jpeg; Content-ID: <[email-masked]>
>>
>> ...binary JPEG icon image ...
>>
>> --ABC--
>>
>>
>> Comments, please.
>>
>> /Miguel
>>
> 
> 
> 

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

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 05 Oct 2006 15:25:19 +0300

I think simplicity should be taken into account.

Additionally, if you want rapid deployment, it is easier to integrate 
the current solution in draft in current deployments (think of SBCs for 
example).

It is true that the current solution is less elegant, but we need to 
balance between practicalities and elegance.

/Miguel

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Oct 2006 10:57:38 -0700

Thanks for investigating my proposal in detail.  

The primary objection to my proposal, which I agree with, is SIP's mistake
to partially adopt MIME without adopting multipart.  This is another
unfortunate case that demonstrates that mistake.  The savings isn't just to
save time writing specifications, but in using existing tools that can
process external-body MIME types -- Nathaniel Borenstein's classic metamail
tools are but one example of existing code that could process such a
bodypart.

I concur with the objections to using external-body.

However, please consider which of the external-body parameters (section
5.2.3.1 of RFC2046) may be useful when you define these same parameters as
SDP attributes.  For example, RFC2046 defines an expiration date parameter
(but draft-garcia-mmusic-file-transfer-mech-00.txt doesn't define an
expiration date attribute), and it might be useful to someone to have such
an attribute.

Another, unrelated thing you might want to consider is consuming only one
SDP attribute and putting all the file parameters in that one attribute.
For example, instead of your current syntax (this taken from your current
-00 document):

      m=message 7654 TCP/MSRP *
      i=This is my latest picture
      a=sendonly
      a=accept-types:*
      a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
  *   a=filename:My cool picture.jpg
  *   a=filetype:image/jpeg
  *   a=disposition:inline
  *   a=filesize:32349
  *   a=creation-date:Mon, 15 May 2006 15:01:31 +03:00
  *   a=icon:cid:[email-masked]
  *   a=hash:SHA 72245FE8653DDAF371362F86D471913EE4A2CE2E

if it might make more sense to have something like this:

      m=message 7654 TCP/MSRP *
      i=This is my latest picture
      a=sendonly
      a=accept-types:*
      a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
  *   a=file-attributes filename:"My cool picture.jpg"
  *     type:image/jpeg disposition:inline size:32349
  *     creation:"Mon, 15 May 2006 15:01:31 +03:00"
  *     icon:cid:[email-masked]
  *     hash:SHA:72245FE8653DDAF371362F86D471913EE4A2CE2E

And one question for you -- will you allow "../" in the filename, or
filenames such as "/etc/passwd", or filenames with non-printable characters?
The syntax allows it byte-string, which would allow such abuse.  I noticed
your security considerations is currently just a placeholder; section
5.2.3.6 of RFC2046 may be helpful.

-d

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Thursday, October 05, 2006 3:18 AM
> To: Aki Niemi
> Cc: ext Miguel Garcia; [email-masked]; Dan Wing; Isomaki 
> Markus (Nokia-TP/Espoo)
> Subject: Re: [MMUSIC] file transfer, moving forward
> 
> Hi Aki,
> 
> >> at 
> http://www1.ietf.org/mail-archive/web/mmusic/current/msg04367.html
> >> ).
> >>

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 05 Oct 2006 21:28:02 +0300

Hi Dan:

Thanks for your comments. I get we are getting consensus in this aspect.

With respect your points:

1) Parameter from the external-body: We'll do a further examination and 
determine if something else is needed. I agree with adding the 
expiration date parameter. One could have think that the Expires header 
in SIP could do the same job, but it is not true: the Expires headers 
affect the session (i.e., all the media streams); the expiration-date 
will affect the file only.

2) Putting all the attributes in a single line. I have no problems with 
it. Can anyone think that we will break SDP by having very long lines?

3) With respect the file names. I think we ought to be careful here. On 
one hand, we should not allow to represent directories, mainly due to 
the disparity of implementations. The same applies for non-printable 
characters. However, we need to allow for internationalization. So I 
guess the idea is that the point is taken and we need to be able to 
solve it. If someone has some concern or idea, I will be happy to hear it.

/Miguel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 06 Oct 2006 09:10:31 +0300

Hi,

> 2) Putting all the attributes in a single line. I have no problems
> with it. Can anyone think that we will break SDP by having very long
> lines?

I do not see the advantage of putting the attributes in a single line.
If we use different lines, standard SDP rules apply to new unknown
parameters, such as what to do if you do not understand them. If we
define everything in a single line, we would need to replicate all those
rules for the contents of our attributes. I believe there will be
implementations that only care about certain attributes and will not
implement all of them. Separate lines provide us with a more
SDP-friendly way to deal with those situations.

Cheers,

Gonzalo

---

From: <[email-masked]>
Date: Thu, 5 Oct 2006 15:53:59 +0300

Hi,

I agree with Miguel (and Aki). It is usually a good principle to utilize
existing work, and in that sense message/external-body is tempting, and
initially I thought we should adopt it. However, it seems that in this
case the re-use would not make implementation or interoperability easier
but actually more burdensome. Also the implications with SBCs/B2BUAs
that inspect or rewrite SDP make me worried.

So, based on this rationale, I would keep the current approach.

Markus 

>From: Miguel Garcia [mailto:[email-masked]] 
>Sent: 05 October, 2006 15:25
>To: Gonzalo Camarillo
>Cc: Niemi Aki (Nokia-NRC/Helsinki); [email-masked]; Dan Wing; 
>Isomaki Markus (Nokia-SIR/Espoo)
>Additionally, if you want rapid deployment, it is easier to 
>integrate the current solution in draft in current deployments 
>(think of SBCs for example).
>
>It is true that the current solution is less elegant, but we 
>need to balance between practicalities and elegance.
>
>/Miguel
>
>Gonzalo Camarillo wrote:
>> Hi Aki,
>> 
>>>> example of how a file transfer offer in SDP would look like if we 
>>>> use message/external-body. I have highlighted where new tokens or 
>>> semantics of message/external-body. Normally, if I receive a MIME 
>>> object with message/external-body, it will tell me what 
>method to use 
>>> for fetching the actual content of that object.
>>>
>>> In file transfer, this is not the case, since it's a push 
>instead of 
>>> a pull operation. So even if you had support for multipart and 
>>> I don't like it. This change seems to only save a few lines of RFC 
>>> text by referencing some already defined header fields, instead of 
>>> defining them itself.
>>>
>>> b) maximizing the probability that interop is achieved by 
>>> implementors of the specification
>>>
>>> Also, I suspect that using MIME multipart all but guarantees no 
>>> existing middle box will work, and very few SIP 
>implementations will 
>>> know where to look for the SDP. In other words, this is not 
>>> backwards-compatible (MIME multipart support is a SHOULD in SIP).
>>>