Subject: [xmpp] xmpp over websocket

From: Jack Moffitt <[email-masked]>
Date: Fri, 10 Dec 2010 11:41:20 -0700

I have just submitted draft-moffitt-xmpp-over-websocket-00 to define
the XMPP sub-protocol for WebSocket:
http://www.ietf.org/id/draft-moffitt-xmpp-over-websocket-00.txt

Eric Cestari did the original work, and he's got an implementation of
most of this already working with ejabberd. This is something the XMPP
community will need in the near future, and I plan to implement this
in my own client libraries as soon as WebSocket itself gets a little
more nailed down.

I'd appreciate opinions on the draft as well as some guidance as to
whether this work is better placed in the HyBi or XMPP WGs.

jack.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Fri, 10 Dec 2010 19:54:02 +0100

Hi Jack,

> whether this work is better placed in the HyBi or XMPP WGs.

Excellent news and thanks to Eric and you for that proposal. Going through
it quickly, I was wondering what the rationale was about this:

"Each XMPP stanza MUST be sent in its own message.  A stanza MUST NOT be
split over multiple messages."

Also, which version of the WebSocket protocol have you based the XMPP
sub-protocol?

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

---

From: Matt Miller <[email-masked]>
Date: Fri, 10 Dec 2010 12:02:06 -0700

On Dec 10, 2010, at 11:54 , Sylvain Hellegouarch wrote:

> Excellent news and thanks to Eric and you for that proposal. Going through it quickly, I was wondering what the rationale was about this:
> 
> "Each XMPP stanza MUST be sent in its own message.  A stanza MUST NOT be split over multiple messages."
> 

This restriction means JavaScript XMPP applications and libraries can easily use the browser's built-in XML parser, which makes it easier to implement said applications and libraries.

Personally, I've already written or worked on enough XML parsers, I don't want to have to do another if I don't have to (-:

- m&m

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 10 Dec 2010 12:05:10 -0700

> split over multiple messages."

Many developers run into problems when first trying to parse XMPP such
as never testing for the case where multiple stanzas come in a single
read() or when only a part of a stanza comes in a single read(). This
is an easy way to make it as easy as possible.

I'm not sure the current state of browser-based XML parsing, but early
XML libraries all suffered from not being adequate for stream parsing.
 Putting each stanza in its own message means that it's possible to
get around this limitation by parsing each message as its own document
(except of course the start and end tag messages, which are easy
enough to recognize).

> Also, which version of the WebSocket protocol have you based the XMPP

We reference -03 in this draft. We will update the draft when new
WebSocket drafts are released.

I believe Eric's implementation is not public, and I'm not sure what
version of WebSocket he developed against.  Except for the mentions of
control frames, this draft should be pretty applicable to -76
implementations.

jack.

---

From: Justin Karneges <[email-masked]>
Date: Fri, 10 Dec 2010 11:21:43 -0800

> whether this work is better placed in the HyBi or XMPP WGs.

Looks like websocket support is being removed from browsers:

http://www.webmonkey.com/2010/12/security-flaws-force-firefox-opera-to-turn-off-
websockets/

I'm not close enough to the issue to understand why this is being done, but 
I'm bringing it up in case it is relevant.

-Justin

---

From: Eric Cestari <[email-masked]>
Date: Fri, 10 Dec 2010 20:42:36 +0100

> control frames, this draft should be pretty applicable to -76

My implementation is indeed based on -76. 
I will maintain compatibility with the most recent browser support I can get my hands on.

Eric

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 11 Dec 2010 03:21:54 +0100

> is an easy way to make it as easy as possible.

Honestly I cannot consider this a good argument. A developer must know
how TCP works and cannot assume that each TCP message contains a
single request/response of the protocol on top of TCP (XMPP here, but
could be HTTP, SIP or whatever). Making the life easier to bad
developers should not be the aim of a well designed protocol.

However in this case (XMPP over WebSocket) such constrain makes sense
(IMHO) as the WebSocket client (the web browser) already handles the
message defragmentation (at TCP and WebSocket level) so a third
defragmentation makes no sense (neither spliting a XMPP stanza into
various WebSocket messages, neither storing various XMPP stanzas in
the same WebSocket message).

Just my opinion. Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 10 Dec 2010 20:45:09 -0700

> developers should not be the aim of a well designed protocol.

It is not the aim, but if it can be done without any harm, why not? It
is also fairly consistent with the spirit of WebSocket itself, which
is not to be constrained by what is in reach for naive developers, but
not to add complexity or difficulty where it is unnecessary. I think
what is specified is the simplest possible framing.

There is also the secondary reason that it may be necessary for
efficient parsing in JavaScript, at least with today's available
browser APIs, though we won't know this for sure until we have a few
people implementing it and reporting their results.

jack.