[Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
Version 0.4 of XEP-0332 (HTTP over XMPP transport) has been released. Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. Changelog: [See revision history] (pw) Diff: http://xmpp.org/extensions/diff/api/xep/0332/diff/0.3/vs/0.4 URL: http://xmpp.org/extensions/xep-0332.html
Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
hey Peter, Thanks for your comment. Just wanted to point out the possibility as such, even though it would probably not be used by the web server. Since content is normally returned based on query parameters and request headers, the actual content selection would probably be made by the underlying web server, and it would return the corresponding stream. But since there are formats including multiple streams, my thought was to point out the possibility of using this fact, as a possibility to optimize performance in such cases. My point is that using the "first candidate" not going to work. ICE (and probably jingle socks5 clients) can select any candidate and will usually choose the one with the minimal RTT. urn:xmpp:jingle:apps:rtp:1 content descriptions are probably not what you want as an example either -- unless you're transporting things like RTSP (and in that case I doubt we could use jingle:rtp). Copying an example from http://xmpp.org/extensions/xep-0234.html might be better. And I noticed something else: > The client can disable the use of ingle by the server, by including a > jingle='false' attribute in the request. jingle is enabled by > default. On constrained devices with limited support for different > XEP's, this can be a way to avoid the use of technologies not > supported by the client. This is not the XMPP (or rather: stack-of-things-that-builds-on-RFC-6121) way to do it. The gateway should know (or look at) the entity capabilities (or disco#info) of the client. If the client does not have a jingle capability because it is a constrained device, the client should not show that capability. What do you refer to, when you say the "new jingly-pub stuff"? http://xmpp.org/extensions/inbox/jingle-pub.html -- it is not even published yet. Basically sipub with jingle as transfer method.
Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
Hello Philipp Thanks for your comment. Just wanted to point out the possibility as such, even though it would probably not be used by the web server. Since content is normally returned based on query parameters and request headers, the actual content selection would probably be made by the underlying web server, and it would return the corresponding stream. But since there are formats including multiple streams, my thought was to point out the possibility of using this fact, as a possibility to optimize performance in such cases. What do you refer to, when you say the "new jingly-pub stuff"? Best regards, Peter Waher -Original Message- From: Philipp Hancke [mailto:fi...@goodadvice.pages.de] Sent: den 21 augusti 2014 07:58 To: standards@xmpp.org Subject: Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport) Am 13.08.2014 18:12, schrieb XMPP Extensions Editor: > Version 0.3 of XEP-0332 (HTTP over XMPP transport) has been released. > > Abstract: This specification defines how XMPP can be used to transport HTTP > communication over peer-to-peer networks. > > Changelog: [See revision history] (pw) > > Diff: http://xmpp.org/extensions/diff/api/xep/0332/diff/0.2/vs/0.3 > > URL: http://xmpp.org/extensions/xep-0332.html > one thing I noticed: Using Jingle in this way makes it possible for an intelligent server to return multiple streams the client can choose from, something that is not done in normal HTTP over TCP. The first candidate should however correspond to the same stream that would have been returned if the request had been made using normal HTTP over TCP. That is not how candidates or ice work. You want either multiple contents or the new jingle-pub stuff.
Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
Hello Matthew Thanks for your input. My responses to each one of your comments, below: >Two small comments: > > 1) I see the examples have been fixed for streamid -> streamId. >However it's worth noting that we've always conventionally used lowercase >attributes and element names in XMPP. I've noted a mix of syntaxes in different XEPs. Is there some kind of syntax convention extensions should adhere to? I know this has been discussed somewhat earlier. Haven't seen one, however. If the XSF wants to streamline syntax in new XEPs, it might be a good idea to start some kind of discussion regarding this, and include some guidelines in XEP-0001. Personally, I've tried to use camel casing for attributes in all XEP's I've written myself. The main reason for this, is not style as such, even though it is easy enough to read, but to avoid the hyphen sign (-), which is often used as an alternative to separate words where lower-case-only names are used. The hyphen sign does not map well into other scripting languages, etc., and creates a lot of extra work, if you want to do more with the XML and schema, than simply use it for documentation, streaming and validation. (Other examples might be transformation between versions or formats, automatic code generation, searching, mapping in script, etc.) > 2) Servers that don't route messages in order are violating > http://xmpp.org/rfcs/rfc6120.html#rules-order - though we've ended up with > similar attributes in XEP-0047 and XEP-0301, so there is some precedent. Also > both these XEPs call the attribute 'seq', another opportunity for consistency. > >Regards, >Matthew Ok. Is this important to change? I would prefer not to change this, since there are various distributed solutions already in the field, and I would like to avoid making breaking changes, unless they improve or add functionality. But the comment still raises a valid point: Should the XSF maintain a list of (commonly) used attributes and attribute names to promote reuse of the same? Best regards, Peter Waher
Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
Am 13.08.2014 18:12, schrieb XMPP Extensions Editor: Version 0.3 of XEP-0332 (HTTP over XMPP transport) has been released. Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. Changelog: [See revision history] (pw) Diff: http://xmpp.org/extensions/diff/api/xep/0332/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0332.html one thing I noticed: Using Jingle in this way makes it possible for an intelligent server to return multiple streams the client can choose from, something that is not done in normal HTTP over TCP. The first candidate should however correspond to the same stream that would have been returned if the request had been made using normal HTTP over TCP. That is not how candidates or ice work. You want either multiple contents or the new jingle-pub stuff.
Re: [Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
On 13 August 2014 17:12, XMPP Extensions Editor wrote: > Version 0.3 of XEP-0332 (HTTP over XMPP transport) has been released. > > Abstract: This specification defines how XMPP can be used to transport HTTP > communication over peer-to-peer networks. > > Changelog: [See revision history] (pw) Two small comments: 1) I see the examples have been fixed for streamid -> streamId. However it's worth noting that we've always conventionally used lowercase attributes and element names in XMPP. 2) Servers that don't route messages in order are violating http://xmpp.org/rfcs/rfc6120.html#rules-order - though we've ended up with similar attributes in XEP-0047 and XEP-0301, so there is some precedent. Also both these XEPs call the attribute 'seq', another opportunity for consistency. Regards, Matthew
[Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
Version 0.3 of XEP-0332 (HTTP over XMPP transport) has been released. Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. Changelog: [See revision history] (pw) Diff: http://xmpp.org/extensions/diff/api/xep/0332/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0332.html
[Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)
Version 0.2 of XEP-0332 (HTTP over XMPP transport) has been released. Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. Changelog: [See revision history] (pw) Diff: http://xmpp.org/extensions/diff/api/xep/0332/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0332.html
