[jdev] Websockets RFC: stream: prefix required or not?
michael.weibel+xmpp at gmail.com
Tue Feb 3 11:53:22 UTC 2015
Thanks for all the replies. I agree that this should probably be clarified
as the current explanation is not as clear as it should be.
It looks as if you'd need to use the "stream:" prefix for "features" but
you shouldn't/mustn't use it for "error". More examples or writing it in a
better way would help, I assume.
2015-02-03 10:53 GMT+01:00 Hund, Johannes <johannes.hund at siemens.com>:
> > I called this out in 7395 because both stream features and errors
> > traditionally use the 'stream' prefix while relying on the opening
> > tag to define to define the prefix. But for WebSocket there is no parent
> > <stream> tag providing those declarations, and it seemed like an easy
> item for
> > implementors to either miss entirely or do incorrectly like so:
> > // Not define the namespace or prefix at all <stream:features />
> > />
> > // Define the namespace without a prefix, while still using a prefix
> > <stream:features xmlns="http://etherx.jabber.org/streams" />
> > xmlns="http://etherx.jabber.org/streams" />
> > // Stamp 'jabber:client' as the namespace because it has no xmlns
> > <stream:error xmlns="jabber:client" /> <stream:features
> > />
> > — Lance
> Yes, there we saw there is a statement somewhere in the RFC that you
> should use the prefix "stream" ...if you use a prefix.
> I think this confuses many developers, as we have seen implementations
> that refuse fragments as invalid xml if it does not have a prefix (but
> declares the ns for the element) or uses a prefix differently to stream.
> This gives us problems when using EXI, as it will normally just produce
> valid xml. Therefore, it is up to the codec to just assign a namespace to
> any prefix (if necessary). There are flags/codec options defined in the EXI
> standard for exactly this (namespace preservation), but it reduces
> performance (as you have to communicate every use prefix), does not work
> when you build it from a memory representation and is a quirks mode IMHO.
> Maybe it would be good to give some more implementation notes/advice to
> clarify what is valid and what is not?
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the JDev