[Standards] UPDATED: XEP-0234 (Jingle File Transfer)

[XMPP Extensions Editor]

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

[Peter Saint-Andre]

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

--
Peter Saint-Andre
https://stpeter.im/

[Tim Julien]

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
>

[Peter Saint-Andre]

On 06/04/2008 9:23 PM, Tim Julien wrote:

Could you perhaps refrain from top-posting? It makes the conversation
hard to follow. :)

> 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.

Yes, that was the goal.

> section 3.1 (Transport Selection) seems good, too.

OK, great.

> 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.

Part of why I wrote the Jingle file transfer spec was to see how the
general Jingle state machine would work for more use cases. In the case
of fallback, I think the answer is: not very well. We'd have the same
issue if we tried to do fallback from XEP-0177 to XEP-0176 (say) for an
RTP session. So to me that argues for allowing content-replace during
the PENDING state.

> 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

I *think* you're right. I do wonder about fallback in general, that is:
when do you know that you need to fall back? In the case you show above,
you might try ICE-TCP and it might start to work (you get most of the
bits through) but the file is corrupted because you're missing some
bits. I think you would have accepted the session by that point, but the
transport wasn't as reliable as you would have liked so you basically
need to start over. That's a different case than fallback from SOCKS5 to
IBB, where you try SOCKS5 but your firewall configuration makes it
impossible to use any of the offered streamhosts, so you never get any
bits through and need to try IBB. So I think that fallback applies to
situations where the transport setup simply fails and you need to try a
different transport to get any media flowing at all, rather than the
situation where the transport setup worked (send session-accept) but
then you have subsequent media problems -- in that situation you'd send
a content-replace in the ACTIVE state, whereas in the previous situation
you'd send content-replace in the PENDING state.

Does that make sense?

Peter

--
Peter Saint-Andre
https://stpeter.im/