[Standards] Proposed XMPP Extension: Jingle File Transfer

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 13 23:25:11 UTC 2008

Robert McQueen wrote:
> XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> Title: Jingle File Transfer
>> Abstract: This specification defines a profile of the XMPP stream
>> initiation extension for transferring files between two entities.
>> The protocol provides a modular framework that enables the exchange
>> of information about the file to be transferred as well as the
>> negotiation of parameters such as the transport to be used.
>> URL: http://www.xmpp.org/extensions/inbox/jingle-file-transfer.html
> In this example flow, the session initiator appears to be the one who
>  accepts the session. There is no way this can be correct...
> XEP-0166 implies, and this XEP explicitly takes advantage of, the 
> ability to change the description or transport of a content by using
> a content-modify action. It also says that 'content-modify' should be
>  replied to by 'content-accept'. I think both are pretty unsound.
> We should definitely prohibit the ability to change the description -
> I simply don't see any see any situation where this makes sense, and
> it would complicate implementations significantly. Let's have an
> audio call? oh wait, no.. file transfer... oh no... video... wait... 
> whiteboard...! Failure. I also don't see the point of the profile 
> attribute in the first place, and I don't see how changing it would
> ever make any sense either.
> In our implementation, content-modify was *only* usable for changing
> the direction of a stream. This was a change which didn't need an
> action to acknowledge it, just the iq reply, because you can't arrive
> at any serious error/inconsistent state if someone sends to you when
> you don't expect it, or vice versa. You either send, and the other
> end doesn't listen, or the other end is listening, and you refuse to
> send. Whether you're sending/listening or not is just notification of
> intent. Therefore, you either implement the change immediately, you
> ignore it, or change the direction back if you don't like it, so
> there's no need for an action to respond to it.
> So that just leaves transports... if we want to be able to change 
> transports, we really need to define the semantics more clearly. I
> don't think "content-accept" is the right way to acknowledge a
> modification, because it can really confuse the initiator/responder
> roles. Accept should only *ever* go from the responder to the
> initiator, either the session responder sends an session-accept to
> the initiator, or after the session is established, either end can
> send a 'content-add' and expect a 'content-accept' in reply.
> This is the same reason why content-add is prohibited in pending 
> sessions - if the responder added some contents to the session, and
> then sent a session-accept, there would be some contents whose
> initiator was the session recipient, and would strictly speaking
> still be pending acceptance from the session initiator after the
> session was accepted by the session responder, which is unspeakably
> confusing.
> If we start using 'content-accept', let alone 'session-accept' to 
> acknowledge 'content-modify' changing the transport/description, we
> run into the same kind of nonsense. Assuming a session is established
>  between A and B, and we do this:
> A: content-add (lets do some file transfer over TCP/SOCKS/bonghits) 
> ... transport-info, bla bla, failure... B: content-modify (that
> didn't work, lets use IBB) A: content-accept (ok)
> Argh. This file transfer has never actually been accepted by B, its
> only been accepted by A.
> I think we should keep 'content-accept' with the primary meaning it
> has, which implies an acceptance of adding the content, keep
> 'content-modify' for unobjectionable notifications of changes to the
> direction, and we should do something else for changing transports.
> Unfortunately I don't really know what that is - one idea I had was
> some way to replace a content with another, but that still has the
> same confusions if the session responder wants to change the
> transport before the session has been accepted.

This sounds like a topic to discuss at the devcon in Brussels. :) IMHO,
using a high-bandwidth connection (a.k.a. IRL discussion) would be more
productive than an email list for this topic.

BTW, part of the reason I wrote that file transfer proposal was
precisely to unearth problems like this...


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080213/bbcf505b/attachment.bin>

More information about the Standards mailing list