Subject: Re: [xmpp] XMPP over WebSocket

From: Florian Zeitz <[email-masked]>
Date: Fri, 02 Nov 2012 18:25:03 +0100

On 31.10.2012 23:47, Peter Saint-Andre wrote:
> At the XMPP Summit last week, we talked a bit about XMPP and the
> web, including the I-D that Jack Moffitt has worked on for XMPP
> over WebSocket:
> 
> https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/
>
>  Jack said he thinks it is ready to move forward, and I agreed to 
> shepherd it. I then pinged the HYBI WG and XMPP WG chairs, who 
> appeared to agree that it would be good to discuss the spec on the 
> XMPP WG list and eventually seek cross-WG review from the HYBI
> folks. Does anyone here have feedback on the spec? I know that
> several teams have implemented it, so if you want to see it move
> forward to RFC then please review it and send comments to the
> [email-masked] list.
> 
> Thanks!
> 
> Peter
> 
Hi,

I think this draft is indeed a good starting point, however, based on
current implementations I'd like us to re-evaluate the general approach.

The current approach is sending normal XMPP over a WebSocket
connection. The only thing additionally specified is stanza to message
(in the WebSocket sense) mapping.

The "problem" with this is that this technology is primarily meant for
use with web browsers. Now browsers generally only implement a very
limited XML parser. It's neither a streaming parser, nor can you
easily inject (default) XML namespaces.

This leads to some rather ugly hacks in the implementations I have
seen. Opening stream tags are often ignored, or made self-closing
using some find-replace magic before puting them through the XML
parser. Closing stream tags are handled using string matching for
"</stream:stream>". Stanzas are generally not in the jabber:client
namespace, since no default namespace is set when parsing them. Stream
error handling is either non-existant (i.e. fails because the "stream"
prefix is not bound), or involves more find-replace magic to manually
put the stream namespace declaration in the received character data.

Obviously all of this can be (and is to some extend) dealt with in one
way or the other, but I'm currently thinking we might be better of
using an approach similar to BOSH.
By that I don't mean wrapping everything in a <body/>, but:
a) Having namespace declarations present in each (WebSocket) message
(i.e. xmlns="jabber:client" on each stanza, and
xmlns:stream="http://etherx.jabber.org/streams" on stream errros)
b) Using different signalling for stream (re)start and end (i.e.
something that can be parsed as a document on itself).

What does everyone else think about this?

Regards,
Florian Zeitz

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 2 Nov 2012 14:23:34 -0600

> easily inject (default) XML namespaces.

What we need is the ability to create a DOM object with the correct
namespaces (using the attributes from the opening stream tag) and then
the ability to handle parsing and dealing with prefixes when we insert
nodes into the tree.

Currently BOSH gets around this by copying all the stream attributes
into a body tag, and then adding the correct namespaces onto body
tag's children.

There's no issue with parsing the opening an closing tags though. The
closing tag is a magic token and the attributes of the opening tag are
a regular language which can be unambiguously parsed by regular
expressions. But it is work.

> xmlns:stream="http://etherx.jabber.org/streams" on stream errros)

In general I think this is a good idea. Servers already do it for
BOSH, so I don't think it's a problem to do here. This makes each
message parsable with no saved state.

> something that can be parsed as a document on itself).

This I'm less certain of, but it can certainly be done. We could just
define a new tag that does what BOSH's <body> does, but only for the
open and close tags.

Am I right that the goal here is that the websockets payload always be
parsable XML on its own (ie, no prefix state or hanging or early
terminating tags?

As for restarts specifically, is there a reason these exist in BOSH?
There is no need for the client to be aware of stream restarts is
there? Can we just define them out of the websockets binding and let
the endpoint deal with it?

jack.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 2 Nov 2012 20:45:30 +0000

> the endpoint deal with it?

If stream start and stop are not changed for XMPP/WS, then I'd rather stick closely to RFC 6120 here.  I think much of the existing code is acquiesced to this behavior for other transports anyway.

Part of me would like to parse the messages using the same semantics, and so I would vote in favor of such a change.  But I would not consider this a reason to stop this document's progress.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 2 Nov 2012 20:57:39 +0000

On Oct 31, 2012, at 4:47 PM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> At the XMPP Summit last week, we talked a bit about XMPP and the web,
> including the I-D that Jack Moffitt has worked on for XMPP over WebSocket:
> 
> XMPP WG list and eventually seek cross-WG review from the HYBI folks.
> Does anyone here have feedback on the spec? I know that several teams
> have implemented it, so if you want to see it move forward to RFC then
> please review it and send comments to the [email-masked] list.
> 

NITS:

* Section 4 (Examples) needs to be filled out
* Section 5 (IANA Considerations) needs to be filled out

OTHER:
* Stream Setup, restart and closing

I've stated my position in another reply

* Application-level Redirects

One thing I have noticed that I think needs to be addressed, possibly here: application-level redirects.

RFC 6120 defines the <see-other-host/> stream error condition for this, as a new host/ip and port; however, I don't think this error condition is expressive enough for XMPP over WebSockets ("ws" --> "wss", or a change in path).  BOSH defines the "see-other-uri" for this; but relies on semantics specific to BOSH and not readily applied outside of it.

It's a gap that I think needs to be filled before this draft can progress much further.

- m&m

---

From: Florian Zeitz <[email-masked]>
Date: Sat, 03 Nov 2012 13:26:10 +0100

> expressions. But it is work.
Very true. FWIW the opening stream tag is only regular if you assume the
namespace prefix is fixed to "stream", but that's a fair assumption for
XMPP. Unfortunately it appears most people rather do
s/<stream:stream (.*)[^\/]>/<stream:stream $1\/>/
in order to be able to use a DOM parser.
E.g. WXG (XMPP websocket proxy) even sends (and worse expects) a
self-closing opening stream tag.

I'm of course not saying we should change the draft to accommodate
broken implementations, but the fact that this appears to be common
place (to me anyway) might be an indication that we need to do something™.

> parsable XML on its own (ie, no prefix state or hanging or early
Yes, that is the intention. Or put differently, I'd like to get rid of
magic tokens and regular languages that were originally normal XML.

> the endpoint deal with it?
I think if we are honest no variant of XMPP technically still needs, or
ever needed stream restarts. I'd however be reluctant to deviate from
RFC 6120 on this. I have a hunch it would only make servers and client
implementations not confined to websockets more complicated and error prone.

Regards,
Florian