Subject: [MMUSIC] -garcia-mmusic-file-transfer-mech-00.txt

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Jul 2006 16:25:22 -0400

Question on this draft:

Has the MIME content-type message/external-body been considered and rejected
for this use?

-d

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

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 14 Jul 2006 16:17:16 +0300

Hi Dan:

I think the message/external-body would be something similar to content 
indirection. Please correct me if my understanding is wrong. Besides, I 
took a look at the current external-body parameters definition, and they 
aren't enough to provide the rich metadata that we want to provide.

The draft provides a discussion about the relation of this draft with 
content indirection mechanisms. Please refer to Section 1 of the draft, 
where the discussion of the content indirection takes place. If you 
think something is missing, please let me know it.

BR,

       Miguel

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Jul 2006 10:06:00 -0400

Thanks.  

What I have in mind is to continue using a media line in your SDP -- as you
do today.  This provides the offer/answer semantics you describe in section
1 of your draft.

However, rather than encoding everything about the external file in SDP,
encode it using MIME -- which already has ways to encode much (but not all)
of these attributes.  Using part of your example from your draft, you would
have a single "a=" in your SDP which points out to the MIME Content-ID that
describes the external data (I highlighted this with the "<" characters) in
the example below:

  INVITE ...
  Content-Type: multipart/related; boundary=ABC

  --ABC
  Content-Type: application/sdp

  v=0
  ...
  m=message 7654 TCP/MSRP *
  a=external-body:cid:[email-masked]          <<<<<<<<<<<<<<<<<<<<<<<<<<<

  --ABC
  Content-type: message/external-body;
                name="My cool picture.jpg";
                url="msrp://atlanta.example.com:7654/jshA7we;tcp"
  Content-ID: <[email-masked]>               <<<<<<<<<<<<<<<<<<<<<<<<<<<<

  Content-type: image/jpeg
  Content-ID: <[email-masked]>
  Content-Transfer-Encoding: binary
  Content-Disposition: inline

  --ABC--

-d

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Friday, July 14, 2006 9:17 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; 'Gonzalo 
> Camarillo'; [email-masked]
> Subject: Re: -garcia-mmusic-file-transfer-mech-00.txt
> 
> Hi Dan:
>

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 14 Jul 2006 17:54:00 +0300

Hi Dan:

Thanks for putting the flow down... I don't think there is a technical 
problem with the flow. In principles, it appears that this works, 
providing that we make sure that we can extend the external-body to 
accommodate all the metadata that can place today.

A first comparison of what the draft currently says and your proposal: 
the draft includes all the metadata as SDP extensions, whereas your 
draft reuses the existing Content-* headers. But your proposal requires 
multipart bodies, which adds a few extra headers.

My only concern is about backward compatibility. The current draft 
allows the file to be transferred even if the SDP answerer does not 
support the SDP extensions we propose. In this case, the SDP answerer 
will accept the session thinking that it is a regular MSRP session, and 
it will receive the file in the MSRP.

In your proposal, at least if we use multipart/related, it seems that we 
are implicitly requiring the implementation of the external-body and 
(potential) extensions to it, otherwise the session is rejected. At 
least I got this impression when I read RFC 2387. But I suspect that a 
multipart/mixed will be a better approach.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Jul 2006 12:38:06 -0400

As it stands, the draft calls for establishing a new MSRP session, 
transmitting the specified file over it, and then terminating it when 
the transfer is complete. I think it would be helpful if you would just 
not terminate the session after transmission of the file.

Suppose Alice and Bob have already used INVITE to establish an MSRP 
session and are busy chatting. Alice then decides to send a file to Bob. 
  I think Alice can just send a reINVITE, adding the attributes 
describing the file transfer to the existing m-line for the MSRP session 
used for chatting. Upon completion of the reINVITE, Alice can then send 
the file on the same session. Meanwhile Alice and Bob can also continue 
to use it for chatting. Effectively, the a-lines specify special 
handling for a message that matches the attributes in the a-lines, while 
leaving any other messages to be processed normally.

If Bob then wants to transfer a file, he can also do a reINVITE to use 
the session for his file, etc.

This of course in no way prevents establishing a new MSRP session for a 
file transfer if so desired.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 14 Jul 2006 19:43:42 +0300

Paul,

note that the fact that the MSRP session is terminated does not imply 
that the TCP connection is terminated. Basically, you will have a single 
MSRP session per file transfer, but all of them would use the same TCP 
connection, which is the TCP connection Bob and Alice are using for the 
other instant messages.

Cheers,

Gonzalo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Jul 2006 11:31:00 -0400

> Sent: Friday, July 14, 2006 10:54 AM
> To: Dan Wing
> will accept the session thinking that it is a regular MSRP 
> session, and it will receive the file in the MSRP.

Ok, so you're saying you would always want the 
  a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
line in the SDP.

I'm just wondering if it's best to replicate the existing MIME 
mechanisms for recommended local filename, content-type, and so
on, in SDP.  It seems MIME already defined them and pointing to a
MIME body outside of SDP is another way to achieve the same end.

I admit neither mechanism has the perfect protocol layering; having
SDP contain an "a=external-body:cid" pointing to a MIME body (as in 
my proposal) isn't pretty.  But SIP supposedly supports MIME so it
seems we should be using existing MIME mechanisms to express an
external body, which is what you're describing with the SDP.

This may require asking the Applications ADs to confer with the 
RAI ADs to see which way we should go.  There is the additional
yuckiness with SIP in that RFC3261 didn't require support for
multipart MIME, alas.

> (potential) extensions to it, otherwise the session is rejected.
> At least I got this impression when I read RFC 2387. But I 
> suspect that a multipart/mixed will be a better approach.

SIP doesn't define how multipart messages should be handled; Cullen and I
try to move this forward a bit with draft-jennings-sipping-multipart-02.txt.

The SDP session -- which is "m=message" in the application/sdp bodypart --
would still be accepted at the SDP level.

-d

---

From: Miguel Garcia <[email-masked]>
Date: Sun, 16 Jul 2006 10:41:30 +0300

Hi Paul:

Thanks for your comments. I will start with a clarification on the 
terminology. We need to distinguish between the MSRP session, which is 
identified by the 'session-id' in the MSRP URL, and the TCP connection.

The draft says that one file equals one MSRP session, and refers to the 
MSRP draft for handling TCP connections. The MSRP draft says that TCP 
connections can remain open if other MSRP sessions can use it. I believe 
this is allows the reuse of the TCP connection for sending future files, 
which is the desired effect. The MSRP session-id will be new in each new 
file transfer, to simplify handling of files. At the end of the day, if 
you want to send a second file, you always need to do a re-invite 
including the new parameters. So I don't think there is a benefit on 
keeping the MSRP session constant across different files.

Note that an additional MSRP session used for chatting will be a 
different MSRP session than the one used for file transfer, but still 
both can share the same TCP connection.

Hope this clarifies the idea. I guess we need to add a bit more of 
wording in Section 6.5 to better express the concepts. We'll do it in 
the next version of the draft.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jul 2006 10:39:56 -0400

> connection, which is the TCP connection Bob and Alice are using for the 

So, how would you see that working if Alice and Bob have established an 
MSRP session for chatting, and then Alice decides to send Bob a file?

Would you have a reINVITE with an offer that adds a second MSRP session 
for the file transfer, in addition to the one present for chatting? (I 
agree that should work ok, and be able to reuse the existing connection 
if the offer is suitably structured.)

If so, then once the file is transferred, what happens? You say the 
session should be ended? By that I suppose you mean that another 
reINVITE is used to eliminate it? Is there any advantage to that over 
just leaving it until an offer/answer exchange is needed for some other 
reason?

If a number of files are to be transferred, it seems like there are two 
choices:
- send one offer with many m-lines setting up an independent session for
   each file. Then the files can all be transferred in parallel, probably
   over the same connection.

- send the files serially. Offer one, then make another offer that
   replaces the m-line for the first file with one for the next file,
   etc.

These could both work, but have different impacts. Implementors can 
choose which to use when initiating a request, but will have to be 
prepared to handle receiving either kind.

	Thanks,
	Paul

>> the transfer is complete. I think it would be helpful if you would 
>> just not terminate the session after transmission of the file.
>>
>> session and are busy chatting. Alice then decides to send a file to 
>> Bob.  I think Alice can just send a reINVITE, adding the attributes 
>> describing the file transfer to the existing m-line for the MSRP 
>> session used for chatting. Upon completion of the reINVITE, Alice can 
>> then send the file on the same session. Meanwhile Alice and Bob can 
>> also continue to use it for chatting. Effectively, the a-lines specify 
>> special handling for a message that matches the attributes in the 
>> a-lines, while leaving any other messages to be processed normally.
>>
>> This of course in no way prevents establishing a new MSRP session for 
>> a file transfer if so desired.
>>
>>     Paul
>