Here is what I propose in XEP-0053, for a more readable version see
<http://xmpp.org/extensions/tmp/xep-0053-1.4.html#namespaces>...
***
4. Namespace Issuance
The XMPP Registrar shall be responsible for issuing namespaces to be
used in XMPP Extension Protocols (XEPs) developed through the XMPP
Standards Foundation's standards process as specified in XEP-0001. The
policies and procedures for namespace issuance shall be as follows:
1. When a XEP is first published in the Experimental state, the XMPP
Registrar shall work with the author(s) to generate an appropriate
namespace name, which shall be of the form "urn:xmpp:ShortName:0" or,
where appropriate, "urn:xmpp:ShortName:SubName:0". The following
considerations apply:
a. Each name shall adhere to the format defined in RFC 4854 [10].
b. Each name shall be of the form "urn:xmpp:ShortName[:SubName]".
c. The "ShortName" string shall be unique within the XMPP URN
tree and any "SubName" strings shall be unique within the scope of the
ShortName.
d. Each name should be relevant and memorable. Names may be
determined in consultation with the author(s) of the XEP and may be
requested by the author(s) in the XMPP Registrar Considerations section
of the XEP; however, the issuance of namespace names is the sole
responsibility of the XMPP Registrar, which may modify or ignore any
names requested.
e. Each name shall be checked against the registry of existing
names located at <http://www.xmpp.org/registrar/namespaces.html> to
ensure that no duplicate names are issued.
f. The XMPP Registrar shall issue all XMPP URNs directly and
shall not assign secondary responsibility for management of any sub-trees.
2. While the XEP is in the Experimental state, if appropriate and in
consultation with the author(s), the XMPP Registrar shall update the
namespace version number at the end of namespace (e.g., from "0" to
"1"); the XMPP Registrar shall do so only if the protocol defined in the
XEP has been modified in a way that is not backwards-compatible with an
earlier version of the protocol, or if significant new features have
been added to the protocol.
3. When the XMPP Council votes to advance the XEP to a status of
Draft, the XMPP Registrar shall update the namespace registry in
accordance with the procedures specified in the Registry Creation and
Maintenance section of this document.
4. Any namespaces defined after advancement of the relevant XEP to a
status of Draft shall be handled in the same manner.
5. While the XEP is in the Draft or Final state, if appropriate and
in consultation with the author(s) and the XMPP Council, the XMPP
Registrar shall update the namespace version number at the end of
namespace (e.g., from "1" to "2"); the XMPP Registrar shall do so only
if the protocol defined in the XEP has been modified in a way that is
not backwards-compatible with an earlier version of the protocol, or if
significant new features have been added to the protocol. The XMPP
Council must approve any change to the namespace version while the XEP
is in the Draft or Final state.
The XMPP Registrar shall not issue XMPP URNs except as specified above
(e.g., it shall not issue XMPP URNs to private parties or in relation to
specifications that are not published in the XEP series). However, the
XMPP Registrar may at its discretion add namespace names other than XMPP
URNs to its namespace registry, e.g. to register "legacy" namespace
names (of the form "jabber:iq:ShortName", "jabber:x:ShortName", and
"http://jabber.org/protocol/ShortName"; as well as namespace names
produced by recognized standards development organizations (such as
names issued in the IETF URN tree).
***
