Subject: [xmpp] New version of XMPP over Websocket draft

From: Lance Stout <[email-masked]>
Date: Sat, 18 May 2013 14:49:28 -0700

I've updated the XMPP over WebSocket draft to include:

- Several examples for establishing the WebSocket connection, closing the
    connection, and performing a stream restart.
- Adjust language for pings to note that XEP-0198 provides a keepalive
    pinging mechanism as well.
- Modify language on closing the connection, noting that the XMPP streams
    should be explicitly closed before closing the WebSocket connection.
- Added recommendation to use XEP-0198 stream management.
- Added note that a server should keep the session alive (based on policy)
    if a connection is closed without closing the streams (XEP-0198).
- Added section on using XEP-0156 to discover the WebSocket connection 
    endpoint. I've emailed the XMPP Registrar to register the
    _xmpp-client-websocket connection method name. I've also asked the XMPP
    standards list about creating a .well-known/ document to supplement the
    method defined in XEP-0156 as browser based clients that will use the
    WebSocket transport can't make the necessary DNS calls.

There do remain several issues that have been discussed at the previous
IETF meeting and the XSF summit last February:

- How to handle instructing the client to connect to a different
    endpoint (e.g., some see-other-uri error condition). If we can
    define a new stream error condition here, then that would be 
    preferable.

- SASL EXTERNAL. What qualifies? Would a user session cookie (normally
    sufficient for HTTP requests) be acceptable? If a user session
    cookie is provided and authorized by the server before accepting
    the WebSocket connection, is SASL auth still needed or can a client
    request binding immediately? (similar to the use of pre-binding in BOSH)

- Compression. As we are using text frames, we can't compress the XMPP
    traffic directly. However, there are other I-Ds working on enabling
    compression for WebSocket message data. Should this be called out now,
    or wait until those I-Ds have progressed?

- IANA consideration: It's fully possible, and maybe even preferable, for 
    a server to provide both BOSH and WebSocket endpoints on port 5280. 
    Should we update the IANA registration for 5280 to be named 
    something more generic than xmpp-bosh?

Other suggestions had been discussed that, after having personally 
implemented an XMPP over WebSocket client, I don't find sufficiently 
compelling for changing the protocol:

- Creating a new stream start/end marker
- Requiring all in-scope namespaces to be declared on top-level stream child elements

Specifically, here's the relevant excerpt to handle the above:

    data = data.trim();
    // Ignore any <?xml ...?> prelude/processing instructions
    data = data.replace(/^(\s*<\?.*\?>\s*)*/, '');
    if (data.match(self.streamEnd)) {
        self.emit('stream:end');
        return self.disconnect();
    } else if (self.hasStream) {
        // Wrap the data with the saved stream start/end tags to
        // preserve namespace and xml:lang contexts
        try {
            streamData = parse(wrap(data));
        } catch (e) {
            // Received invalid XML from the server
            return self.disconnect();
        }
        self.emit('stream:data', streamData);
     } else {
        // Inspect start of stream element to get NS prefix name
        var parts = data.match(/^<(\S+:)?(\S+) /);
        self.streamStart = data;
        self.streamEnd = '</' + (parts[1] || '') + parts[2] + '>';

        try {
            streamData = parse(data + self.streamEnd);
        } catch (e) {
            try {
                // Received stream error while trying to open the stream
                streamData = parse(data);
            } catch (e2) {
                // Received invalid XML from the server
                return self.disconnect();
            }
        }

        self.hasStream = true;
        self.emit('stream:start', streamData);
    }

-- Lance

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-moffitt-xmpp-over-websocket-03.txt
> Date: May 18, 2013 1:47:07 PM PDT
> To: Eric Cestari <[email-masked]>, Jack Moffitt <[email-masked]>, Lance Stout <[email-masked]>
> 
> 
> A new version of I-D, draft-moffitt-xmpp-over-websocket-03.txt
> has been successfully submitted by Lance Stout and posted to the
> IETF repository.
> 
> Filename:	 draft-moffitt-xmpp-over-websocket
> Revision:	 03
> Title:		 An XMPP Sub-protocol for WebSocket
> Creation date:	 2013-05-18
> Group:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-moffitt-xmpp-over-websocket-03.txt
> Status:          http://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket
> Htmlized:        http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-03
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-moffitt-xmpp-over-websocket-03
> 
> Abstract:
>   This document defines a binding for the XMPP protocol over a
>   WebSocket transport layer.  A WebSocket binding for XMPP provides
>   higher performance than the current HTTP binding for XMPP.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 21 May 2013 15:00:20 -0500

(as XMPP co-chair)

Thanks, Lance!

I'd like to remind everyone that XMPP over WebSocket is on our charter. The chairs will shortly call the question about whether this draft should be adopted as a working group draft for that work. I encourage everyone to take a look at the update and discuss it, and think about whether it's on the right track.

Thanks!

Ben.

On May 18, 2013, at 4:49 PM, Lance Stout <[email-masked]> wrote:

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 28 May 2013 22:54:15 +0200

Hey Lance,
good to see you working on this. Some comments inline.

> - Added recommendation to use XEP-0198 stream management.
I feel that this, as well as the recommendation to use XMPP Ping, is
good to have.
However, I'm not sure having this at the RECOMMENDED level is actually
sensible. I would much rather have this as OPTIONAL along with some more
information on why this is useful/important to implement.

>     request binding immediately? (similar to the use of pre-binding in BOSH)
IMHO, if the server is offering SASL EXTERNAL that means "I have some
means of verifying your identity on another protocol level". I think it
is sensible that a server would offer EXTERNAL if it saw a e.g. a
session cookie. I would prefer to keep the SASL auth step, to keep this
in line with the usual XMPP flow.

>     something more generic than xmpp-bosh?
Interesting question. I think that reservation might have become
somewhat bogus over time. 5280 is mostly a "HTTP service provided by a
XMPP server".
E.g. prosody has a general HTTP API which is used to provide different
things, from web-admin, over chat logs to BOSH and websockets all on
port 5280. IIRC ejabberd's web-admin is on 5280, too. Additionally BOSH
is/was often proxied to port 80 to avoid same-origin policy issues.
It might be worthwhile updating the registration, I'm not sure what a
decent description (that actually warrants having a dedicated port)
would be though.

> [snip bunch of javascript]
I disagree, that this is not compelling (Well, I'm sort of bound to,
since those are my suggestions), particularly considering your code example.
With those two changes in place the equivalent client code would amount to:
parser = new DOMParser();
stanza = parser.parseFromString(message, "application/xml");
On top of that it's a 13 line change in Prosody's mod_websocket.

I think it fits our simple client, complex server model a lot better to
have the complexity for making this easy to parse in a web-browser on
the server side.

Regards,
Florian

---

From: Matthew Wild <[email-masked]>
Date: Wed, 29 May 2013 13:55:24 +0100

> have the complexity for making this easy to parse in a web-browser on

I'll also add that while different technically, there is some
precedent for this. Practically all BOSH implementations do this
stamping of stream children already because of <body
xmlns='http://jabber.org/protocol/httpbind'>. Why we don't prefix
<body> I don't know, but that's the way the XEP and today's
implementations are, so I guess the main answer is "historical
reasons" - possibly rooted in poor XML namespace support in browsers
10 years ago.

I say we should jump at the chance to use framing available to us in
the transport while we can. Streaming parsers could still be used (or
more importantly for multi-transport implementations: re-used), and it
removes a contentious issue: many people dislike streaming parsers,
but more worryingly many popular platforms simply don't even have them
available (often leading people to write their own, and get it wrong
and/or complain about XMPP/XML vocally).

Regards,
Matthew

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 29 May 2013 14:44:49 +0000

> and/or complain about XMPP/XML vocally).

I completely agree with taking advantage of framing wherever possible.  While it does not appear to be difficult, I think we're doing ourselves a disservice to continue this practice, particularly where XMPP-friendly streaming parsers are effectively not available.

In that vein, might I suggest the following for opening and closing (WS) stream?

* begin: <ws:open xmlns:ws='urn:ietf:params:xml:ns:xmpp-websocket'
                  version='1.0'
                  to='example.com'
                  from=[email-masked]'
                  xml:lang='en'/>
Basically everything one would expect in a stream:stream.

* end: <ws:close xmlns:ws='urn:ietf:params:xml:ns:xmpp-websocket'/>

- m&m

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

---

From: DOI Yusuke <[email-masked]>
Date: Thu, 30 May 2013 01:08:32 +0900 (JST)

Dear Matt,

From: "Matt Miller (mamille2)" <[email-masked]>
Subject: [xmpp] Take advantage of framing [WAS: New version of XMPP over Websocket draft]
Date: Wed, 29 May 2013 14:44:49 +0000

> * end: <ws:close xmlns:ws='urn:ietf:params:xml:ns:xmpp-websocket'/>

Peter Waher and I have had similar (almost identical) discussion on
EXI encoding because bit-packed EXI also has a problem on streaming. I
think we can share the same definition of the open/close marker if
they are transport agonistic (e.g. not placed under ws: namespace).

Regards,

Yusuke

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 29 May 2013 16:20:20 +0000

> they are transport agonistic (e.g. not placed under ws: namespace).

Personally, I think I have a slight preference for a transport-specific mechanism, but that could just be for reasons of precedent.  As long as something gets defined that is usable for WebSocket.

- m&m