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. Regards, Rob
