[Standards-JIG] Re: WHACK

Robert Norris rob at cataclysm.cx
Wed Apr 26 03:03:24 UTC 2006

> > I wonder how servers handle such things, too. ;-)
> Thus far, Jabber's approach to namespace prefixing has always been:
>   - If the spec is defined to use prefixes, you MUST use them.
>   - If the spec is not defined to use prefixes, then you MUST NOT use them.
> Of course, a proper implementation should be able to receive data in either 
> form, but enforcing a single outbound format leaves room for old/bad/etc 
> implementations to "hard-code" their parsers.

The approach I set out in JEP-0044 and implemented in jabberd2 was that
implementations should be able to accept anything that is allowed by the
XML Namespaces doc, but should try to output using the "traditional"
prefixes to maintain compatibility.

I'd personally continue to recommend the practice of no prefix for
jabber:client and jabber:server, db: for jabber:server:dialback, and
_maybe_ sasl: and tls:. But I'd be loathe to say MUST - its a
restriction that really isn't required.

Besides, if there's projects that are actively implementing new features
but not recognising namespaces, I'd argue that they need to make it more
of a priority - XML Namespaces have been around for seven years now,
most off-the-shelf parsers support them, and if you've rolled your own
parser it shouldn't be that hard to add support.

> In the case of JEP-Ack, what we'd probably want to do is turn the prefix 
> recommendation into a requirement.

I wouldn't even bother with a recommendation - just leave it as is, use
a prefix in the examples, and let the implementations sort it out, same
as every other JEP.


Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060426/61b41d62/attachment.sig>

More information about the Standards mailing list