[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Comments to the TOTE draft
Thanks for the comments, Miguel. Looks like this topic is a contentious
one, for different reasons than I thought. Lots of folks didn't want
info-events, but it looks like lots of folks think we already have
solutions for the media-plane equivalent (file transfer and the
media-ctrl framework).
Responses below:
Miguel Garcia wrote:
> Here are some comments to the TOTE draft:
>
> 1. In the Introduction the draft mentions three general purpose
> mechanisms that allow a pair of agents to communicate data during a
> session. However it fails to name the most relevant work for this draft,
> which is the file transfer mechanism, an MMUSIC WG item:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-06.txt
Sure I am aware of that. I saw that as a specific type of data
communications - file transfer.
>
>
> 2. Then, I believe most of what the draft proposes can be done with the
> above draft. For good or for bad, the file transfer mechanism does not
> really define a new file transfer protocol as TOTE does, but reuses the
> existing MSRP.
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.
>
> 3. I don't think I have seen the requirements for this draft. So, I
> cannot really evaluate why the file transfer mechanism is able to meet
> these requirements, and I cannot evaluate if MSRP is able to meet these
> requirements. The requirements corresponding to the file transfer
> mechanism were posted way back in this draft:
> http://tools.ietf.org/draft/draft-isomaki-sipping-file-transfer/draft-isomaki-sipping-file-transfer-01.txt
The requirements are the same ones driving info-events - the ability to
communicate between agents for new applications without requiring
standardization work. I am merely adding a media-path solution to that
problem.
>
>
> 4. Assuming that there is a need for a new protocol for transferring
> files
TOTE is not about file transfer. See above.
> between to endpoints, I would encourage to re-use existing work.
> In particular, the file transfer mechanism says:
>
> In principle it is possible to use the SDP extensions defined here
> and replace MSRP with any other similar protocol that can carry
> MIME objects. This kind of specification can be written as a
> separate document if the need arises. Essentially, such protocol
> should be able to be negotiated on an SDP offer/answer exchange
> (RFC 3264 [RFC3264]), be able to carry MIME objects between two
> endpoints, and use a reliable transport protocol (e.g., TCP).
>
> For what I read, TOTE will qualify for such alternative protocol, but
> again, we need to understand the requirements that makes the need for
> yet another file transfer protocol.
Interesting. I had missed that bit of the document.
So I think there are a few ways to see how these relate:
1. as you suggest, TOTE could be an alternative to MSRP and you could
continue to use the SDP attributes defined in your draft,
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.
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.
Architecturally, the interesting question I'm posing, is what is our
model for extending SIP to accomodate new media-level things. To date,
it has been about doing SDP extensions for each new thing. This draft
suggests that we don't do that; that we make SIP/SDP minimal and just
set up something else that can do the application-specific protocol
procedures that are optimized for it. This means, you don't need to
upgrade your SIP/SDP infrastructure (since with b2bua they are coupled)
every time you want something new. This is the same aspect that has
attracted people to INFO - I can send new stuff without a new sip
extension. I'd like the same for the media plane.
>
> 5. On a slightly different topic. The draft also mentions Shared
> Browsing. I have recently put a draft that describes how to do
> collaboration between endpoints, and one of the topics is Shared
> Browsing. The draft is this one:
>
> http://www.ietf.org/internet-drafts/draft-garcia-mmusic-sdp-collaboration-00.txt
>
>
> Section 4.2 discusses the topic, and proposes to use the file transfer
> mechanism for sending those URL objects between endpoints.
Yes I did see this, and had a chance to skim. Looking forward to the
discussion.
>
> 6. I've been told that in German language TOTE means DEATH, so, perhaps
> that name should be changed.
lol. Well TOTE worked really nice in English since it means, "to carry"
and that is basically what this does.
-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