Subject: [MMUSIC] file transfer, moving forward

From: Miguel Garcia <[email-masked]>
Date: Fri, 08 Sep 2006 09:17:27 +0300

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.

We are looking for opinions and consensus of whether this is the way to 
proceed.

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

    --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

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

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

---

From: Aki Niemi <[email-masked]>
Date: Fri, 22 Sep 2006 10:51:51 +0300

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
> ).
>
> 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 *

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
> --ABC Content-type: image/jpeg; Content-ID: <[email-masked]>
>