Re: [Sip] Comments to the TOTE draft

[Paul Kyzivat <pkyzivat at cisco.com>]

Just jumping in, not replying to anyone in particular...

I don't see the relationship between TOTE-like functionality and File 
Transfer at all. But I do see MSRP as an alternative to TOTE for the 
kinds of things Jonathan is proposing TOTE for.

Advantages of using MSRP are:
- its already defined
- it already has all the mime type negotiation defined
- it has some mechanisms to mitigate the head of line blocking issue
- whatever is done to get MSRP through firewalls and proxies
   could be reused for this application
- the exchange of mime objects as envisioned for tote could
   share a connection with IM if IM happens to be in use

Some disadvantages:
- its heavier weight than what Jonathan is proposing
- there may be issues with MSRP relays

The heavier weight of MSRP is an issue for UAs that won't otherwise be 
implementing MSRP anyway. For those that do its probably not an issue. 
OTOH, more uses for the protocol may serve to encourage ubiquitous 
implementation.

The use of relays vs using ICE to get though FWs and NATs has already 
been brought up for MSRP in general I think. Perhaps that needs to be 
considered.

OTOH, the use of media intermediaries of one sort or another for MSRP is 
likely to be required in many cases, at least in enterprises, because 
they have a need to log the stuff for legal or other business reasons. 
It may well be that the same people would conclude that they need to log 
TOTE exchanges too, because it otherwise might be used to tunnel things. 
So it may be that e2e media connections won't be allowed in any case.

Bottom line: I haven't yet decided if I like TOTE or would prefer to see 
MSRP used for that purpose.

	Paul



Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
>> Miguel Garcia
>>
>>> 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.
>>
>> I disagree here. You said:
>> - It is designed around instant messaging: I would say MSRP is designed
>> around real-time transfer of objects. The MSRP draft provides examples
>> and provisions for transferring, for example, large video files.
>> - It's having extensions for things like nicknames and conferencing
>> which are specific to conferencing: I don't see the point here. It is
>> like if you tell me that SIP is not good for voice because there are
>> extensions for presence, instant messaging and alike. MSRP is generic
>> enough to carry objects between two points. Extensions try to improve
>> the user experience for specific applications.
> 
> Not really.  We *DO* say SIP is not appropriate for carrying the voice itself (vs. RTP), or not appropriate for carrying session-based IM (vs. MSRP).  We say that because of SIP's properties compared to the needs/properties of voice or IM or whatever.  I assume we all agree on that.
> 
> MSRP also has properties.  Some of them frankly aren't very good for bulk file transfer, IMHO.  One of those "properties" is it doesn't seem to be getting deployed UA-UA.  It's getting deployed UA-AS-AS-UA, where "AS" is an app server or SBC or both either acting as an MSRP-relay or MSRP-b2bua.  (it shouldn't be a surprise this is happening - the MSRP protocol leaves no other choice)
> 
> I don't think it's a good property that a bulk file transfer gets sent through a chain of app servers.  I don't think it's a good property that camera controls get sent through a chain of app servers.  My 2 cents anyway.
> 
> -hadriel
> 
> _______________________________________________
> 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
> 
_______________________________________________
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