[xmpp] Websockets: streams or not streams?

[Matthew Wild <[e-mail]>]

Florian Zeitz, Lance Stout, Paul Aurich, Waqas Hussain and myself have
just been having some discussion about the largest remaining open
issue in the websocket draft.

I'll start explaining from the beginning, assuming no prior knowledge,
because we're looking for input from as many people as possible in
order to reach a consensus (ha).

Unlike standard TCP which offers a stream of bytes, websockets provide
"framing", which means that the underlying stream is split into
individual frames.

We had a general consensus early on that it made sense to use these
frames to separate stanzas, which is especially useful because
generally Javascript clients do not have access to a streaming (e.g.
SAX) XML parser which is required for parsing unframed XMPP streams.
With framing, clients could (theoretically) take each frame and parse
it individually as a small standalone document.

However there is some awkwardness in this approach, because the
concept of a stream is quite central to traditional XMPP.

Here are the two questions we have:

1) If stanzas are going to be parsed as standalone documents, can they
inherit namespaces from the stream header like they can in normal
XMPP? Or should we require entities to always explicitly declare
namespaces on stanzas? (this includes for example adding
xmlns="jabber:client" xml:lang="xyz" to every stanza).

2) Should we keep the existing stream open and close mechanisms? They
are not standalone documents, and so websocket clients will still need
to handle them with special code.

Options for #1:

  Including namespaces will allow clients (libraries) to pass the data
in a frame directly into the XML parser they have.

  If we don't include namespaces (the current situation), clients are
resorting to hacks which include:
   - Not handling namespaces properly, perhaps assuming they are
always jabber:client
   - Capturing the stream header, and preprending it to every incoming
stanza by concatentating them together (example at
https://github.com/legastero/stanza.io/blob/master/lib/websocket.js#L59
)

However the concerns about adding namespaces explicitly to every stanza include:
  - Bandwidth increase
  - General noise and mess (look at it from a JSON fanatic's perspective)

Options for #2:

First option (current):

  OPEN:  <stream:stream xmlns:stream="..." xmlns="jabber:client"
id="abc123" xml:lang="en">
  CLOSE: </stream:stream>
  ERROR: <stream:error>...</stream:error>

  Benefits include:
     - Pretty much what we are used to already with traditional XMPP,
which means we are all familiar with it, and don't need to define
drastically new stuff

  Problems include:
    - Open and close are not standalone documents, which complicates
parsing for clients without streaming parsers. Again, this leads to
client hacks which include:
        * Parsing with regular expressions
        * Replacing the > at the end with />

Second option (goal: make everything a standalone document):

   OPEN: <stream:stream xmlns:stream="..." xmlns="jabber:client"
id="abc123" xml:lang="en" />
   CLOSE: ????
   ERROR: <stream:error xmlns:stream="..." xmlns="jabber:client"
id="abc123" xml:lang="en">...</stream:error>

   Benefits:
       - Re-uses what we already have

   Problems:
       - Not clear what we should use to signal stream closure
       - Although it's re-using what we already have, it is
overloading it somewhat (the 'stream' is no longer a stream...)

Third option (let's try a new way!):

    OPEN: <open xmlns="..." id="abc123" />
    CLOSE: <close xmlns="..." />
    ERROR: <error xmlns="http://etherx.jabber.org/streams">...</error>

   Benefits:
       - Clean, simple

   Problems:
       - Quite a departure from traditional streams now
       - Duplicates some things from the 'stream' element

Questions, comments, feedback welcome! It's worth noting that this
issue won't be unique to websockets, but will likely be re-used by any
transports that support framing (SCTP for example).

Regards,
Matthew