So, I'm confused about some of the transport negotiation stuff.
In first scenario (section 3.1) the negotiation occurs after session-accept - which is counter to every Jingle spec that has come out so far: typically both <description> and <transport> are negotiated as a pre-requisite to session-accept and going into ACTIVE. (I'll bet it was done this way because content-replace isn't currently allowed in PENDING, even though the other specs are using it there).
In the second scenario (section 3.2) the negotiation occurs before the session-accept. This follows the pattern of previous Jingle specs - but isn't consistent with section 3.1.
I really like the concepts of "Fallback" (3.1) and "Transport Selection" (3.2). Being able to negotiate *which* transport type to use as opposed to just negotiating connectivity within a *one* pre-set transport type. We haven't seen that yet from the other Jingle specs, but I really like it. It's analogous to the listing of multiple <payload-type>'s in Jingle Audio RTP, and both parties agree on one.
-Tim Julien XMPP Extensions Editor wrote:
Version 0.2 of XEP-0234 (Jingle File Transfer) has been released. Abstract: This specification defines a Jingle application type 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. Changelog: Added transport negotiation scenario. (psa) Diff: currently unavailable URL: http://www.xmpp.org/extensions/xep-0234.html
