Re: [Sip] Comments to the TOTE draft

[Jonathan Rosenberg <jdrosen at cisco.com>]

inline:

Miguel Garcia wrote:

>> I think its the MIME bit that has gotten lots of folks in a tizzy 
>> here. I think, you are thinking, "MIME object = file" and so this 
>> draft is basically doing file transfer. But really its about these 
>> "purposes", and a purpose can be a mini-protocol and not really a file 
>> transfer in any sense of the word. Would you use the file transfer 
>> draft above to exchange camera controls? I didnt think so.
> 
> If it is about a single camera control then it is possible to do it. But 
> if the camera control is some sort of continuous interaction, then I 
> would probably not use the file transfer, but just vanilla MSRP with the 
> appropriate content type.

Ah, so there are two parts of this discussion:

1. whether MSRP is to be used as a general transport of stuff between 
agents, which is not strictly instant messaging (like camera controls)

2. regardless of MSRP vs. something else, when would one use the file 
transfer mechanism and when not


Frankly I don't think you'd ever use the file transfer mechanism for 
camera controls, even a one-shot. Most of the file selector attributes 
don't make sense here - size, filename, hashes - these are useful 
primarily for transfering an existing stored file, not for carrying 
arbitrary protocols.

So then the question is, is MSRP a general purpose UA to UA transport 
mechanism, or not. Frankly I think it is not. Its designed around 
instant messaging which is a particular application. ITs having 
extensions for things like nicknames and conferencing which are specific 
to IM. The reporting feature is also IMHO very much an IM-specific thing.

File transfer is arguably very close to IM and can benefit from much of 
what MSRP provides; chunking and interruption all make sense because 
these are big objects.

TOTE proposes a much more lightweight transfer mechanism for general UA 
to UA protocols/applications.

>
>> 2. the file transfer spec very much couples the negotiation of the 
>> file transfer itself (parameters of the file along with an indication 
>> of willingness) with O/A. We have been burned by this before, when 
>> we've tried to take negotiation things and couple them to the O/A 
>> exchange. Security key negotiation is an example. We found, in the 
>> end, by doing it in the media path we had more flexibility and were 
>> not limited to a two-way handshake. So another way to think of it, is 
>> this, would you benefit from separating the file transfer negotiation 
>> from O/A itself? Would you benefit from more round trips or more 
>> complex objects that are hard to place in SDP? I for one always 
>> thought file trnasfer is best done as a 4-way:
>>
>> A->B want to send file, here are characteristics
>> B->A yes, please send
>> A->B ok here is the file
>> B->A got it
>>
>> basically the file transfer is doing the first two in O/A and the last 
>> two in MSRP, so it kind of works. But I wonder if you had more 
>> flexibility would we get a feature or capability that would be 
>> impossible otherwise. For example, the ability of the recipient to 
>> cancel mid-transaction, or to tell the sender to pause and resume. If 
>> we went this route, you'd basically take your existing SDP attributes, 
>> take them out into a standalone protocol message and send e2e over 
>> this connection instead.
> 
> Yes, the background for the file transfer draft. It tries to emulate the 
>  file transfer feature that we have in many instant messaging systems. 
> So, the coupling of the file description with the O/A works well in that 
> case. Any of both ends can also abort the file transfer. Both ends can 
> also pause and resume the file transfer.

How do you do pause with MSRP? Specifically, how does the receiver tell 
the sender to pause? How does the receiver cancel?

> 
>>
>> 3. file transfer is for file transfer and tote is for other things 
>> that don't include file transfer; i.e., these look similar but file 
>> transfer has some special needs and that is why we have a specific 
>> spec for it. And so both proceed independently.
>>
> 
> I think the OTE draft should reuse the file transfer draft as much as it 
> could. Dealing with files or MIME objects is a subtle difference. 
> Perhaps the biggest difference is that TOTE tries to create a media 
> stream for transferring a MIME object, while the file transfer draft 
> assume a given protocol (so far MSRP) and a given purpose (a file). But 
> it should be possible for me to offer you a file with either MSRP or the 
> simple TCP connection that TOTE uses without much changes to the SDP.

That last sentence I agree with. However What I don't agree with, is if 
I am not transferring a file, just doing a camera control or somethign, 
that I have to use the file transfer SDP attributes.


-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen at cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip