[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Comments to the TOTE draft
Inline discussion.
Jonathan Rosenberg wrote:
> 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.
That is correct, the draft is specific to file transfer. Now, I don't
want to open a discussion about what is a file versus what is a MIME
object. I think we should focus on the semantics, and what make the file
transfer draft not feasible for the TOTE protocol.
>
>>
>>
>> 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.
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.
>
>>
>> 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.
>
ok, understood.
>>
>>
>> 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.
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.
>
> 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.
>
>
> 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.
>
This is certainly the question. But even with the model that TOTE uses,
you still need to at least register the MIME objects or the underlying
protocol, right? I understand the SDP should not change for any of these
usages that you envision, so you don't need to upgrade intermediaries,
but at least some mnemonic that identifies the protocol should be
>
> -Jonathan R.
/Miguel
--
Miguel A. Garcia tel:+358-50-4804586
Nokia Siemens Networks Espoo, Finland
_______________________________________________
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