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

Philipp Hancke fippo at goodadvice.pages.de
Tue Oct 21 13:46:37 UTC 2014

Am 08.10.2014 18:33, schrieb XMPP Extensions Editor:
> This message constitutes notice of a Last Call for comments on XEP-0332 (HTTP over XMPP transport).
> Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks.
> URL: http://xmpp.org/extensions/xep-0332.html
> This Last Call begins today and shall end at the close of business on 2014-10-21.
> Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?

I'm not sure. Tunneling http semantics over an xmpp connection seems 
like a useful thing sometimes, but I think the approach described here 
is a very complicated way of doing this.

> 2. Does the specification solve the problem stated in the introduction and requirements?

I had a very hard time to understand the problem and requirements.

> 3. Do you plan to implement this specification in your code? If not, why not?

no. Reviewing just so I can make a decision in the council meeting.

> 4. Do you have any security concerns related to this specification?
> 5. Is the specification accurate and clearly written?

I don't think so.

> Your feedback is appreciated!

section 1:
 > The XMPP protocol however does not have the same problems as HTTP in
 > these regards. It's a peer-to-peer protocol naturally allowing
 > communication with applications and devices behind firewalls

Well no. I prefer the text from 
https://tools.ietf.org/html/rfc6120#section-2.5 about being logically 
p2p here.

 > through established friendship relationships.

We don't call being on someone else's roster and having a presence 
subscription "friendship" in XMPP.

section 2:
I fail to see where the requirement for the server to have a web server 
is used.

section 3:
RFC 2616 has been obsoleted by RFC 7230 et al in the meantime. Using 
some of the terminology from 
http://tools.ietf.org/html/rfc7230#section-2.3 might make things clearer.

section 4:
editorial: can the amount of bold face reduced please?
style: I prefer text along the lines of
	the requesting entity MUST send an IQ stanza of type "get",
	containing an empty <query/> element qualified by the
	'http://jabber.org/protocol/disco#info' namespace, to the JID
	of the target entity
(from xep-0030)

 > Xml content embedded in the XML telegram

XML stanza? Used several times.
ed: avoiding different ways of capitalizing XML helps the reader.

 > Motion JPeg

ed: Motion JPEG seems to be the most common capitalization.

 > 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.

I still don't think that including a flag in every request is the right 
way to convey client capabilities.

 > The client can disable the use of ingle

ed: s/ingle/Jingle/

section 4.1.2:
 > Note: The XMPP/HTTP bridge at the server

Well, it's not at the server, it is located at httpserver at clayster.com
"XMPP/HTTP bridge" should be explained in the glossary. I think the 
terminology from RFc 7230 might be helpful here.

(general remark: I think using company names in those examples will 
limit adoption)

in 4.2.7:
 > 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.

I've said that before: this is not how jingle or ice works.

RFC 2616 has been obsoleted by 7230. While 2818 is just updated, I think 
it's better to reference 7230. Note that the definitions seem to have 
changed, see http://tools.ietf.org/html/rfc7230#section-2.7.1 and 2.7.2

example 18:
    httpx_URL = "httpx:" "//" resourceless_jid [ abs_path [ "?" query ]]

We call this a "bare jid" usually.

In general, relying on the terminology of 
http://tools.ietf.org/html/rfc7230#section-2.3 I do not see why a new 
uri scheme is needed instead of considering this a "tunnel" intermediary 
(which I do not think the approach outlined in the XEP does).
Further, it is not clear to me how the requests for this look like. Is 
the "xmpp/http bridge" preconfigured like a proxy?

I suspect that httpx://user@host has some undesired consequences since 
this consitutes an authority component (because of the //) and hence the 
part before the @ is to be interpreted as userinfo instead of being part 
of the JID.

 > Friendship requests

See above.

 > If not in the roster, the browser needs to send a friendship request

Why? This whole section seems to presume XMPP-based communication 
between the browser and the httpx server. Whereas section 4.1 was 
talking about bridging.

There are privacy concerns related to exchanging presence with sites 
"browsed" by the user.

Section strongly reminds me of the use-cases Dirk Meyer had been 
doing. It's not clear to me how this relates to the stuff in 4.1

 > If the following design rules are followed

I don't think so. How does the client route the <iq/> stanzas to the 
server if it can not specify the full resource in the URI?
I'd note that disco/caps might help here, presuming there is a presence 
subscription. Describing this is probably the most important part of 
doing httpx and it is missing.

Section 6.1:
 > However, in the HTTP over XMPP case, there are no connections between
 > the client and the server. Both clients and servers have active
 > connections to the XMPP Server

This would have been a very good thing to say in the very beginning. So 
this specification is not about bridging http and xmpp. Or is it?

 > The HTTP over XMPP tunnel is just a tunnel of HTTP over XMPP

I don't think that what is described here can act as a "blind relay", 
see the many notes about the body.

 > returning the sime kind of response

ed: s/sime/same/

 > the headers are consumed by web servers and web clients

those web servers and web clients both having an xmpp connection? A 
picture of the architecture in the introduction would be somewhat helpful.

in 6.4:
 > bandwidth resitrctions

section 7:
 > HTTP clients or HTTP servers handle rosters internally

HTTP clients and servers dont have a concept of rosters. There is a 
distinction between the xmpp and http responsiblities of the entities 
involved here, but it's not clear from the text.

 >  friendship request

presence subscription request

 > It is assumed that by entering the URL, or using the URL of an
 > application already displayed, this implies giving permission to add
 > that JID as a friend to the roster of the browser.

That assumption is a very bold one. By browsing a website I never expect 
to give it PERMANENT access to my presence.

What are the implications of communicating with entities not in the 
roster? This seems like an attempt to workaround servers that do not 
allow the exchange of iq stanzas without a presence subscription.

This section describes access control on the "http" server. Those access 
controls are based on the xmpp jid of the requestor.
I suppose that the http rfcs describe similar access control mechanism 
in some kind of framework already?

 > To avoid bloating the roster, friendship requests could be
 > automatically unsubscribed once the HTTP session has ended.

We have something called exchange of directed presence in xmpp. To me 
this suggests that using presence subscriptions here is wrong.

section 8:
If the XSF is supposed to do the registration, then I suppose the 
registrar will be the contact and change control is by the council.

It also seems that the IANA knows a httpx already:
It's not a registered uri scheme -- 
http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml -- not 
sure if they would allow this.

More information about the Standards mailing list