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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
