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

Peter Saint-Andre stpeter at stpeter.im
Wed May 28 22:58:09 UTC 2008

On 05/21/2008 1:18 PM, Tim Julien wrote:
> So, I'm confused about some of the transport negotiation stuff.

It was sketched out rather quickly and probably needs more work.

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

The other specs have been corrected.

In file transfer especially you might want fallback because SOCKS5
Bytestreams does not provide reliable NAT traversal, unlike ICE. So you
might try XEP-0065 first but then it fails, so you fall back to In-Band
Bytestreams because you know that will always get through (well, almost
always: you might run into rate limiting from your server).

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

Right. Consistency is good, as long as it's not a foolish consistency. :)

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

As I explained above, the hope is that we won't need fallback for audio
or video because we're using ICE-UDP there. File transfer is a bit of a
special case because we have this large deployed base of clients that
support XEP-0065, so we need a way to fall back to XEP-0047. If we all
just used ICE-TCP for file transfer life would be different, but that's
not done yet and it doesn't provide backwards-compatibility with our
deployed base.

That said, I will work on the flows in XEP-0234 so that this is all clearer.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080528/563c148d/attachment.bin>

More information about the Standards mailing list