[Standards] Namespaces, specifications, and protocol life cycles
dave at cridland.net
Tue Sep 9 15:36:41 UTC 2008
We currently create new protocols with a "urn:xmpp:tmp:protoname"
namespace. This is useful to avoid collisions, as well as avoiding
incompatible implementations in the wild.
When they pass a certain maturity level, they become
"urn:xmpp:protoname". This is great, but we don't do this until they
pass a maturity level which is often hard to judge without
Moreover, sometimes a section of the community really wants to
implement, but the wider community hasn't quite made up our
collective minds yet. An example of this was XEP-0158, for instance,
and was reminded again while looking through XEP-0198.
So, I'd like to propose we change this a bit:
urn:xmpp:tmp:protoname - we keep this for really early days, probably
stuff that's either still protoXEP or in its first XEP incarnation.
The authors can apply for a namespace from the XMPP Registrar (Peter,
you get to talk to yourself again), who will grant it if he believes
the specification to have obtained a reasonable degree of stability.
That last portion we'll treat as a version number. Any time we cause
incompatibility between versions of the XEP, we update it. (Note,
that's not "every new XEP").
So by the time it moves out of Experimental and to Draft, it might be:
And there it stays - the advantage here is that if the protocol is
stable earlier than its move to Draft - and actually, this is
normally the case, a lot of the pre-draft stuff is specification
wrangling rather than proptocol redesign - people can go ahead and
implement it, and it'll continue to work.
Otherwise, as we get closer to Draft, we're actually putting people
off implementation at the very moment we want to encourage it.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards