FROM RFC 2611 URN Namespace Registration, Update, and NID Assignment Process Different levels of disclosure are expected/defined for namespaces. According to the level of open-forum discussion surrounding the disclosure, a URN namespace may be assigned or may request a particular identifier. The [RFC2434] document suggests the need to specify update mechanisms for registrations -- who is given the authority to do so, from time to time, and what are the processes. Since URNs are meant to be persistently useful, few (if any) changes should be made to the structural interpretation of URN strings (e.g., adding or removing rules for lexical equivalence that might affect the interpretation of URN IDs already assigned). However, it may be important to introduce clarifications, expand the list of authorized URN assigners, etc, over the natural course of a namespace's lifetime. Specific processes are outlined below. There are 3 categories of URN namespaces defined here, distinguished by expected level of service and required procedures for registration. Furthermore, registration maintenance procedures vary slightly from one category to another. I. Experimental: These are not explicitly registered with IANA. They take the form: X- No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. As there is no registration, no registration maintenance procedures are needed. II. Informal: These are registered with IANA and are assigned a number sequence as an identifier, in the format: "urn-" where is chosen by the IANA on a First Come First Served basis (see [RFC2434]). Registrants should send a copy of the registration template (see section 3.0), duly completed, to the: urn-nid@apps.ietf.org mailing and allow for a 2 week discussion period for clarifying the expression of the registration information and suggestions for improvements to the namespace proposal. After suggestions for clarification of the registration information have been incorporated, the template may be submitted to: iana@iana.org for assignment of a NID. The only restrictions on are that it consist strictly of digits and that it not cause the NID to exceed length limitations outlined in the URN syntax ([RFC2168]). Registrations may be updated by the original registrant, or an entity designated by the registrant, by updating the registration template, submitting it to the discussion list for a further 2 week discussion period, and finally resubmitting it to IANA, as described above. III. Formal: These are processed through an RFC review process. The RFC need not be standards-track. The template defined in section 3.0 may be included as part of an RFC defining some other aspect of the namespace, or it may be put forward as an RFC in its own right. The proposed template should be sent to the: urn-nid@apps.ietf.org mailing list to allow for a 2 week discussion period for clarifying the expression of the registration information, before the IESG progresses the document to RFC status. A particular NID string is requested, and is assigned by IETF consensus (as defined in [RFC2434]), with the additional constraints that the NID string must - not be an already-registered NID - not start with "x-" (see Type I above) - not start with "urn-" (see Type II above) - not start with "XY-", where XY is any combination of 2 ASCII letters (see NOTE, below) - be more than 2 letters long NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters, are reserved for potential use as countrycode- based NIDs for eventual national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such namespaces is beyond the scope of this document. Registrations may be updated by updating the RFC through standard IETF RFC update mechanisms. Thus, proposals for updates may be made by the original authors, other IETF participants, or the IESG. In any case, the proposed updated template must be circulated on the urn-nid discussion list, allowing for a 2 week review period. Registered URN Namespaces Value Reference ------------------------- ----- --------- IETF 1 [RFC2648] References ---------- [RFC2611] Daigle, L., et. al., "URN Namespace Definition Mechanisms", RFC 2611, June 1999. [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.