[Standards] UPDATED: XEP-0332 (HTTP over XMPP transport)

Philipp Hancke fippo at goodadvice.pages.de
Thu Aug 21 18:26:25 UTC 2014

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.

More information about the Standards mailing list