diff options
Diffstat (limited to 'doc/rfc/rfc3406.txt')
| -rw-r--r-- | doc/rfc/rfc3406.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc3406.txt b/doc/rfc/rfc3406.txt new file mode 100644 index 0000000..cd739ab --- /dev/null +++ b/doc/rfc/rfc3406.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group L. Daigle +Request for Comments: 3406 Thinking Cat Enterprises +BCP: 66 D.W. van Gulik +Obsoletes: 2611 WebWeaving +Category: Best Current Practice R. Iannella + IPR Systems + P. Faltstrom + Cisco + October 2002 + + + Uniform Resource Names (URN) Namespace Definition Mechanisms + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document lays out general definitions of and mechanisms for + establishing Uniform Resource Names (URN) "namespaces". The URN WG + has defined a syntax for URNs in RFC 2141, as well as some proposed + mechanisms for their resolution and use in Internet applications in + RFC 3401 and RFC 3405. The whole rests on the concept of individual + "namespaces" within the URN structure. Apart from proof-of-concept + namespaces, the use of existing identifiers in URNs has been + discussed in RFC 2288. + +Table of Contents + + 1.0 Introduction ................................................. 2 + 2.0 What is a URN Namespace? ..................................... 3 + 3.0 URN Namespace (Registration) Types ........................... 3 + 3.1 Experimental Namespaces ..................................... 4 + 3.2 Informal Namespaces ......................................... 4 + 3.3 Formal Namespaces ........................................... 4 + 4.0 URN Namespace Registration, Update, and NID Assignment + Process ..................................................... 6 + 4.1 Experimental ................................................ 6 + 4.2 Informal .................................................... 6 + 4.3 Formal ...................................................... 7 + 5.0 Security Considerations ..................................... 9 + + + +Daigle, et. al. Best Current Practice [Page 1] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + 6.0 IANA Considerations ......................................... 9 + 7.0 References .................................................. 9 + Appendix A -- URN Namespace Definition Template ................. 11 + Appendix B -- Illustration ...................................... 15 + B.1 Example Template ............................................ 15 + B.2 Registration steps in practice .............................. 17 + Appendix C -- Changes from RFC 2611 ............................. 18 + C.1 Detailed Document Changes ................................... 19 + Authors' Addresses .............................................. 21 + Full Copyright Statement ........................................ 22 + +1.0 Introduction + + Uniform Resource Names (URNs) are resource identifiers with the + specific requirements for enabling location independent + identification of a resource, as well as longevity of reference. + URNs are part of the larger Uniform Resource Identifier (URI) family + [RFC3305] with the specific goal of providing persistent naming of + resources. + + There are 2 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 namespaces (per the URN + syntax definition) are valid URN namespaces. A URN namespace must + have a recognized definition in order to be valid. + + The purpose of this document is to outline a mechanism and provide a + template for explicit namespace definition, as well as provide the + mechanism for associating an identifier (called a "Namespace ID", or + NID) which is registered with the Internet Assigned Numbers Authority + (IANA). + + Note that this document restricts itself to the description of + processes for the creation of URN namespaces. If "resolution" of any + so-created URN identifiers is desired, a separate process of + registration in a global NID directory, such as that provided by the + + + +Daigle, et. al. Best Current Practice [Page 2] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + DDDS system [RFC3401], is necessary. See [RFC3405] for information + on obtaining registration in the DDDS global NID directory. + +2.0 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 1 resource, nor are they ever re-assigned to a different + resource. A single resource, however, may have more than one URN + assigned to it for different purposes. 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 may 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 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, etc); they are beyond the scope of the IETF URN + work. + + 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.0 URN Namespace (Registration) Types + + There are three categories 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.0. + + + + + +Daigle, et. al. Best Current Practice [Page 3] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + +3.1 Experimental Namespaces + + These are not explicitly registered with IANA. They take the form: + + X-<NID> + + No provision is made for avoiding collision of experimental NIDs; + they are intended for use within internal or limited experimental + contexts. + +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 an + alphanumeric NID to registered informal namespaces, per the process + outlined in Section 4.0. + +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 + communities or networks not connected to the Internet. For example, + a NID that is meant for naming of physics research is requested. 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 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 have openly- + published access protocols. + + + + + + + +Daigle, et. al. Best Current Practice [Page 4] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + 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 community benefit from formally establishing + the proposed URN namespace. + + Additionally, since the goal of URNs is to provide persistent + identification, some consideration as to the longevity and + maintainability of the namespace must be given. The URN WG discussed + at length the issue of finding objective measures for predicting (a + priori) the continued success of a namespace. No conclusion was + reached -- much depends on factors that are completely beyond the + technical scope of the namespace. However, the collective experience + of the IETF community does contain a wealth of information on + technical factors that will prevent longevity of identification. The + IESG may elect not to publish a proposed namespace RFC if the IETF + community consensus is that it contains technical flaws that will + prevent (or seriously impair the possibility of) persistent + identification. + + The kinds of things the URN WG discussed included: + + - the organization maintaining the URN namespace should + 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; + + - it should demonstrate ability and competency in name assignment. + This should improve the likelihood of persistence (e.g. to + minimize the likelihood of conflicts); + + - it should commit to not re-assigning existing names and + allowing old names to continue to be valid, even if the owners + or assignees of those names are no longer members or customers + of that organization. This does not mean that there must be + resolution of such names, but that they must not resolve the + name to false or stale information, and that they must not be + reassigned. + + 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 namespace. + + + + + + + +Daigle, et. al. Best Current Practice [Page 5] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + +4.0 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 "IANA Considerations" document [RFC2434] + 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. + + The official list of registered URN namespaces is maintained by IANA. + URN namespace registrations are currently being posted in the + anonymous FTP directory: + + http://www.iana.org/assignments/urn-namespaces + + See [RFC3232] for the current location of IANA registry. + + The registration and maintenance procedures vary slightly from one + namespace type (as defined in Section 3.0) to another. + +4.1 Experimental + + These are not explicitly registered with IANA. They take the form: + + X-<NID> + + 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. + +4.2 Informal + + These are registered with IANA and are assigned a number sequence as + an identifier, in the format: + + "urn-" <number> + + + + + +Daigle, et. al. Best Current Practice [Page 6] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + where <number> is chosen by the IANA on a First Come First Served + basis (see [RFC2434]). + + Registrants should send a copy of the registration template (see + Appendix A), duly completed, to: + + urn-nid@apps.ietf.org + + and allow for a 2 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 a NID to: + + iana@iana.org + + The only restrictions on <number> are that it consist strictly of + digits and that it not cause the NID to exceed length limitations + outlined in the URN syntax ([RFC2141]). + + 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. + +4.3 Formal + + Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]: + + "IETF Consensus - New values are assigned through the IETF + consensus process. Specifically, new assignments are made via + RFCs approved by the IESG. Typically, the IESG will seek input on + prospective assignments from appropriate persons (e.g., a relevant + Working Group if one exists)." + + Thus, the Formal NID application is made via publication of an RFC + through standard IETF processes. The RFC need not be standards- + track, but it will be subject to IESG review and acceptance pursuant + to the guidelines written here (as well as standard RFC publication + guidelines). The template defined in Appendix A 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 + + + + +Daigle, et. al. Best Current Practice [Page 7] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + mailing list to allow for a two week discussion period for clarifying + the expression of the registration information, before the IESG + reviews the document. + + The RFC must include a "Namespace Considerations" section, which + outlines the perceived need for a new namespace (i.e., where existing + namespaces fall short of the proposer's requirements). + + Considerations might include: + + - URN assignment procedures + - URN resolution/delegation + - type of resources to be identified + - 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. + + The RFC must also include a "Community Considerations" section, which + 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. Potential considerations include: + + - 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) + + The RFC must include an "IANA Considerations" section, indicating + that the document includes a URN NID registration that is to be + entered into the IANA registry of URN NIDs. + + 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 + + + + + + +Daigle, et. al. Best Current Practice [Page 8] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + 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 revised by updating the RFC through standard + IETF RFC update processes (see [RFC2606] for a discussion of IETF + process). In any case, a revised document, in the form of a new + Internet-Draft, must be published, and the proposed updated template + must be circulated on the urn-nid discussion list, allowing for a 2 + week review period before pursuing publication of the new RFC + document. + +5.0 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.0 IANA Considerations + + This document outlines the processes for registering URN namespaces, + and has implications for the IANA in terms of registries to be + maintained. In all cases, the IANA should assign the appropriate NID + (informal or formal), as described above, once an IESG-designated + expert has confirmed that the requisite registration process steps + have been completed. This document defines processes to replace + those outlined in [RFC2611]. + +7.0 References + + [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats + - Information interchange - Representation of dates and + times" + + [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for + Uniform Resource Names", RFC 1737, December 1994. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + + + + + +Daigle, et. al. Best Current Practice [Page 9] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource + Name Resolution", RFC 2276, January 1998. + + [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing + Bibliographic Identifiers as Uniform Resource Names", RFC + 2288, February 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2611] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, + "URN Namespace Definition Mechanisms", RFC 2611, June 1999. + + [RFC3232] Reynolds, J, Editor, "Assigned Numbers: RFC 1700 is + Replaced by an On-line Database", RFC 3232, January 2002. + + [RFC3305] Mealling, M. (Ed.) and R. Denenberg (Ed.), "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. + + [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", RFC 3405, + October 2002. + + + + + + + + + + + + + + + + + + + + + + +Daigle, et. al. Best Current Practice [Page 10] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + +Appendix A -- URN Namespace Definition Template + + Definition of a URN namespace is accomplished by completing the + following information template. Apart from providing a mechanism for + disclosing 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) + - 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" and "IANA + Considerations", as described in Section 4.3. + + Information in the template is as follows: + + Namespace ID: + + Assigned by IANA. In the case of a Formal NID registration, a + particular NID string may be requested. + + Registration Information: + + This is information to identify the particular version of + registration information: + + - registration version number: starting with 1, incrementing by 1 + with each new version + - registration date: date submitted to the IANA, using the format + outlined in [ISO8601]: + + YYYY-MM-DD + + Declared registrant of the namespace: + This includes: + Registering organization + Name + Address + Designated contact person + Name + Coordinates (at least one of: e-mail, phone, postal address) + + + + +Daigle, et. al. Best Current Practice [Page 11] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + Declaration of syntactic structure: + + This section 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 sections. 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 + + Relevant ancillary documentation: + + This section should list any RFCs, standards, or other published + documentation that defines or explains all or part of the + namespace structure. + + Answers might include, but are not limited to: + + - RFCs outlining syntax of the namespace + - Other of the defining community's (e.g., ISO) documents + outlining syntax of the identifiers in the namespace + - Explanatory material introducing the namespace + + Identifier uniqueness considerations: + + This section 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: + + - exposition of the structure of the identifiers, and + partitioning of the space of identifiers amongst assignment + authorities which are individually responsible for respecting + uniqueness rules + - identifiers are assigned sequentially + - information is withheld; the namespace is opaque + + + +Daigle, et. al. Best Current Practice [Page 12] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + 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 section 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: + + If a namespace is intended to be accessible for global resolution, + it must be registered in an RDS (Resolution Discovery System, see + [RFC2276]) such as DDDS. Resolution then proceeds according to + standard URI resolution processes, and the mechanisms of the RDS. + What this section 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 + + + +Daigle, et. al. Best Current Practice [Page 13] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + Rules for Lexical Equivalence: + + If there are particular algorithms for determining equivalence + between two identifiers in the underlying namespace (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. + + Conformance with URN Syntax: + + This section 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 section should flag any such characters, and outline + necessary mappings to conform to URN syntax. Normally, this will + be handled by hex encoding the symbol. + + For example, see the section on SICIs in [RFC2288]. + + 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 + + + +Daigle, et. al. Best Current Practice [Page 14] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + 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 + + Scope: + + This section should outline the scope of the use of the + identifiers in this namespace. Apart from considerations of + private vs. public namespaces, this section is critical in + evaluating the applicability of a requested NID. For example, a + namespace claiming to deal in "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". + +Appendix B -- Illustration + +B.1 Example Template + + The following example is provided for the purposes of illustrating + the URN NID template described in Appendix A. Although it is based + on a hypothetical "generic Internet namespace" that has been + discussed informally within the URN WG, there are still technical and + infrastructural issues that would have to be resolved before such a + namespace could be properly and completely described. + + Namespace ID: + + To be assigned + + Registration Information: + + Version 1 + Date: <when submitted> + + + + + + + + + + +Daigle, et. al. Best Current Practice [Page 15] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + Declared registrant of the namespace: + + Name: Thinking Cat Enterprises + Address: 1 ThinkingCat Way + Trupville, NewCountry + Contact: L. Daigle + E-mail: leslie@thinkingcat.com + + Declaration of structure: + + The identifier structure is as follows: + + URN:<assigned number>:<FQDN>:<assigned string> + + where FQDN is a fully-qualified domain name, and the assigned + string is conformant to URN syntax requirements. + + Relevant ancillary documentation: + + Definition of domain names, found in: + + P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", + RFC 1035, November 1987. + + Identifier uniqueness considerations: + + Uniqueness is guaranteed as long as the assigned string is never + reassigned for a given FQDN, and that the FQDN is never + reassigned. + + N.B.: operationally, there is nothing that prevents a domain name + from being reassigned; indeed, it is not an uncommon occurrence. + This is one of the reasons that this example makes a poor URN + namespace in practice, and is therefore not seriously being + proposed as it stands. + + Identifier persistence considerations: + + Persistence of identifiers is dependent upon suitable delegation + of resolution at the level of "FQDN"s, and persistence of FQDN + assignment. + + Same note as above. + + + + + + + + +Daigle, et. al. Best Current Practice [Page 16] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + Process of identifier assignment: + + Assignment of these URNs is delegated to individual domain name + holders (for FQDNs). The holder of the FQDN registration is + required to maintain an entry (or delegate it) in the DDDS. + Within each of these delegated name partitions, the string may be + assigned per local requirements. + + e.g., urn:<assigned number>:thinkingcat.com:001203 + + Process for identifier resolution: + + Domain name holders are responsible for operating or delegating + resolution servers for the FQDN in which they have assigned URNs. + + Rules for Lexical Equivalence: + + FQDNs are case-insensitive. Thus, the portion of the URN + + urn:<assigned number>:<FQDN>: + + is case-insensitive for matches. The remainder of the identifier + must be considered case-sensitive. + + Conformance with URN Syntax: + + No special considerations. + + Validation mechanism: + + None specified. + + Scope: + + Global. + +B.2 Registration steps in practice + + The key steps for registration of informal or formal namespaces + typically play out as follows: + + Informal NID: + + 1. Complete the registration template. This may be done as part + of an Internet-Draft. + + + + + + +Daigle, et. al. Best Current Practice [Page 17] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + 2. Communicate the registration template to urn-nid@apps.ietf.org + for technical review -- as a published I-D, or text e-mail + message containing the template. + + 3. Update the registration template 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. + + Formal NID: + + 1. Write an Internet-Draft describing the namespace and include + the registration template, duly completed. Be sure to include + "Namespace Considerations", "Community Considerations" and + "IANA Considerations" sections, as described in Section 4.3. + + 2. Send the Internet-Draft to the I-D editor, and send a copy to + urn-nid@apps.ietf.org for technical review. + + 3. Update the Internet-Draft as necessary from comments, and + repeat steps 2 and 3 as needed. + + 4. Send a request to the IESG to publish the I-D as an RFC. The + IESG may request further changes (published as I-D revisions) + and/or direct discussion to designated working groups, area + experts, etc. + + 5. If the IESG approves the document for publication as an RFC, + send a request to IANA to register the requested NID. + +Appendix C -- Changes from RFC 2611 + + This revision of [RFC2611] adds more detail describing the process of + registering a URN namespace identifier (in terms of mechanical + steps). + + This version of the document also separates the process (mechanics) + from the discussion of the requirements for namespaces, attempting to + make the latter as objective as possible. + + Throughout the document, references have been updated to the current + versions of the DDDS and related documentation (which collectively + obsolete [RFC2168] and related drafts). + + + + + + +Daigle, et. al. Best Current Practice [Page 18] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + +C.1 Detailed Document Changes + + Added table of contents + + Section 2 + + Clarified the definition of a URN namespace, the uniqueness of + assignment, and that a single resource may have more than one + identifier associated with it. + + Clarified the "number example" -- that the same string may appear in + 2 different namespaces, and be applied to different resources. + Originally used ISBN/ISSN example, but structurally this is not + possible. + + Section 3 (new) + + This section explicitly defines the 3 categories of namespace -- + Experimental, Informal and Formal. This section provides a + description of the intended use of the different namespace types, as + well as some acceptability guidelines for Formal namespaces (which + require IETF review). + + Section 4.0 + + Spelled out the name of RFC 2434 ("IANA Considerations"). + + Provided a pointer to the IANA URN namespace registry. + + Sections 4.1-4.3 + + New subsection divisions of the existing discussion of individual + namespace types. + + Section 4.2 + + Corrected reference to URN Syntax document (RFC 2141, not RFC 2168). + + Section 4.3 + + Added clarifying text as to the intended nature of Formal namespaces + and processes for registering them. + + Added text to describe the requirement for a "Namespace + Considerations" section in RFCs defining Formal namespaces. Defined + the required content of that section. + + + + + +Daigle, et. al. Best Current Practice [Page 19] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + Added text to describe the new requirement for a "Community + Considerations" section in RFCs defining Formal namespaces. Defined + the required content of that section. + + Added text to explicitly call out the need for an "IANA + Considerations" section in such RFCs, in order to alert IANA to + required action. + + Added text to further clarify the (IETF) process for revising Formal + namespace registrations through the RFC and IETF review process. + + Section 6 + + New section -- added text to describe the IANA considerations for + this document. + + Section 7 -- References + + Added references to revised NAPTR documentation ([RFC3401]), and the + previous version of this document ([RFC2611]). + + Appendix A + + Section created by moving the "URN Namespace Definition Template" + (RFC2611's Section 3) to an appendix. + + Added references to the new requirements for "Namespace + Considerations", "Community Considerations", and "IANA + Considerations" sections for Formal namespace registrations. + + Clarified the "Declared registrant of the namespace" template + element. + + Added text to describe the purpose and scope of the "Validating + Mechanism". + + Appendix B + + Section B.1 is the "example template" that was "Section 5" in RFC + 2611. + + Update the sample "declared registrant" data per the changes to the + template description. + + Removed the reference to "US-ASCII" in the "namespace specific + string" of the example namespace. + + + + + +Daigle, et. al. Best Current Practice [Page 20] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + + Section B.2 (new) + + This added section is a step-by-step walkthrough of the process for + registering Informal namespaces and Formal namespaces. + +Authors' Addresses + + Leslie L. Daigle + Thinking Cat Enterprises + + EMail: leslie@thinkingcat.com + + + Dirk-Willem van Gulik + WebWeaving Internet Engineering + Nieuwsteeg 37A + 2311 RZ Leiden + The Netherlands + + URL: http://www.webweaving.org/ + Email: dirkx@webweaving.org + + + Renato Iannella + IPR Systems Pty Ltd. + + EMail: renato@iprsystems.com + + + Patrik Faltstrom + Cisco Systems Inc + 170 W Tasman Drive SJ-13/2 + San Jose CA 95134 + USA + + EMail: paf@cisco.com + + + + + + + + + + + + + + + +Daigle, et. al. Best Current Practice [Page 21] + +RFC 3406 URN Namespace Definition Mechanisms October 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Daigle, et. al. Best Current Practice [Page 22] + |