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 [email protected] 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 [email protected]
"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.
section 4.3.1.1
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.
In 4.3.1.2
> 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 4.3.1.3 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
s/resitrctions/restrictions/
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.
7.1:
> 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.
7.2:
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:
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=80
It's not a registered uri scheme --
http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml -- not
sure if they would allow this.
