[Standards] File Transfer Roadmap
christian.schudt at gmx.de
Mon Jul 27 08:33:15 UTC 2015
there's another related XEP: XEP-0137: Publishing Stream Initiation Requests.
I am not sure if Jingle File Transfer should cover the following use cases as well, but what I am reading and hearing more and more (in this list, in my company, in forums) are the following two requirements:
1) How to do offline file transfer? (see "HTTP Upload"-XEP)
2) How to send a file in a MUC room to all occupants/members?
I don't think these use cases are properly covered by existing XEPs, maybe XEP-0066 for 1) and XEP-0137 for 2), but still very vague.
I suggested to use JFT for uploading a file to a server (for the offline case, instead of the "HTTP Upload"-XEP approach), but I am still not sure, if JFT is suitable for this.
I think before moving JFT to Draft, the above two questions should be discussed.
Gesendet: Montag, 27. Juli 2015 um 00:33 Uhr
Von: "Sam Whited" <sam at samwhited.com>
An: "XMPP Standards" <standards at xmpp.org>
Betreff: [Standards] File Transfer Roadmap
As I mentioned on the MUC room earlier, I've been investigating the
state of file transfer in XMPP, which has historically been a sticky
point for the protocol (especially where compatibility between different
clients is concerned).
After digging a bit, the following XEP's appear to be related to file
transfer or stream initialization to some degree (please do point out
any that I've overlooked):
- XEP-0047: In-Band Bytestreams (Final Standard)
- XEP-0065: SOCKS5 Bytestreams (Draft Standard)
- XEP-0066: Out of Band Data (Draft Standard)
- XEP-0095: Stream initialization (Draft Standard)
- XEP-0096: SI File Transfer (Draft Standard)
- XEP-0166: Jingle (Draft Standard)
- XEP-0234: Jingle File Transfer (Experimental)
- XEP-0260: Jingle SOCKS5 Bytestreams Transport Method (Draft Standard)
- XEP-0261: Jingle In-Band Bytestreams Transport Method (Draft Standard)
- HTTP Upload (ProtoXEP in PR )
The only real sticking point I can see for obsoleting several of these
XEPs and pushing forward with Jingle as the officially recommended
method is the fact that Jingle File Transfer is still marked as
experimental. However, it is already begining to gain adoption (Gajim,
Conversations, Swift, Stanza.io, Babbler, probably others that I'm
unaware of), while other clients, such as the ever popular libpurple,
tend to refuse to implement XEPs that are still in the Experimental
stage (I'm not sure if that's actually what's happening WRT Jingle File
With that in mind, I'd like to know what the council (and everyone
elses) opinion is of moving Jingle File Transfer forward in the process?
What needs to be done? The last time JFT was discussed (as far as I'm
aware), the only problem was the complaint that the <request/> flow had
been removed, however, Lance pointed out that this was a
reimplementation of existing Jingle semantics  and was planning on
adding a section to describe how this worked in JFT:4.
If this is indeed the only blocker, I'd like to propose the following
roadmap for XMPP file transfer:
- Incorporate Lance's changes to JFT (or, if he is no longer working
on those, I will propose similar changes to describe the plain-Jingle
- Advance Jingle File Transfer to "Proposed" (and then hopefully to
"Draft" shortly thereafter)
- Deprecate XEP-0096 and mark it as obsoleted by XEP-0234
- Evaluate moving XEP-0047, and XEP-0065 fully into XEP-0234, and
XEP0260 (which partially re-describe them) to reduce confusion, or
leaving it alone to reduce work and needless changes.
As I said, I'm happy to drive any or all of this, but want to get some
idea of how people feel about it before attempting any of the work (eg.
are Lance's patches to JFT still being worked on or should I (or anyone
else who has a better grasp of Jingle than I do) take up the torch, will
the XSF ever actually obsolete SI File Transfer or will that be a
down-vote from the get-go at which point there's no reason to work on
it, etc.) Thoughts?
More information about the Standards