[Standards] Proposed XMPP Extension: Jingle File Transfer

Robert McQueen robert.mcqueen at collabora.co.uk
Thu Feb 7 12:37:03 UTC 2008

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.


More information about the Standards mailing list