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 implementation experience.

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.

urn:xmpp:protoname:1

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:

urn:xmpp:protoname:4

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.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Reply via email to