List of namespace registrations (may not be up to date - see RFC 3232):
Conditions for a name space in order to be accepted (cf. RFC 3406, section
3.3):
- The namespace must benefit at least a subset of users on the Internet,
preferably without the use of proprietary protocols and tools.
- It must be explained how the namespace is maintained. For example:
- What, if any, organizations are taking care of the namespace?
- How are conflicting names avoided?
- It must be explained how the goal of persistent identification can be
approximated or even achieved.
Registration process for an NID, a Namespace ID (cf. RFC 3406, sections 4.3 and
B.2):
- The process:
- A proposal for an RFC is written. It may (or should or has to?) be based
on the template in Appendix A, RFC 3406. Appendix B provides an example of
a filled out template.
- The proposal is sent to the mailing list urn-nid@apps.ietf.org and send a
copy to the I-D editor (I-D: "Internet Draft").
- The proposal is discussed on the mailing list for two weeks. If
necessary, it needs to be resubmitted.
- The proposal is sent to the IESG.
- The IESG may:
- request modifications.
- direct discussion to a designated working group.
- direct discussion to area experts.
- etc.
- If the IESG approves the document, then a request is sent to IANA to
register the requested NID.
- See RFC 2434 for "IETF Consensus" according to which NIDs are assigned.
- Part of the process is publication of a proposed namespace RFC by the IESG
(Internet Engineering Steering Group).
Testing of namespaces (cf. RFC 3406, section 4.1): This can be done by
prepending an "X-" to the namespace identifier, e.g. "X-trade". Of course, it
cannot be guaranteed that different experimental namespaces do not conflict.