IETF URNbis WG A. Hoenes, Ed. Internet-Draft TR-Sys Obsoletes: 3406 (if approved) October 19, 2012 Intended status: BCP Expires: April 22, 2013 Defining Uniform Resource Name (URN) Namespaces draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 Abstract RFC 2141bis formalizes the concept of Uniform Resource Names (URNs) for persistent, location-independent, resource identifiers within the generic URI system specified in RFC 3986. To structure and organize URN usage, RFC 2141bis specifies a hierarchy that divides the set of possible URNs into "URN Namespaces" that can be individually defined and managed. URN Namespaces allow to map existing identifier systems into the URN scheme and thereby make available generic, network-based resolution services for the identified resources (documents, artifacts, and other objects) and metadata related to them. To this end, URN Namespaces need to be defined and specified in a comparable manner, and their Namespace Identifiers (NIDs) need to be registered with IANA, so that naming conflicts are avoided and implementers of services can follow a structured approach in support of various namespaces, guided by the registry to the related documents and the particularities of specific namespaces, as described in these Namespace registration documents. This RFC serves as a design guideline for stakeholders of URN Namespaces and authors of URN Namespace definition and registration documents. It describes the process to be followed to register a URN Namespace with IANA and the essential content of such documents. This document supersedes and replaces RFC 3406. Discussion Discussion of this memo utilizes the urn@ietf.org mailing list. [[ RFC-Editor: this clause to be deleted before RFC publication ]] Hoenes Expires April 22, 2013 [Page 1] Internet-Draft Defining URN Namespaces October 2012 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Hoenes Expires April 22, 2013 [Page 2] Internet-Draft Defining URN Namespaces October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirement Language and Terminology . . . . . . . . . . . 5 2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 6 3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 8 3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 8 3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8 3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 8 4. URN Namespace Registry: Processes for Registration and Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Experimental Namespaces: No Registration . . . . . . . . . 11 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 12 4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 13 4.4. Registration Documents . . . . . . . . . . . . . . . . . . 14 4.4.1. Namespace Considerations in Registration Documents . . 14 4.4.2. Community Considerations in Registration Documents . . 15 4.4.3. Security Considerations in Registration Documents . . 16 4.4.4. IANA Considerations in Registration Documents . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. URN Namespace Definition Template . . . . . . . . . . 21 A.1. Annotated URN Namespace Definition Template . . . . . . . 21 A.2. Plain URN Namespace Definition Template (Informative) . . 27 Appendix B. Summary of Registration Steps (Informative) . . . . . 28 Appendix C. Changes from RFC 3406 (Informative) . . . . . . . . . 29 C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 29 C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 29 C.3. Changes from URNbis WG I-D -00 to -01 . . . . . . . . . . 32 C.4. Changes from URNbis WG I-D -01 to -02 . . . . . . . . . . 32 C.5. Changes from URNbis WG I-D -02 to -03 . . . . . . . . . . 32 Hoenes Expires April 22, 2013 [Page 3] Internet-Draft Defining URN Namespaces October 2012 1. Introduction Uniform Resource Names (URNs) are identifiers bound to resources with the objective to provide location-independent identification of these resources as well as longevity of reference. URNs are part of the larger Uniform Resource Identifier (URI) family (see the joint W3C/ IETF memorandum, RFC 3305 [RFC3305], and the IETF STD 66, RFC 3986 [RFC3986]), with the specific goal of persistent binding names to resources. The URN scheme formalized in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] structures and organizes the entirety of URNs into a hierarchy that divides the set of possible URNs into "URN Namespaces" that can be individually defined, managed, and (optionally) further subdivided. URN Namespaces in particular serve to map existing identifier systems into the URN system and thereby make available generic, network-based resolution services for the identified resources (documents, artifacts, abstract concepts, and other objects) and their metadata. There are two assumptions that are key to this document: Assumption #1: Assignment of a URN is a managed process. I.e., not all strings that conform to URN syntax are necessarily valid URNs. A URN is assigned according to the rules of a particular namespace (in terms of syntax, semantics, and process). Assumption #2: The space of URN Namespaces is managed. I.e., not all syntactically correct URN Namespace identifiers (per the URN syntax definition) designate valid URN Namespaces. A URN Namespace must have a well recognized definition in order to be valid. To actually draw benefits from this unification (structured embedding of existing namespaces into the URN framework), URN Namespaces have common design considerations, they need to be specified in a comparable manner, and their Namespace Identifiers (NIDs) need to be centrally registered, so that naming conflicts are avoided and implementers of services can follow a structured approach in support of various namespaces, guided by the registry to the related documents and the particularities of specific namespaces, as described in these URN Namespace registration documents. The primary purpose of this document is to outline a mechanism for explicit URN Namespace definition, associating it with an identifier (called a "Namespace ID", or NID). To this end, this RFC defines the Hoenes Expires April 22, 2013 [Page 4] Internet-Draft Defining URN Namespaces October 2012 requirements for URN NID specification documents and provides a registration template, which is to be registered with the Internet Assigned Numbers Authority (IANA) [IANA] in the URN Namespaces registry maintained at [IANA-URN]. However, to give additional guidance to prospective stakeholders / designers of URN Namespaces in fulfiling the requirements for registration, this document also elaborates on generic considerations and design choices for the establishment of URN Namespaces. The URN Namespace definition and registration mechanisms originally have been specified in BCP 33, RFC 2611 [RFC2611], which has been obsoleted by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing IANA procedures have been revised as well over the years, and at the time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative document. This document is a revision of RFC 3406 based on the revised specification of URNs in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226. The reader is referred to Section 1.1 of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the history of documents fundamental for URNs. Note that this document restricts itself to the description of processes for the creation of URN Namespaces. If generic "resolution" of any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that proposed by the DDDS system [RFC3401], is necessary. See [RFC3405] for information on obtaining registration in the DDDS global NID directory. RFC 2141bis establishes an IANA registry for URN services, such that registration documents can unambiguously identify such services and discuss their applicability to the particular URN Namespace. 1.1. Requirement Language and Terminology When spelled in all-capitals as in this paragraph, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. In this document, these key words describe requirements for the process to be followed and the content to be provided in URN Namespace definition documents and registration templates. For the purpose of this document, its subject is spelled "URN Namespace" (in headline case), whereas in other context, "namespace" is spelled in lower case, e.g., to designate a (standard or non- standard) identifier system on which a URN Namespace is based. Hoenes Expires April 22, 2013 [Page 5] Internet-Draft Defining URN Namespaces October 2012 2. What is a URN Namespace? For the purposes of URNs, a "namespace" is a collection of uniquely- assigned identifiers. That is, the identifiers are not ever assigned to more than one resource. These resources may be stable (e.g., a doctoral dissertation or an abstract concept of a protocol) or dynamic (e.g., a continuously evolving web site of a periodical or a specific protocol parameter registry subject to additions and maintenance). If the identified resource is a metadata record, such record may describe several objects (such as two versions of a book) or a collection of objects (such as a periodical with, say, monthly issues); in this case, these subordinate objects are not the identified resources. For each namespace, it must be clear what the identified resources are; if the namespace is heterogenous in this respect, the registration and resolution systems must unambiguously designate the kind of identified resource, for each identifier assigned in the namespace. Once assigned, URNs are never re-assigned to a different resource. A single resource, however, may have more than one URN assigned to it -- within a particular Namespace or among different Namespaces -- for different purposes, since the Namespaces are not mutually exclusive. Such abstract namespace might be defined by some pre-established (standard or non-standard) identifier system that can be made "network-actionable" by embedding it into the URN framework using a specific URN Namespace. A URN Namespace itself has an identifier in order to: - ensure global uniqueness of URNs, - (where desired) provide a cue for the structure of the identifier. For example, many identifier systems use strings of numbers as identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable that there might be some numbers that are valid identifiers in two different established identifier systems. Using different designators for the two collections (and making these designators an intrinsic syntactic part of URNs) ensures that no two URNs will be the same for different resources (since each collection is required to uniquely assign each identifier). The development of an identifier structure, and thereby a collection of identifiers, is a process that is inherently dependent on the requirements of the community defining the identifier, how they will be assigned, and the uses to which they will be put. All of these issues are specific to the individual community seeking to define a namespace (e.g., publishing community, association of booksellers, protocol developers, technology-specific vendor groups, etc.); they are beyond the scope of the IETF URN work. Hoenes Expires April 22, 2013 [Page 6] Internet-Draft Defining URN Namespaces October 2012 If a namespace contains structured resources, per RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] the designers of a related URN Namespace and the implementers of the related resolution systems have available three options for the Namespace to support identification and resolution of component resources: a. A Namespace can choose to assign individual identifiers (Namespace Specific String, NSS) to some or all components of a structured resource that is also named by the identifier system. This method is independent of the Internet media types the resolution system(s) for the Namespace can provide. This is the preferred method. However, there may be rules for a pre-existing identifier system (that is going to be made accessible via URNs) and objectives for the NSS format desired that effectively prohibit such identifier assignments; in such cases, the Namespace designers cannot adopt this method. b. A Namespace can choose to provide a resolution system that interprets the 'component' ("c=") directive that can be incorporated in the part of URI references to URNs (see [I-D.ietf-urnbis-rfc2141bis-urn]). This way, only the basic resources are assigned an NSS -- which will simplify the identifier assignment/registration processes/systems for the namespace, or even be dictated by existing processes/systems -- and the URN resolvers for the Namespace can make use of additional information captured from the owners of the individual resources (in any way that is proper for the namespace). This method is independent of the Internet media types that will be used to return the URN resolution results for such Namespace, and as such allows for stable assigned names yet a flexible, perhaps evolving choice of media types provided by the resolution system(s). c. A Namespace that tightly controls the media types provided by particular resolution services might specify how resolution clients can make use of identifiers contained in URI references to URNs of that Namespace (see [I-D.ietf-urnbis-rfc2141bis-urn]) to pick a component resource from the media returned by the URN service. Since per STD 66 [RFC3986] identifiers of URIs are evaluated at the client side in a manner specific to each media type (if applicable at all), this method depends on the specific capabilities of the media types used. Namespaces specified prior to RFC 2141bis are constricted to method a. Future Namespace definitions MUST document the methods applicable to it and available via its resolvers. Hoenes Expires April 22, 2013 [Page 7] Internet-Draft Defining URN Namespaces October 2012 This document outlines the processes by which a collection of identifiers satisfying certain constraints (uniqueness of assignment, etc.) can become a bona fide URN Namespace by obtaining a NID. In a nutshell, a template for the definition of the Namespace is completed for deposit with IANA, and a NID is assigned. The details of the process and possibilities for NID strings are outlined below. 3. URN Namespace (Registration) Types There are three categories (types) of URN Namespaces defined here, distinguished by expected level of service and required procedures for registration. Registration processes for each of these Namespace types are given in Section 4. In both this Section and Section 4 these categories are ordered by increasing relevance/importance for the Internet and, accordingly, increasing strenght of requirements for the definition and registration processes. 3.1. Experimental Namespaces These are not explicitly registered with IANA. No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. However, as described below in Section 4.1, these are designated by a specific form of the NID to allow differentiation (without preexisting knowledge of details) from the other URN Namespace types. 3.2. Informal Namespaces These are fully fledged URN Namespaces, with all the rights and requirements associated thereto. Informal Namespaces can be registered in global registration services. They are required to uphold the general principles of a well-managed URN Namespace -- providing persistent identification of resources and unique assignment of identifier strings. Informal and Formal Namespaces (described below) differ in the NID assignment. IANA will assign to registered Informal Namespaces a simply structured, alphanumeric, ordinal NID (following a pattern defined in Section 4.2 below), per the process outlined in Section 4. 3.3. Formal Namespaces A Formal Namespace may be requested, and IETF review sought, in cases where the publication of the NID proposal and the underlying namespace will provide benefit to some subset of users on the Internet. That is, a formal NID proposal, if accepted, must be functional on and with the global Internet, not limited to users in Hoenes Expires April 22, 2013 [Page 8] Internet-Draft Defining URN Namespaces October 2012 communities or networks not connected to the Internet. For example, assume a NID is requested that is meant for naming of physics research material. If that NID request required that the user use a proprietary network or service that was not at all open to the general Internet user, then it would make a poor request for a formal NID. The intent is that, while the community of those who may actively use the names assigned within that NID may be small (but no less important), the potential use of names within that NID is open to any user on the Internet. It is however expected that Formal NIDs may be applied to Namespaces where some aspects are not fully open. For example, a Namespace may make use of a fee-based, privately managed, or proprietary registry for assignment of URNs in the Namespace, but it may still provide benefit to some Internet users if the services associated with it have openly published access protocols. In addition to the basic registration information defined in the registration template (in Appendix A), a Formal Namespace request must be accompanied by documented considerations of the need for a new Namespace and of the benefit for the Internet community from formally establishing the proposed URN Namespace -- see Sections 4.4.1 and 4.4.2 below. Additionally, since the goal of URNs is to provide persistent identification, careful consideration must be given to the longevity and maintainability of the URN Namespace. The collective experience of the IETF community contains a wealth of information on technical factors that will prevent longevity of identification. Thus, the IESG may elect not to accept a proposed Namespace registration if the IETF community consensus is that the registration document contains technical flaws that will prevent (or seriously impair the possibility of) persistent identification, and that it therefore should not be published as an RFC. In addition to the technical aspects of the Namespace and its resolution, consideration should be given to the following organizatorial aspects: - the organization maintaining the URN Namespace should credibly demonstrate stability and the ability to maintain the URN Namespace for a long time, and/or it should be clear how the Namespace can continue to be usable/useful if the organization ceases to be able to foster it; Hoenes Expires April 22, 2013 [Page 9] Internet-Draft Defining URN Namespaces October 2012 - the organization(s) assigning URNs within the URN Namespace should demonstrate ability and competency in name assignment; this should improve the likelihood of persistence (e.g., to minimize the likelihood of conflicts); - the organization(s) assigning URNs within the URN Namespace need to be committed to honor the scope, rules, and regulations outlined in its registration document and the documents defining the underlying namespace and covering its identifier assignment and maintenance procedures (if any), and the organization maintaining the URN Namespace needs to have procedures in force that aim at ensuring this adherance at a very high confidence level; and - the involved organization(s) need to commit to not re-assign existing names; old names MUST continue to be valid, even if the owners or assignees of those names are no longer members or customers of such organization; this does not mean that there needs to be resolution of such names, but that they must not resolve such names to false or stale information and that they must not be reassigned. If the underlying namespace is based on an established standard, the standards body or the organization(s) in charge with the maintenance of the namespace should be involved in the process, either by performing the registration on their own, or by supporting the action of the registrant and asserting support of the registration document. These aspects, though hard to quantify objectively, should be considered by organizations/people considering the development of a Formal URN Namespace, and they will be kept in mind when evaluating the technical merits of any proposed Formal URN Namespace. The kind of mandate upon which the organization aims to undertake this activity might give a strong indication for this evaluation, because it likely mirrors the trust that other parties (for instance states, international treaty organizations, professionals' associations, etc.) put on the organization. 4. URN Namespace Registry: Processes for Registration and Update 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 an identifier by IANA or may request a particular identifier. The IANA Considerations Guidelines document (BCP 26 [RFC5226]) suggests the need to specify update mechanisms for registrations -- who is given the authority to do so, from time to time, and what are Hoenes Expires April 22, 2013 [Page 10] Internet-Draft Defining URN Namespaces October 2012 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. The official list of registered URN Namespaces is currently maintained at [IANA-URN]. The registry is subdivided into two sub- registries, one for "Formal URN Namespaces" and one for "Informal URN Namespaces", and each entry there links to a stable repository of the registration document or (an escrow copy of) the filled-out registration template. The registration and maintenance procedures vary between the Namespace types defined in Section 3. The process generally makes use of the urn-nid@ietf.org discussion list, where, under the auspices of the designated expert(s), volunteering experts and other interested parties review URN Namespace proposals. NOTE: The nominal review period on that list (repeatedly quoted below) is specified in this document as four weeks. This is an upper limit intended to grant the experts following the list sufficient headroom and flexibility. The designated expert(s) may always come to a conclusion earlier, based on personal judgement, observation of feedback on the list, and the precedents of a submission. Registrations may be revised by updating the Namespace definition document using the same process as used for initial registrations, including the circulation of the draft form of the revised Namespace definition document on the urn-nid discussion list. 4.1. Experimental Namespaces: No Registration The NIDs of Experimental Namespaces (Section 3.1) are not explicitly registered with IANA. They SHOULD take the form: X- where is a string of up to 30 characters, consisting solely of letters, decimal digits, and hyphen ("-") characters, as specified by the NID syntax specification in Section 2.1 of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn]. Hoenes Expires April 22, 2013 [Page 11] Internet-Draft Defining URN Namespaces October 2012 No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts exclusively. NOTE: The above form is no more considered MANDATORY, in order to accommodate experience and demonstrated evidence that, under specific circumstances, experimental prototype systems have to create and assign identifiers that the interested community perceives are infeasible to be changed once the Namespace gets formally registered. However, it is still RECOMMENDED to prefix eventually targeted NIDs by "X-" during experiments and tests. As there is no registration, no registration/maintenance procedures are needed. Usage of Experimental URN Namespaces MUST be short-lived and whithin a private scope; it MUST NOT be disclosed to the Internet at large, e.g., by distribution of software versions that make use of such. 4.2. Informal Namespaces The NIDs of Informal Namespaces are synthesized by the IANA using an assigned sequence number (ordinal) and registered in their own sub- registry, as indicated in Section 4; they take the format: urn- where is the decimal representation of a natural number, with no leading zeroes. This sequence number is assigned by the IANA on a First-Come-First-Served [RFC5226] basis to registration requests for Informal Namespaces. Registrants should send a copy of the registration template (as shown in Appendix A), duly completed, to the urn-nid@ietf.org mailing list for review and allow for a four-week discussion period for clarifying the expression of the registration information and suggestions for technical improvements to the Namespace proposal. After suggestions for clarification of the registration information have been incorporated, the template may be submitted for assignment of an Informal NID by email to iana@iana.org . Hoenes Expires April 22, 2013 [Page 12] Internet-Draft Defining URN Namespaces October 2012 4.3. Formal Namespaces Formal NIDs are assigned via IETF Review and Expert Review, as defined in BCP 26 [RFC5226]. "IETF Review" means that the Formal NID application is made via submission to the IETF of an Internet-Draft that contains the Namespace definition and targets publication as an RFC of Informational or Standards-Track category, which needs to be approved by the IESG after performing an IETF Last Call on the document and evaluating review comments. The applicant can be an individual or an IETF working group, in alignment with the designation of the Internet-Draft. The actual choice should be properly considered by applicants, but it is RECOMMENDED that the registration documents for NIDs belonging to an established standard namespace aim at Standards- Track, whereas other applications aim at Informational RFC. Before publication can be requested, however, the draft Namespace specification document must undergo an "Expert Review" process [RFC5226] pursuant to the guidelines written here (as well as standard RFC publication guidelines). The designated expert(s) for URN Namespace registrations are nominated by the IESG, and their role adheres to the guidelines in BCP 26, unless specified otherwise below. The template defined in Appendix A SHOULD be included as part of an RFC-to-be defining some other aspect(s) of the Namespace, but it MAY be put forward as a Namespace definition document in its own right. The proposed template (including a pointer to a readily available copy of the registration document) should be sent to the urn-nid@ietf.org mailing list for review. This list is monitored by the designated expert(s). The applicant has to allow for a four-week discussion period for clarifying the expression of the registration information, and SHOULD improve the Namespace document and/or registration template based on the comments received, under the guidance of the designated expert(s). Multiple iterations can be performed, before the proposal is accepted and the document can be forwarded to the IESG for review at large. the Working groups generally SHOULD seek early expert review for a Namespace definition document, and individual applicants are also advised to seek expert comments early enough. The aforementioned list can be contacted for informal advice at any stage. The document writeup needed for submitting a working group document to the IESG requires that all applicable Expert Review processes have been followed; this applies to the process described here. NIDs for Formal URN Namespaces MUST NOT have the forms indicated in the preceding two sections for the other two Namespace types. The proposed NID string MUST conform with the syntax rule in Hoenes Expires April 22, 2013 [Page 13] Internet-Draft Defining URN Namespaces October 2012 Section 2.1 of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to the following additional constraints: - not be an already-registered NID; - not start with "X-" (see Section 4.1 above); - not start with "urn-" (see Section 4.2 above); - not start with "xy-", where xy is any combination of 2 ASCII letters (see NOTE below); - not be equal to or start with "example" (see NOTE below); - be more than 2 characters long. NOTE: All two-letter combinations as well as two-letter combinations followed by "-" and any sequence of valid NID characters are reserved for potential future 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. Further, to avoid confusion, "urn" is not allowed as an NID string; To allow neutral example URNs in code and documentation, NID strings starting with "example" are set aside for use in documentation; IANA has permanently reserved these string to prohibit assignment. Applicants, in concert with the designated expert(s), should ensure that the sought NID strings are "proper" for the designated purpose, according to common sense (and applicable legal rules). 4.4. Registration Documents The following subsections describe essential, MANDATORY parts of URN Namespace registration documents (beyond the registration template specified in Appendix A), which will be focal in the Expert Review process and IETF Review. 4.4.1. Namespace Considerations in Registration Documents The Namespace definition document MUST include a section with "Namespace Considerations" that outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements). Part of the expected elaborations need to be the arguments why other identifier systems, in particular a specific/new URI Scheme would not be suitable for the intended purpose. Hoenes Expires April 22, 2013 [Page 14] Internet-Draft Defining URN Namespaces October 2012 The basis for the expected reasoning can be laid by collecting and analyzing the requirements for the new namespace or, if an existing identifier system shall be incorporated into the URN system, from studying applicable stable (and preferably readily available) documents related to that identifier system that can be quoted. Particular insight to properly decide whether a new namespace is needed can be gained from preparing the explanations to be filled into clauses of the Registration template in Appendix A related to: - kind of resources to be named; - URN assignment procedures; - URN resolution/delegation; - type of services to be supported. NOTE: It is expected that more than one Namespace may serve the same "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the IESG's consideration. If the need for a new namespace can be demonstrated, it needs to be checked whether the requirements and properties of the desired identifer system is properly matched to the basic assumptions and requirements for URNs -- cf. the Introduction of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn]. If that is not obvious, it needs to be explained in detail in the Namespace Considerations. See the trailing NOTE of the next Section for exceptional conditions that might allow to waive the need for presenting the above-described rationale in a standalone section of a particular Namespace definition document. 4.4.2. Community Considerations in Registration Documents The Namespace definition document MUST also include a section with "Community Considerations" that indicates the dimensions upon which the proposer expects its community to be able to benefit by publication of this Namespace, as well as how a general Internet user will be able to use the space if they care to do so. Again, insight into arguments needed here might be possible to be gained by preparing the material to be filled into clauses of the Registration template in Appendix A related to: Hoenes Expires April 22, 2013 [Page 15] Internet-Draft Defining URN Namespaces October 2012 - (open) assignment and use of identifiers within the Namespace; - open operation of resolution servers for the Namespace (server); - creation of software that can meaningfully resolve and access services for the Namespace (client). NOTE: It is acknowledged that occasionally the Namespace Considerations and Community Considerations are closely intertwined; e.g., this has has been observed in the context of legacy identifier systems to be embedded into a URN Namespace. If such circumstances can be demonstrated, the Expert Review process can waive the requirement to present the two independent sections of a Namespace defintition document described in this and the preceding Section and concede to the applicant(s) to combine the content required for those two mandatory sections into a single "Namespace and Community Considerations" section. 4.4.3. Security Considerations in Registration Documents According to the general procurements for RFCs, URN Namespace definition documents must include a "Security Considerations" section (cf. BCP 72 [RFC3552]). That section has to identify the security considerations specific to the subject URN Namespace. If the subject URN Namespace is based on an underlying namespace, the registration can include substantive security considerations described in specifications related to that particular namespace by reference to these documents. For general security considerations regarding URN usage (and more generally, URI usage), for the sake of clarity and brevity, it should refer to the Security Considerations in STD 63 [RFC3986] and in the URN Syntax document [I-D.ietf-urnbis-rfc2141bis-urn]. 4.4.4. IANA Considerations in Registration Documents According to the general procurements for RFCs, URN Namespace definitions documents must include an "IANA Considerations" section (cf. BCP 26 [RFC5226]). That section has to indicate that the document includes a URN Namespace registration template that is to be entered into the IANA registry of either Informal or Formal URN Namespaces. The completed Namespace registration template included in (or referred by) the IANA Considerations section in the published form of Registration documents will provide the particular, unique NID string that has been assigned, in case of formal Namespaces, by the Standards/Protocol Action of the IESG that approved the publication Hoenes Expires April 22, 2013 [Page 16] Internet-Draft Defining URN Namespaces October 2012 of the registration document as an RFC, or, in case of informal Namespaces, by the IANA after successful Expert Review. As specified above in Section 4.3, draft registration documents for formal Namespaces usually carry the NID suggested by the registrant (subject to the expert review process); otherwise the NID will be assigned by the IANA. RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are ASCII strings that are interpreted in a case- insensitive manner, but the NID string SHALL be registered in the capitalization form preferred by the registrant. Additional syntactical constraints for NIDs are specified (per Namespace type) in Sections 4.2 and 4.3 above. Applicants and the designated expert(s) have to ensure that the sought NID strings are suitable and proper for the designated purpose and not misleading, according to common sense and applicable legal rules. The IETF Review process gives interested parties the opportunity to rise concerns if they want to challenge proposed strings; the final approval decision still remains with the IESG. To avoid clerical accidents, the IANA Considerations Section in Namespace registration documents should clearly spell out the implications of the registration on the URN Query Parameters registries defined in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], if any. Namespace registration documents have to specify the use or non-use of query instructions (by registered keyword) by the resolvers related to the respective namespace. Additionally, they can optionally define new query keywords (of specific scope) for that Namespace or an entire group of Namespaces. 5. Security Considerations This document largely focuses on providing mechanisms for the declaration of public information. Nominally, these declarations should be of relatively low security profile; however, there is always the danger of "spoofing" and providing mis-information. Information in these declarations should be taken as advisory. 6. IANA Considerations This document outlines the processes for registering URN Namespaces, and has implications for the IANA in terms of registries to be maintained, as previously defined in RFC 3406 [RFC3406]. This document replaces RFC 3406; it contains a revised description for the management of the "Uniform Resource Names (URN) Namespaces" IANA Registry that uses the policy designation terms from BCP 26, RFC 5226 [RFC5226], but does not introduce significant changes to the applicable procedures described in Section 4 of this RFC. Hoenes Expires April 22, 2013 [Page 17] Internet-Draft Defining URN Namespaces October 2012 IANA is asked to update the applicable policy for the registry of Formal URN Namespaces in the list of protocol parameter registries at http://www.iana.org/protocols/, replacing "IETF Consensus Action" by "IETF Review after expert review on the urn-nid discussion list (designated expert: ...)". In both sub-registries of [IANA-URN] (for Formal and Informal Namespaces), the registry column headings "URN Namespaces" should be changed to "Namespace ID", and "Value" to "Ordinal"; preferably these columns should be swapped in both sub-registries. [[ DISCUSS: Do we actually need these numerical columns at all? ]] IANA is asked to add to both sub-registries of [IANA-URN] a new third column entitled "Kind of named resources"; entries into this column shall be captured from the respective clause of received registration templates conforming to Appendix A. For legacy entries, the original registrants are encouraged to provide proper short descriptions to IANA. [[ DISCUSS: Shall *we* provide sensical values for legacy entries and/or actively poll the Namespace owners instead? ]] All references there to the predecessor, [RFC3406], should be replaced by references to this document. We would appreciate a reorganization of the Registry web page to make the registration templates for Informal URN Namespaces directly linked from the main page; this would make the page /assignments/ urn-informal.htm page dispensable (for persistency's sake, the web server should redirect requests to the /assignments/urn-namespaces page. Section 4 of this document outlines the general procedures. Sections 4.2 and 4.3 above describe the syntax rules for NIDs to which the registry needs to obey. As pointed out in Section 4.3 above and in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is permanently reserved and MUST NOT be assigned as an NID. All strings starting with "example" are permanently reserved for use in code and documentation, and hence MUST NOT be assigned as an NID. In conformance with BCP 100 [RFC4020], in all cases of new Namespace registration proposals, the IANA should provisionally assign the appropriate NID (informal or formal), as described throughout the body of this memo, once an IESG-designated expert has confirmed that the requisite registration process steps have been completed. These registrations become permanent and can be made publicly available once the registration document has been approved by the IESG for publications as a Standards-Track or Informational RFC. Hoenes Expires April 22, 2013 [Page 18] Internet-Draft Defining URN Namespaces October 2012 Once a Namespace registration template has been accepted for IANA processing, the IANA is expected to also update the "Supported by" lists in the registry specified by Section 9.2.1 of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], based on the information supplied in the "Usage of query instructions" clause of the registration template. 7. Acknowledgements This document is heavily based on RFC 3406 (and thereby its predecessor, RFC 2611), authored by Leslie Daigle, Dirk-Willem van Gulik, Renato Ianella, and Patrik Faltstrom, whose work is cordially acknowledged. This document also been inspired by other recent documents that have updated important IANA registries, and the countless authors and contributors to these efforts are acknowledged anonymously. Several individuals in the URNbis working group have participated in the detailed discussion of this memo. Particular thanks for detailed review comments and text suggestions go to (in alphabetical order) Leslie Daigle Juha Hakala, Subramanian Moonesamy. Peter Saint-Andre, Lars Svensson, and Mykyta Yevstifeyev. 8. References 8.1. Normative References [I-D.ietf-urnbis-rfc2141bis-urn] Hoenes, A., "Uniform Resource Name (URN) Syntax", draft-ietf-urnbis-rfc2141bis-urn-03 (work in progress), October 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Hoenes Expires April 22, 2013 [Page 19] Internet-Draft Defining URN Namespaces October 2012 8.2. Informative References [IANA] IANA, "The Internet Assigned Numbers Authority", . [IANA-URN] IANA, "Uniform Resource Names (URN) Namespace Registry", . [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999. [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Hoenes Expires April 22, 2013 [Page 20] Internet-Draft Defining URN Namespaces October 2012 Appendix A. URN Namespace Definition Template Definition of a URN Namespace is accomplished by completing the following information template. It is provided in two versions; the annotated template with comments explaining what should go into the filled-out template is shown in Appendix A.1 and the plain template that can be used as a starting point for filling in the required information via plaintext editing is shown in Appendix A.2. To further the application of the template, both forms will be made available in xml2rfc form on the IETF Tools and/or IANA web site [[ to be decided ]]. In case of (unintended) deviations, Appendix A.1 takes precedence over Appendix A.2. Apart from providing a mechanism for disclosing the structure of the URN Namespace, this information is designed to be useful for - entities seeking to have a URN assigned in a Namespace (if applicable) and - entities seeking to provide URN resolvers for a Namespace (if applicable). This is particularly important for communities evaluating the possibility of using a portion of an existing URN Namespace rather than creating their own. Applications for Formal URN Namespaces must also document "Namespace Considerations", "Community Considerations", "Security Considerations", and "IANA Considerations", as described in Section 4.4. A.1. Annotated URN Namespace Definition Template Information in the template is as follows (text in curly braces describes the expected content and should be removed from filled-in templates): Namespace ID: { If request is for an Informal NID, indicate so; the number will be assigned by IANA. In the case of a Formal NID registration, regularly a particular NID string will be requested. } Kind of named resources: { Short description of what resources are named under this NID. } Hoenes Expires April 22, 2013 [Page 21] Internet-Draft Defining URN Namespaces October 2012 Registration Information: { This is information to identify the particular version of registration information: } - version number: { starting with 1, incrementing by 1 with each new version } - date: { date submitted to the IANA or date of approval of registration document, using the format outlined in "Date and Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD } Declared registrant of the Namespace: - Registering organization: Name: { ... } Address: { ... } - Designated contact person: Name: { ... } { Address: ... (at least one of: Email, Phone, Postal address) } Declaration of syntactic structure of NSS part: { This clause should outline any structural features of identifiers in this Namespace. At the very least, this description may be used to introduce terminology used in other clauses. This structure may also be used for determining realistic caching/ shortcuts approaches; suitable caveats should be provided. If there are any specific character encoding rules (e.g., which character should always be used for single-quotes), these should be listed here. Answers might include, but are not limited to: - the structure is opaque (no exposition); - a regular expression for parsing the identifier into components, including naming authorities; - formal syntax of the NSS, preferably in ABNF (STD 68 [RFC5234]). } Relevant ancillary documentation: { This clause should list any RFCs, standards, or other published documentation that defines or explains all or part of the namespace structure. Hoenes Expires April 22, 2013 [Page 22] Internet-Draft Defining URN Namespaces October 2012 Answers might include, but are not limited to: - RFCs that outline the syntax of the namespace; - other documents of the defining community (e.g., ISO) that outline the syntax of the identifiers in the namespace; - explanatory material that introduces the namespace. } Conformance with URN Syntax: { This clause should outline any special considerations required for conforming with the URN syntax. This is particularly applicable in the case of legacy naming systems that are used in the context of URNs. For example, if a namespace is used in contexts other than URNs, it may make use of characters that are reserved in the URN syntax. This clause should flag any such characters, and outline necessary mappings to conform to URN syntax. Normally, this will be handled by percent-encoding the symbol. } Rules for Lexical Equivalence of NSS part: { If there are particular algorithms for determining equivalence between two identifiers in the underlying namespace (and hence, in the URN string itself), rules can be provided here. Some examples include: - equivalence between hyphenated and non-hyphenated groupings in the identifier string; - equivalence between single-quotes and double-quotes; - namespace-defined equivalences between specific characters, such as "character X with or without diacritic marks". Note that these are not normative statements for any kind of best practice for handling equivalences between characters; they are statements limited to reflecting the namespace's own rules. However, namespaces that seek to provide higher-level lexical equivalence rules should preferably make use of established and standardized normalization procedures (like the methods leading to the various Unicode Normalization Forms, which would have to be applied before UTF-8 encoding) and not invent their own "magic"; in practice, the utility of such things is likely to be limited since test of lexical equivalence is a typical client-side pre- Hoenes Expires April 22, 2013 [Page 23] Internet-Draft Defining URN Namespaces October 2012 screening operation performed by applications that try to remain as general as possible and typically will not have built-in, NID- specific knowledge -- ultimately, functional (or semantical) equivalence of URNs can only be decided in the NID-specific assignment/resolution systems, and their internal rules can be handled much more flexibly than more complicated, nailed-down lexical equivalence rules that are unlikely to be implemented at large. } Usage of query instructions: { Either say "not applicable" or describe the query instructions (keywords and associated values) supported by the resolvers for this Namespace (cf. Sections 2.5 and 9.2 of RFC 2141bis). Is the "s" keyword supported to select component resources? If yes: Which registered services can be selected with it? What is the default/fallback service if "s=" is not given or if the value specified for it is unknown/unsupported? For which services is the "c" keyword supported (if any)? If affirmative, specify the values that can be used with it and the behavior if an unrecognized / inapplicable value is used. } Usage of fragment part: { Either say "not applicable" if parts cannot sensically be used with URI references to URNs of this NID, or specify (by URN service supported) which media types that support fragment identifiers will be returned by the resolvers for this Namespace, and the designators that will be applicable. (Cf. Section 2.4 of RFC 2141bis.) } Identifier uniqueness considerations: { This clause should address the requirement that URN identifiers be assigned uniquely -- they are assigned to at most one resource, and are not reassigned. (Note that the definition of "resource" is fairly broad; for example, information on "Today's Weather" might be considered a single resource, although the content is dynamic.) Possible answers include, but are not limited to: Hoenes Expires April 22, 2013 [Page 24] Internet-Draft Defining URN Namespaces October 2012 - exposition of the structure of the identifiers, and partitioning of the space of identifiers amongst assignment authorities that are individually responsible for respecting uniqueness rules; - identifiers are assigned sequentially; - information is withheld; that is, the namespace is opaque. } Identifier persistence considerations: { Although non-reassignment of URN identifiers ensures that a URN will persist in identifying a particular resource even after the "lifetime of the resource", some consideration should be given to the persistence of the usability of the URN. This is particularly important in the case of URN Namespaces providing global resolution. Possible answers include, but are not limited to: - quality of service considerations. } Process of identifier assignment: { This clause should detail the mechanisms and/or authorities for assigning URNs to resources. It should make clear whether assignment is completely open, or if limited, how to become an assigner of identifiers, and/or get one assigned by existing assignment authorities. Answers could include, but are not limited to: - assignment is completely open, following a particular algorithm; - assignment is delegated to authorities recognized by a particular organization (e.g., the Digital Object Identifier Foundation controls the DOI assignment space and its delegation); - assignment is completely closed (e.g., for a private organization). } Process for identifier resolution: { Which URN resolution services will be supported? What is the default service provided by the resolvers for this Namespace? Hoenes Expires April 22, 2013 [Page 25] Internet-Draft Defining URN Namespaces October 2012 (The "Usage of query instructions:" clause above only reports which services can be selected by the "s" query instruction, if any.) } { If a Namespace is intended to be accessible for global resolution, it must be registered in an RDS (Resolution Discovery System, see RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]). Resolution then proceeds according to standard URI resolution processes, and the mechanisms of the RDS. What this clause should outline is the requirements for becoming a recognized resolver of URNs in this Namespace (and being so listed in the RDS registry). Answers may include, but are not limited to: - the Namespace is not listed with an RDS, this is not relevant; - resolution mirroring is completely open, with a mechanism for updating an appropriate RDS; - resolution is controlled by entities to which assignment has been delegated. } Validation mechanism: { Apart from attempting resolution of a URN, a URN Namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. There are 2 issues here: 1) users should not "guess" URNs in a Namespace; 2) when the URN Namespace is based on an existing identifier system, it may not be the case that all the existing identifiers are assigned on Day 0. The reasonable expectation is that the resource associated with each resulting URN is somehow related to the thing identified by the original identifier system, but those resources may not exist for each original identifier. For example, even if a telephone number-based URN Namespace was created, it is not clear that all telephone numbers would immediately become "valid" URNs, that could be resolved using whatever mechanisms are described as part of the Namespace registration. Validation mechanisms might be: - a syntax grammar; - an on-line service; - an off-line service. } Hoenes Expires April 22, 2013 [Page 26] Internet-Draft Defining URN Namespaces October 2012 Scope: { This clause should outline the scope of the use of the identifiers in this namespace, i.e. the precise kind of resources to which the URNs are assigned. Apart from considerations of private vs. public namespaces, this clause is critical in evaluating the applicability of a requested NID. For example, a namespace claiming to deal with "social security numbers" should have a global scope and address all social security number structures (unlikely). On the other hand, at a national level, it is reasonable to propose a URN Namespace for "this nation's social security numbers". } A.2. Plain URN Namespace Definition Template (Informative) Namespace ID: ... Kind of named resources: ... Registration Information: - version number: _ - date: yyyy-mm-dd Declared registrant of the Namespace: - Registering organization: Name: ... Address: ... - Designated contact person: Name: ... { Address: ... } Declaration of syntactic structure of NSS part: ... Relevant ancillary documentation: ... Conformance with URN Syntax: ... Hoenes Expires April 22, 2013 [Page 27] Internet-Draft Defining URN Namespaces October 2012 Rules for Lexical Equivalence of NSS part: ... Identifier uniqueness considerations: ... .. [[ to be completed in next draft rev if this idea is accepted ]] ... Appendix B. Summary of Registration Steps (Informative) The key steps for registration of Informal or Formal Namespaces typically play out as follows: A) Informal NID: 1. Complete the registration template. This may be done as part of an Internet-Draft. 2. Communicate the registration template to urn-nid@ietf.org for technical review -- as an email with a pointer to the submitted I-D or inline text containing the template. 3. Update the registration template (and/or document) as necessary from comments, and repeat steps 2 and 3 as necessary. 4. Once comments have been addressed (and the review period has expired), send a request to IANA with the revised registration template. B) Formal NID: 1. Write an Internet-Draft describing the namespace and include the registration template, duly completed. Be sure to include "Namespace Considerations" and "Community Considerations" sections (or a combined section for these), "Security Considerations" and "IANA Considerations" sections, as described in Section 4.4. 2. Submit the Internet-Draft, and send a pointer to the I-D (perhaps using a copy of the I-D announcement) to urn-nid@ietf.org in order to solicit technical review. Hoenes Expires April 22, 2013 [Page 28] Internet-Draft Defining URN Namespaces October 2012 3. Update the Internet-Draft as necessary from comments, and repeat steps 2 and 3 as needed. 4. If the Internet-Draft is the product of a working group in the IETF, follow the usual WG process to forward the document to the IESG for publication as an RFC. Otherwise, find a sponsoring Area Director willing to guide the draft through the IESG. The IESG (or the IETF at large in case an IETF-wide last call is deemed necessary) may request further changes (submitted as I-D revisions) and/or direct discussion to designated working groups, area experts, etc. 5. The IESG evaluation process includes a review by IANA, and if the IESG approves the document for publication as an RFC, IANA processing of the document will follow the regular work-flow between the RFC Editor and IANA. This way, the NID registration will be made public by IANA when the RFC is published. Appendix C. Changes from RFC 3406 (Informative) C.1. Essential Changes since RFC 3406 [ RFC Editor: please remove the Appendix C.1 headline and all subsequent subsections of Appendix C starting with Appendix C.2. ] [[ T.B.D. in next iteration of this memo. ]] C.2. Changes from RFC 3406 to URNbis WG Draft -00 o Abstract: rewritten entirely; o Section 1 (Introduction): added historical RFC information; o Section 1.1 (Requirements Language): added; o Section 3.1: added Note that challenges the utility of Experimental Namespaces and raises question of whether formal "provisional" registrations would be useful; o Section 4: text expanded and updated; background material added; added Note to challenge IANA website practices; o Section 4.2 ff: changed "home" of URN-NID registration discussion list (it already had been moved to the IETF Secretariat servers); o Section 4.2: added Note to challenge the 2-week review period; in current practice, that is almost always exceeded, and some regard Hoenes Expires April 22, 2013 [Page 29] Internet-Draft Defining URN Namespaces October 2012 it as too short; o Section 4.3: largely clarified procedures as they happen in practice; adapted language for conformance with RFC 5226; use new home of URN-NID (as mentioned above); the registration template (Appendix A) now "SHOULD" be used; o Section 4.3: split off new Section 4.4 on Registration Documents, because registrants essentially are encouraged to follow these guidelines for Informal Namespaces as well, as far as practical; replaced "RFC" by "Registration Document"; Section 4.4 is subdivided for all mandatory sections; o Section 4.4.1: made requirements a "MUST"; o Sections 4.4.1 and 4.4.2: added common Note that challenges the need to split Namespace and Community Considerations, based on observed problems in practice to separate the topics, and pointing to overlap with clauses in the registration template due to bullets listed that are not so clearly related to the headlines under which they appear; suggestion is to avoid duplication, place factual stuff into the template and focus on rationale in these Considerations, perhaps in a common section; o Section 4.4.3: added discussion of Security Considerations section; advice is to focus on namespace-specific considerations and refer to the SecCons in the "generic" RFCs for the general issues; o Section 4.4.4: amended discussion of IANA Considerations section; this tries to reflect standing practice and codifies that Formal NIDs are generally proposed by the registrant; added Note that "urn" is permanently reserved and MUST NOT be assigned as a NID, to avoid confusion (as also specified in RFC 2141bis draft); wrt registration maintenance: got rid of wrong reference in RFC 3406 (to RFC 2606); o Section 6 (IANA Considerations): updated and rephrased description of the role of this document, including a sketch of the history; added teat that tries to precisely describe what is expected from IANA on approval of this draft; added text on procedures and suggest a provisional assignment practice upon "thumbs-up" of the IANA Expert to protect prospective registrants from collateral damage on NID precedence in case the document suffers from delays unrelated to the registration template before it eventually gets approved; Hoenes Expires April 22, 2013 [Page 30] Internet-Draft Defining URN Namespaces October 2012 o Section 7 (Acknowledgements): added; o References: Updated and amended references; added pointers to chartered URNbis work items; removed entirely outdated example material related to legacy documents; o Appendix A and B.1: added words on Security Considerations section; o Appendix A (Registration Template): clarified role of text snippets in the Template: hint and commentary now all enclosed in curly braces, with not that these parts shall be removed when filling in the tempalte; indicate that Formal NIDs are normally proposed by registrant; changed date/time ref. from ISO 8601 to RFC 3339; use inherited term "percent-encoding"; o Appendix A -- structure: moved formal clauses on Conformance with URN Syntax and Rules for Lexical Equivalence to vicinity of namespace specific syntax clause, to which these are closely related; o Appendix A -- changes of clauses: the Declaration of syntactic structure and Rules for Lexical Equivalence clauses now tentatively have been restricted to the NSS part only; this change is described in NOTEs and motivated by the observation of repeated confusion in past and present registration documents, which hopefully can be avoided (and the job of the Expert and reviewers made easier) by leaving discussion of the invariate parts that cannot be re-specified there at the single place where they belong to: the NID is fully specified in the initial clause, rules for the NID and the URI scheme name "urn" are inherited from RFC 2141[bis] and RFC 3986, respectively, and hence the new clause descriptions avoid conflict by taking these components out of scope of these clauses; o Appendix B.1 (Example Template): facelifted a bit; concerns with IESG policy on examples in RFCs raised in a NOTE; o Appendix B.2 (Registration steps in practice): updated and clarified description of procedure, in alignment to current practice; o Appendix C: removed "Changes from RFC 2611"; added this change log; o General: numerous editorial changes and enhancements, following contemporary RFC style. Hoenes Expires April 22, 2013 [Page 31] Internet-Draft Defining URN Namespaces October 2012 C.3. Changes from URNbis WG I-D -00 to -01 Usage of terminology strenghtened. Clarified role and usage of Experimental Namespaces. Clarified NID strings for Formal Namespaces. Added hint that recommends Std. Track RFCs for NID applications based on established standard namespaces, and Informational for others. Changed standard review period from 2 to 4 weeks (pending discussion). Resolved with IANA: simple, traditional and generic URL used by IANA for the URN Namespace registry. (Needed to be re-opened in -02!) Numerous editorial enhancements and fixes. C.4. Changes from URNbis WG I-D -01 to -02 General text edits based on evaluation of meeting and on-list comments. Updated and tightened the organizatorial requirements for Formal Namespace requests. Restored additional IANA Considerations -- due to observed defects. Reserved NID strings "example.*" for documentation (as suggested by Larry Masinter, Peter Saint-Andre, and Julian Reschke). Added text on possible "higher level" methods to establish lexical equivalence of URNs, with the caveats that such things are rather unlikely to get traction in general-purpose client software. Removed historical Appendix B.1 (Example Template). Various editorial enhancements and fixes. Updated and expanded "Issues" Appendix (below) in preparation of usage of the IETF Issue Tracker. C.5. Changes from URNbis WG I-D -02 to -03 Due to the scattered discussion of the previous draft version, the items below not only list effected changes but also give rationale for where suggested changes have not been applied. Hoenes Expires April 22, 2013 [Page 32] Internet-Draft Defining URN Namespaces October 2012 Document title shortened to better reflect entire purpose of document. Abstract: revised and shortened (comments from SM). Introduction: Rephrased 1st para to put emphasis on name binding property (derived from list discussion on related topic, Keith Moore et al.). Amended / modified text to better reflect the intended audience of the memo and its contents, and to accommodate the evolution of the rfc2141bis I-D. Wordsmithing Assumption: "_well_ recognized" (Lars Svensson). Contrary to a proposal (PSA), the draft text keeps the Assumptions separate from the consequences/conclusions drawn from these; the registration process is what is to be followed to maintain the assumption, not the 2nd assumption itself. Text reworked based on comments (SM, PSA, et al.). The single paragraph with a historical perspective on previous documents is deemed rather helpful for the intended audience (note the confusing artifact caused by RFC Editor mistake, giving the replacement of a BCP a different BCP number!), and it serves to capture important motivations for the document revision effort; therefore, it is kept in the draft. The pargraph describing the purpose of the document has been rephrased. It isn't barely about an IANA procedure, it is also about what prospective registrants are well advised to consider before deciding on a new Namespace and the processes they have to implement, and finally capturing the results in a URN Namespace registration document. Section 2: Amended by text describing the 3 methods available to Namespace designers / stakeholdes to make component resources of structured resources identifiable/accessible. Some existing text reworded based on comments (SM et al.). It has been argued that text on URN Namespaces in s2 would better be placed into the rfc2141bis document, but on the other hand, it has been argued that text introducing and discussing Namespace properties from rfc2141bis should better be placed into this memo. To keep both documents as much self-contained as practical, text on URN Namespaces of specific interest to prospective stakeholders of URN Namespaces and authors of registration documents has been kept in s2 of this draft, and new such material has been added there. (The rfc2141bis draft now points to this.) s3.3: Reworded "benefit" clause to clarify distinction between the community interested in a new Namespace and the Internet community at large (corollary to comments on and revision of s4.4.2.). Hoenes Expires April 22, 2013 [Page 33] Internet-Draft Defining URN Namespaces October 2012 s4: (dealing with comments from SM, PSA) The justification for the need to consider and specify registration maintenance procedures has been in RFC 3406; the text from there has been updated according to our chartered, to update for RFC 5226. This matter needs to be taken into account by prospective Namespace owners, and thus the text makes sense in this document. Reorganization of subsequent text made it logically necessary to include into this section a high level description of the urn-nid@ietf.org list. The nominal review period is left a four weeks in this draft revision, but a Note has been added to s4 indicating that this is an upper limit to accommodate headroom, whereas the designated expert(s) may always come to a conclusion earlier. Repeated references to IANA have been consolidated. The common shorthand designation "IANA experts" for the designated expert(s) supporting IANA in the maintenance of the URN NID registry is now being avoided. s4.1: No technical changes. The continued use of the "X-" prefix for Experimental Namespaces does not violate RFC 6648 because this is legacy practice, experimental NIDs are not being registered, and this memo again prohibits the use of Experimental Namespaces in the open Internet. s4.3: Text reorganized, incorporating material from s4.4.4 (see below). The text on the (modified) "IETF Review" policy has been upgraded from RFC 3406 (and thereby effectively shortened). It serves to give concise information to the expected primary audience of the document, applicants for Namespaces, which according to experience are rather unlikely inclined to read the full RFC 5226, but just need to know what is said in the single sentence in the draft. Further, this sentence supplies the background information for the following sentences and thus improved the readability of the text. Therefore, no substantive changes applied here. s4.4: text amended to avoid confusion about registration template. s4.4.1 and s4.4.2: Heavily reworked based on discussion (Leslie, PSA, Juha, et al.). Bullet lists now point to clauses of the registration template where working on the text to be supplied there will likely give insights to answer the basic questions to be answered here. A NOTE now tentatively allows to include a combined Namespace and Community Considerations section into a Namespace registration document, if the expert review admits it. s4.4.3: The first sentence lays the foundation for the subsequent sentences and gives the appropriate reference (to BCP 72); hence it Hoenes Expires April 22, 2013 [Page 34] Internet-Draft Defining URN Namespaces October 2012 is regarded as non-disposable -- no change. Repeated negative experience has motivated the addition of a hint that emphasizes that WG documents including URN Namespace definitions need to go through the urn-nid process before they can be forwarded to the IESG (document writeup requirement). s4, s4.4.4: Last paragraph ostensibly belonging to s4.4.4 moved to end of s4, then adjusted to context. (The RFC format doesn't allow to recognize the continuation of a higher-level section after the inclusion of sub-sections.) s4.3, s4.4.4: The checklist of syntactical constraints for NIDs of formal namespaces was intended as a checklist for IANA; following comments from Lars Svensson, it has been moved from s4.4.4 to s4.3 and related text has been modified accordingly. s4.4.4: substantially revised (comments from Lars Svensson et al.). IANA Cons. (s6): Added request to IANA to clarify the procedures for Formal NIDs in the list of ptorocol parameter registries. Updated and expanded Acknowledgements. References: RFC 3339 demoted to Informational; you don't need to read it to insert the date into the registration template, the applicable pattern is shown there directly; this change avoids a potential normative downref. Clarified role of Appendices. Appendix A: Clarified purpose of the explanations in curly braces embedded in the annotated registration template. Use term "clause" throughout. Removed Notes from template that served to explain previous changes. Template now provided in both annotated and bare form (suggestion from SM); once finalized, both forms will be provided in xml2rfc format (location to be decided: IETF Tools and/or IANA). Added new items to registration template for Purpose of Namespace (short description of named resources), applicability of part and supported query instructions (if any), and applicability of part. Appendix B: The document organization is carried over from RFC 3406. Modified title of App. B, declared it Informative. This Appendix C.5 added; previous Appendix D (Issues) dropped. Multiple editorial fixes and enhancements. Hoenes Expires April 22, 2013 [Page 35] Internet-Draft Defining URN Namespaces October 2012 Author's Address Alfred Hoenes (editor) TR-Sys Gerlinger Str. 12 Ditzingen D-71254 Germany EMail: ah@TR-Sys.de Hoenes Expires April 22, 2013 [Page 36]