Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method
Le mercredi 19 août 2015, 15:44:30 XMPP Extensions Editor a écrit : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Jingle HTTP Transport Method > > Abstract: This specification defines two Jingle transport methods for > establishing HTTP connections for either uploading or downloading data. > > URL: http://xmpp.org/extensions/inbox/jingle-http-transport.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP. Hello, I think this protoXEP was forgotten, and I'm actually interested in it. Is it possible to update its status ? Thanks Goffi ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method
Wed, 26 Aug 2015 19:38:35 -0700 Lance Stout wrote: > 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. Looks nice, thank you. I wish Council would accept the changes despite Marcus (the author) is inactive for a very long time. > 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. An example for a MUC case would be appreciated. From the XEP I understood nothing. Also, how will this interact with legacy clients (old unsupported XMPP clients, mostly 95% of all clients)? In the case of HTTP Upload any client will be able at least to see the link and download the file. > 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. I don't think XEP-0353 (Jingle Message Initiation) will help because it requires the initiator to be available in order to receive message-accept which is not always the case. I'm not sure if XEP-0357 (Push Notifications) may help here, I thought it was designed for a different purpose.
Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method
> 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. - Lance smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method
Wed, 26 Aug 2015 16:48:41 +0200 Kim Alvefur wrote: > Didn't Jingle File Transfer support transfer of multiple files? OK, probably it does. But it's still unclear how this will interact with thumbnails. As I understand several files will be rejected at the first step (only thumbnails are allowed), then, if a receiver desires, the process should be repeated or what? > As for sending a thumbnail, there is a XEP for that: > http://xmpp.org/extensions/xep-0264.html Deferred and supports bob only. > Some of those are things that could be described in different XEPs > that may or may not have been written yet. But why should we write tons of XEPs which leads to overengineering when we could just improve HTTP Upload proto-XEP?
Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method
On 2015-08-26 16:36, Evgeny Khramtsov wrote: > Wed, 19 Aug 2015 15:44:30 + (UTC) > XMPP Extensions Editor wrote: > >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Jingle HTTP Transport Method >> >> Abstract: This specification defines two Jingle transport methods for >> establishing HTTP connections for either uploading or downloading >> data. >> >> URL: http://xmpp.org/extensions/inbox/jingle-http-transport.html >> >> The XMPP Council will decide in the next two weeks whether to accept >> this proposal as an official XEP. >> > > I have several question on the XEP: > > 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. Didn't Jingle File Transfer support transfer of multiple files? > 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. As for sending a thumbnail, there is a XEP for that: http://xmpp.org/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? > 4) How this XEP can be used when a user wants to share an HTTP Uploaded > URI with an offline contact? > > I don't see this XEP resolves any of these. Some of those are things that could be described in different XEPs that may or may not have been written yet. -- Kim "Zash" Alvefur signature.asc Description: OpenPGP digital signature
Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method
Wed, 19 Aug 2015 15:44:30 + (UTC) XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Jingle HTTP Transport Method > > Abstract: This specification defines two Jingle transport methods for > establishing HTTP connections for either uploading or downloading > data. > > URL: http://xmpp.org/extensions/inbox/jingle-http-transport.html > > The XMPP Council will decide in the next two weeks whether to accept > this proposal as an official XEP. > I have several question on the XEP: 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. 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. 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? 4) How this XEP can be used when a user wants to share an HTTP Uploaded URI with an offline contact? I don't see this XEP resolves any of these.
