[Standards] Proposed XMPP Extension: Jingle HTTP Transport Method
lancestout at gmail.com
Thu Aug 27 02:38:35 UTC 2015
> I don't see this XEP resolves any of these.
That is correct.
However, this XEP was never intended to solve those issues, in the exact same way that no other Jingle transport (IBB, SOCKS5, ICE, raw UDP, etc) is intended to directly solve those problems. These are things that apply to *all* Jingle session types, not just file transfer, independent of transport mechanisms.
This XEP is not to be confused with the HTTP upload storage slot proposal (http://xmpp.org/extensions/inbox/http-upload.html), which addresses the problem of provisioning and populating some URIs in the first place, a related but different problem from exchanging and negotiating how those URIs will be used by a peer (which is the purpose of this XEP). A client using a Jingle HTTP transport is very likely to first use the HTTP slot provisioning process in order to have URIs it can then use for Jingle negotiation.
The impetus for this XEP indeed was to allow clients to use Jingle FT with the proposed HTTP storage slots, and at the same time provide a simpler implementation target for JingleFT (don't need to implement the transport complexities of IBB/SOCKS5/ICE, just the basics of Jingle session management).
> 1) How is it possible to get several URLs during HTTP Upload? For
> example, an HTTP server may generate previews and return
> them with the main URL. This is done in a lot of pics hostings and is
> very handy for a client.
What happens happens to data after the Jingle transfer has completed is beyond the scope of a transport mechanism.
As far as a client using a Jingle HTTP transport is concerned, the URIs might as well be considered one-time-use. There is no requirement or guarantee made by this XEP that a URI be usable after the session has ended. That is left to whatever mechanism is used to provision the URIs in the first place (e.g. HTTP upload slots).
Negotiating the uploading of multiple files should be done with multiple Jingle contents as described in XEP-0234, in which case you would have a single upload URI for each.
> 2) How is it possible to offer HTTP Download (see 7.1) with multiple
> files and some of those are thumbnails? So, for example, a receiving
> entity sees a thumbnail first and downloads the original content if she
> likes it.
This is addressed by XEP-0264 (File Transfer Thumbnails), but it does have some limitations in its current form. Namely, it requires the use of XEP-0231 (Bits of Binary) for retrieving the thumbnail data, which limits their use.
To that end, I submitted an update to XEP-0264 today to get it out of the Deferred state, allow it to use other URI types, and expand its scope to more than just file transfer thumbnails (for example, attaching a thumbnail preview to RTP video streams). A rendered version of the PR is available at http://legastero.github.io/customxeps/extensions/xep-0264.html.
> 3) How this XEP can be combined with MUC? Let's say a client did HTTP
> Upload, how will it share the URL in MUC? Will it use procedures from
> 7.1 directly to MUC room jid?
Use within MUC is an issue with any Jingle session type and transport. XEP-0358 (Publishing Available Jingle Sessions, aka JinglePub) is intended as a solution for that problem. JinglePub works via a similar mechanism as what is proposed in https://github.com/processone/ejabberd-saas-docs/blob/master/xmpp-specs/http-filetransfer/http-filetransfer.md, but is usable with any type of Jingle session.
> 4) How this XEP can be used when a user wants to share an HTTP Uploaded
> URI with an offline contact?
Starting a Jingle session with an offline user is naturally an issue with any Jingle session type. Using XEP-0353 (Jingle Message Initiation) or XEP-0358 in combination with XEP-0357 (Push Notifications) is intended as a foundation for a general solution.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4115 bytes
Desc: not available
More information about the Standards