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

[XMPP Extensions Editor]

Version 0.3 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: Corrected and more clearly explained negotiation flows for consistency with XEP-0166 and other Jingle specifications. (psa)

Diff: http://is.gd/nH8

URL: http://www.xmpp.org/extensions/xep-0234.html

[Tim Julien]

One of the first things I'm going to want to do is add ice-udp (we have
a reliable UDP impl) as a transport (and ice-tcp when we get that spec).

Do you envision those negotiations occurring after session-accept, like
Socks5 and IBB in this spec, or before session-accept like in jingle
audio / video over RTP?

-Tim

XMPP Extensions Editor wrote:
> Version 0.3 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: Corrected and more clearly explained negotiation flows for consistency with XEP-0166 and other Jingle specifications. (psa)
>
> Diff: http://is.gd/nH8
>
> URL: http://www.xmpp.org/extensions/xep-0234.html
>

[Dirk Meyer]

XMPP Extensions Editor wrote:
> Version 0.3 of XEP-0234 (Jingle File Transfer) has been released.
>
> URL: http://www.xmpp.org/extensions/xep-0234.html

The caption of example 12 is wrong, the initiator acknowledges
session-accept.


Dirk

--
Only Irish coffee provides in a single glass all four essential food groups --
alcohol, caffeine, sugar, and fat.
-- Alex Levine

[Peter Saint-Andre]

On 05/30/2008 12:14 PM, Tim Julien wrote:
> One of the first things I'm going to want to do is add ice-udp (we have
> a reliable UDP impl) as a transport

Isn't reliable UDP different from UDP? Or would you just negotiate
ice-udp and if your UDP stack provides reliable UDP that would just fall
out from the negotiation?

> (and ice-tcp when we get that spec).

Yes, we need to define that one. It should be pretty straightforward.

> Do you envision those negotiations occurring after session-accept, like
> Socks5 and IBB in this spec, or before session-accept like in jingle
> audio / video over RTP?

Probably before, since they would function just like ICE in the voice
and video examples (start sending candidates even before you receive the
session-accept).

/psa

[Tim Julien]

Peter Saint-Andre wrote:
> On 05/30/2008 12:14 PM, Tim Julien wrote:
>> One of the first things I'm going to want to do is add ice-udp (we have
>> a reliable UDP impl) as a transport
>
> Isn't reliable UDP different from UDP? Or would you just negotiate
> ice-udp and if your UDP stack provides reliable UDP that would just fall
> out from the negotiation?

I'm not sure if reliable UDP would be a new transport type or an
attribute / feature of the current UDP Jingle transports. I think I
would lean towards defining a new transport - if only to register it as
"reliable" as opposed to "lossy".

>
>> (and ice-tcp when we get that spec).
>
> Yes, we need to define that one. It should be pretty straightforward.
>
>> Do you envision those negotiations occurring after session-accept, like
>> Socks5 and IBB in this spec, or before session-accept like in jingle
>> audio / video over RTP?
>
> Probably before, since they would function just like ICE in the voice
> and video examples (start sending candidates even before you receive the
> session-accept).

I've mentioned it before, but just to beat a dead horse - its strange to
me to negotiate the initial transport in different states, depending on
which transport you are negotiating. I find it confusing, and from an
implementation perspective it will probably make things alot more
complicated because being in the ACTIVE state doesn't tell you anything
about whether you have negotiated a transport. Also, this is counter to
all other Jingle specs to date.

From the Jingle spec (166) section 5 (Concepts and Approach), check out
items 3 and 6 in the sequence of events:

....
3. The parties attempt to set up data transmission over the designated
transport method as defined in the relevant specification (e.g., this
may involve sending multiple transport-info actions).
....
6. As soon as the responder determines that data can flow over the
designated transport, it sends to the initiator a session-accept action.

Seems like negotiating initial transport after session-accept breaks that.

>
> /psa
>

[Peter Saint-Andre]

On 06/04/2008 10:08 AM, Tim Julien wrote:
> Peter Saint-Andre wrote:
>> On 05/30/2008 12:14 PM, Tim Julien wrote:
>>> One of the first things I'm going to want to do is add ice-udp (we have
>>> a reliable UDP impl) as a transport
>>
>> Isn't reliable UDP different from UDP? Or would you just negotiate
>> ice-udp and if your UDP stack provides reliable UDP that would just fall
>> out from the negotiation?
>
> I'm not sure if reliable UDP would be a new transport type or an
> attribute / feature of the current UDP Jingle transports. I think I
> would lean towards defining a new transport - if only to register it as
> "reliable" as opposed to "lossy".

Right, that seems appropriate. I hadn't realize that many people have
implemented RFC 908 / 1151, but you learn something new every day. ;-)

>>> (and ice-tcp when we get that spec).
>>
>> Yes, we need to define that one. It should be pretty straightforward.
>>
>>> Do you envision those negotiations occurring after session-accept, like
>>> Socks5 and IBB in this spec, or before session-accept like in jingle
>>> audio / video over RTP?
>>
>> Probably before, since they would function just like ICE in the voice
>> and video examples (start sending candidates even before you receive the
>> session-accept).
>
> I've mentioned it before, but just to beat a dead horse - its strange to
> me to negotiate the initial transport in different states, depending on
> which transport you are negotiating. I find it confusing, and from an
> implementation perspective it will probably make things alot more
> complicated because being in the ACTIVE state doesn't tell you anything
> about whether you have negotiated a transport. Also, this is counter to
> all other Jingle specs to date.
>
> From the Jingle spec (166) section 5 (Concepts and Approach), check out
> items 3 and 6 in the sequence of events:
>
> ...
> 3. The parties attempt to set up data transmission over the designated
> transport method as defined in the relevant specification (e.g., this
> may involve sending multiple transport-info actions).
> ...
> 6. As soon as the responder determines that data can flow over the
> designated transport, it sends to the initiator a session-accept action.
>
> Seems like negotiating initial transport after session-accept breaks that.

OK I will think about that some more, but I need to perform some surgery
on the other Jingle specs first, per list discussion. I think you may be
right but I want to complete those other edits first.

Peter

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