The message flow in section 2 (i.e., "happy path") seems good. Only
question I would have is maybe wrap the bytestream / ibb negotiation
messages in jingle transport-info messages. But I can see an argument
against that if the goal is to allow existing implementations to reuse
as much code as possible.
section 3.1 (Transport Selection) seems good, too.
I share your anxiety with Fallback in 3.2 - doing the fallback after
session-accept. Can we modify the PENDING state to allow
content-replace? It seems like we have a real use case for it here.
I can also envision wanting to do fallback like this for anything that
wants to be non-lossy:
ICE-TCP fallback to -> ICE-RUDP fallback to -> IBB
(RUDP = Reliable UDP)
-Tim
Peter Saint-Andre wrote:
On 06/04/2008 4:49 PM, XMPP Extensions Editor wrote:
Version 0.4 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: Harmonized negotiation flows with other Jingle application
types. (psa)
Diff: http://is.gd/r3R
URL: http://www.xmpp.org/extensions/xep-0234.html
I'm not 100% happy with the modified flows, especially in the fallback
scenario (sending session-accept and then content-replace strikes me as
a bit hokey), but I'll think about it some more. Feedback is welcome. :)
Peter
