Internet-Draft                                                 L. Daigle
URN WG                                          Thinking Cat Enterprises
Expires May August 11, 2001                                     D. van Gulik
Category: Best Current Practice                               WebWeaving
draft-ietf-urn-rfc2611bis-00.txt
draft-ietf-urn-rfc2611bis-01.txt                             R. Iannella
                                                            DSTC Pty Ltd
                                                             IPR Systems
                                                            P. Faltstrom
                                                                   Cisco
                                                       November 10, 2000
                                                       February 11, 2001

                  URN Namespace Definition Mechanisms

Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     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."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Abstract

   The URN WG has defined a syntax for Uniform Resource Names (URNs)
   [RFC2141], as well as some proposed mechanisms for their resolution
   and use in Internet applications ([RFCXXXX], [RFCYYYY]).  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 ([RFC2288]), and this
   document lays out general definitions of and mechanisms for
   establishing URN "namespaces".

   This document obsoletes RFC2611.

   Discussion of this document should be directed to urn-ietf@ietf.org

Table of Contents

   Abstract ........................................................  1
   Table of Contents ...............................................  2
   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 .....................................................  5
   4.1 Experimental ................................................  5
   4.2 Informal ....................................................  6
   4.3 Formal ......................................................  6
   5.0 Illustration ................................................  8
   5.1 Example Template ............................................  8
   5.1 Registration steps in practice .............................. 10
   6.0 Security Considerations ..................................... 11
   7.0
   6.0 IANA Considerations ......................................... 11
   8.0
   7.0 References .................................................. 11
   9.0
   8.0 Authors' Addresses .......................................... 12
   10.0
   9.0 Appendix A -- URN Namespace Definition Template .............. 13 .............
   10.0 Appendix B -- Illustration .................................
   10.1 Example Template ...........................................
   10.2 Registration steps in practice .............................

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.
   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, along with 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
   DDDS system [RFCXXXX], is necessary.  See [RFCYYYY] 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.  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, ISBNs and ISSNs are both collections of identifiers used
   in the traditional publishing world; while there may be some number
   (or numbers) that is both a valid ISBN identifier and ISSN
   identifier, using different designators for the two collections
   ensures that no two URNs will be the same for different resources.

   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; first,
   a template for the definition is provided.

3.0 URN Namespace (Registration) Types
   There are 3 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.

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, unique identification of resources.  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 an open and broad base of the
   Internet community.  That is, as in any open standards outcome,
   publication of the NID proposal would allow persons not immediately
   associated with the proposer to create new software, or services, work with the identifiers, or
   otherwise better carry out their own activities than if the NID
   publication had not been made.  Benefits are expected to be in the
   form of open accessibility, interoperability, etc.

   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 an externally managed (proprietary) registry (as, e.g., ISBN
   does), for assignment of URNs in the namespace, but it may still
   provide broad community benefit if the services associated have
   openly-published access protocols.

   In addition to the basic registration information defined in the
   registration template (in the Appendix), Appendix A), a formal namespace request
   must be accompanied by documented considerations of the need for a
   new namespace and the community benefit of 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 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 at name assignment
        in order to facilitate 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 it does mean that they must not
        resolve the name to false or stale information, and it means
        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.

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 will be are currently being posted in the
   anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-
   namespaces/". "ftp://ftp.isi.edu/in-
   notes/iana/assignments/URN-namespaces/".  See [STD2] 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>

   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 the
   Appendix),
   Appendix A), duly completed, to the

                           urn-nid@apps.ietf.org

   mailing and allow for a 2 week discussion period for clarifying the
   expression of the registration information and suggestions for
   improvements to the namespace proposal.

   After suggestions for clarification of the registration information
   have been incorporated, the template may be submitted to:

                               iana@iana.org

   for assignment of a NID.

   The only restrictions on <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 the 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

   mailing list to allow for a 2 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 the Internet
   community to be able to benefit by publication of this namespace.
   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)

   A particular NID string is requested, and is assigned by IETF
   consensus (as defined in [RFC2434]), with the additional constraints
   that the NID string must

        - not be an already-registered NID
        - not start with "x-" (see Type I above)
        - not start with "urn-" (see Type II above)
        - not start with "XY-", where XY is any combination of 2
          ASCII letters  (see NOTE, below)
        - be more than 2 letters long

   NOTE: ALL two-letter combinations, and two-letter combinations
   followed by "-" and any sequence of valid NID characters,  are
   reserved for potential use as countrycode- based  NIDs for eventual
   national registrations of URN namespaces.   The definition and
   scoping of rules for allocation of responsibility for such namespaces
   is beyond the scope of this document.

   Registrations may be revised by updating the RFC through standard
   IETF RFC update mechanisms.  Thus, proposals for updates may be made
   by the original authors, other IETF participants, or the IESG.  In
   any case, the proposed updated template must be circulated on the
   urn-nid discussion list, allowing for a 2 week review period.

5.0 Illustration

5.1 Example Template

   The following example is provided Security Considerations

   This document largely focuses on providing mechanisms for the purposes
   declaration of illustration public information.  Nominally, these declarations
   should be of relatively low security profile, however there is always
   the URN NID template described danger of "spoofing" and providing mis-information.  Information
   in these declarations should be taken as advisory.

6.0 IANA Considerations

   This document outlines the Appendix.  Although it is based
   on a hypothetical "generic Internet namespace" that has been
   discussed informally within the processes for registering URN WG, there are still technical namespaces,
   and
   infrastructural issues that would have has implications for the IANA in terms of registries 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>

   Declared registrant of
   maintained.  In all cases, the namespace:

      Required: Name and e-mail address.
      Recommended:  Affiliation, address, etc.

   Declared registrant of IANA should assign the namespace:

      Name:           T. Cat
      E-mail:         leslie@thinkingcat.com
      Affiliation:    Thinking Cat Enterprises
      Address:        1 ThinkingCat Way
                      Trupville, NewCountry

   Declaration of structure:

      The identifier structure is appropriate NID
   (informal or formal), as follows:

      URN:<assigned number>:<FQDN>:<assigned US-ASCII string>

      where FQDN is a fully-qualified domain name, and described above, once an IESG-designated
   expert has confirmed that the assigned
      string is conformant to URN syntax requirements.

   Relevant ancillary documentation:

      Definition of domain names, found in:

      P. Mockapetris, "DOMAIN NAMES requisite registration process steps
   have been completed.

7.0 References

   [ISO8601]   ISO 8601 : 1988 (E), "Data elements and interchange
               formats - IMPLEMENTATION AND SPECIFICATION",
      RFC1035, November 1987.

   Identifier uniqueness considerations:

      Uniqueness is guaranteed as long Information interchange - Representation of
               dates and times"

   [RFC2288]   Lynch, C., Preston, C. and R. Daniel, "Using Existing
               Bibliographic Identifiers as Uniform Resource Names", RFC
               2288, February 1998.

   [RFCXXXX]   Mealling, M., "URI Resolution using the assigned string is never
      reassigned Dynamic
                  Delegation Discovery System", RFCXXXX.

   [RFCYYYY]   Mealling, M., "Assignment Procedures 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 URI Resolution
                 Using DNS", RFCYYYY.

   [RFC2141]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an uncommon occurrence.
      This is one
               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
               October 1998.

   [STD2]    Reynolds, J, and J. Postel, "Assigned Numbers", STD 2,
             October 1994.

   [RFC1737]   Sollins, K. and L. Masinter, "Functional Requirements for
               Uniform Resource Names", RFC 1737, December 1994.

   [RFC2276]   Sollins, K., "Architectural Principles of Uniform
               Resource Name Resolution", RFC 2276, January 1998.

8.0 Authors' Addresses

   Leslie L. Daigle
   Thinking Cat Enterprises

   EMail:  leslie@thinkingcat.com

   Dirk-Willem van Gulik
   WebWeaving
   Plein 1813 - 5a
   8545 HX Arnhem
   The Netherlands

   Phone:  +39 0332 78 0014 (Phone and Fax)
   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
   URL:   http://www.cisco.com

9.0 Appendix A -- URN Namespace Definition Template
   Definition 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 accomplished by completing the level of "FQDN"s, and persistence of FQDN
      assignment.

      Same note as above.

   Process of identifier assignment:

      Assignment of these URNs delegated to individual domain name
      holders (for FQDNs).  The holder
   following information template.  Apart from providing a mechanism for
   disclosing structure of the FQDN registration URN namespace, this information is
      required
   designed to maintain an entry (or delegate it) be useful for

      - entities seeking to have a URN assigned 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 a namespace (if
        applicable)
      - entities seeking to provide URN resolvers for the FQDN in which they have assigned URNs.

   Rules a namespace (if
        applicable)

   This is particularly important for Lexical Equivalence:

      FQDNs are case-insensitive.  Thus, communities evaluating the portion
   possibility of the URN

              urn:<assigned number>:<FQDN>:

      is case-insenstive for matches.  The remainder using a portion of the identifier
      must be considered case-sensitve.

   Conformance with an existing URN Syntax:

      No special considerations.

   Validation mechanism:

      None specified.

   Scope:

      Global.

5.1 Registration steps namespace rather
   than creating their own.

   Information in practice

   The key steps for registration of informal or formal namespaces
   typically play out the template is as follows:

   Informal NID:

     1.  Complete the registration template.  This

   Namespace ID:
      Assigned by IANA.  In some contexts, a particular one may be done as part
     of an Internet-Draft.

     2.  Communicate the registration template
      requested (see below).

   Registration Information:

      This is information to urn-nid@apps.ietf.org
     for technical review -- as a published I-D, or text e-mail message
     containing the template.

     3. Update identify the particular version of
      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) end a request to IANA information:

      - registration version number: starting with the revised 1, incrementing by 1
        with each new version
      - registration
     template.

   Formal NID:

     1. Write an Internet-Draft describing date: date submitted to the namespace and including IANA, using the registration template, duly completed.

     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 format
                                YYYY-MM-DD

        as needed.

     4.  Send a request to outlined in [ISO8601].

   Declared registrant of the IESG to publish namespace:
      This includes:
         Registering organization
            Name
            Address
         Designated contact person
            Name
            Coordinates (at least one of: e-mail, phone, postal address)

   Declaration of syntactic structure:

      This section should outline any structural features of identifiers
      in this namespace.  At the I-D as an RFC.  The
     IESG very least, this description 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 be
      used to register the requested NID.

6.0 Security Considerations introduce terminology used in other sections.  This document largely focuses on providing mechanisms
      structure may also be used for the
   declaration of public information.  Nominally, these declarations determining realistic
      caching/shortcuts approaches; suitable caveats should be of relatively low security profile, however provided.

      If there is are any specific character encoding rules (e.g., which
      character should always
   the danger of "spoofing" and providing mis-information.  Information
   in be used for single-quotes), these declarations should
      be taken as advisory.

7.0 IANA Considerations

   This document outlines listed here.

      Answers might include, but are not limited to:

      - the processes for registering URN namespaces,
   and has implications structure is opaque (no exposition) - a regular expression
        for parsing the IANA in terms of registries to be
   maintained.  In all cases, the IANA identifier into components, including naming
        authorities

   Relevant ancillary documentation:

      This section should assign the appropriate NID
   (informal list any RFCs, standards, or formal), as described above, once an IESG-designated
   expert has confirmed other published
      documentation that the requisite registration process steps
   have been completed.

8.0 References
   [ISO8601]   ISO 8601 : 1988 (E), "Data elements and interchange
               formats - Information interchange - Representation defines or explains all or part of
               dates and times"

   [RFC2288]   Lynch, C., Preston, C. and R. Daniel, "Using Existing
               Bibliographic Identifiers as Uniform Resource Names", RFC
               2288, February 1998.

   [RFCXXXX]   Mealling, M., "URI Resolution using the Dynamic
                  Delegation Discovery System", RFCXXXX.

   [RFCYYYY]   Mealling, M., "Assignment Procedures for URI Resolution
                 Using DNS", RFCYYYY.

   [RFC2141]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
               October 1998.

   [RFC1737]   Sollins, K. and L. Masinter, "Functional Requirements for
               Uniform Resource Names", RFC 1737, December 1994.

   [RFC2276]   Sollins, K., "Architectural Principles of Uniform
               Resource Name Resolution", RFC 2276, January 1998.

9.0 Authors' Addresses

   Leslie L. Daigle
   Thinking Cat Enterprises

   EMail:  leslie@thinkingcat.com

   Dirk-Willem van Gulik
   WebWeaving
   Plein 1813 - 5a
   8545 HX Arnhem
   The Netherlands

   Phone:  +39 0332 78 0014 (Phone and Fax)
   EMail:  Dirkx@webweaving.org

   Renato Iannella
   DSTC Pty Ltd
   Gehrmann Labs, The Uni
      namespace structure.

      Answers might include, but are not limited to:

      - RFCs outlining syntax of Queensland
   AUSTRALIA, 4072

   Phone:  +61 7 3365 4310
   Fax:    +61 7 3365 4311
   EMail:  renato@dstc.edu.au

   Patrik Faltstrom
   Cisco Systems Inc
   170 W Tasman Drive SJ-13/2
   San Jose CA 95134
   USA

   EMail: paf@cisco.com
   URL:   http://www.cisco.com

10.0 Appendix -- URN Namespace Definition Template

   Definition the namespace
      - Other of a URN the defining community's (e.g., ISO) documents
        outlining syntax of the identifiers in the namespace is accomplished by completing
      - Explanatory material introducing the
   following 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 template.  Apart from providing on "Today's Weather" might be considered a mechanism for
   disclosing single
   resource, although the content is dynamic.)

   Possible answers include, but are not limited to:

      - exposition of the structure of the URN namespace, this information is
   designed to be useful identifiers, and partitioning
        of the space of identifiers amongst assignment authorities which
        are individually responsible for respecting uniqueness rules
      - entities seeking to have a URN identifiers are assigned in a namespace (if
        applicable) sequentially
      - entities seeking to provide URN resolvers for a namespace (if
        applicable)

   This information is particularly important for communities evaluating withheld; the
   possibility namespace is opaque

   Identifier persistence considerations:

      Although non-reassignment of using URN identifiers ensures that a portion of an existing URN namespace rather
   than creating their own.

   Information
      will persist in the template is as follows:

   Namespace ID:
      Assigned by IANA.  In some contexts, identifying a particular one may be
      requested (see below).

   Registration Information:

      This is information resource even after the
      "lifetime of the resource", some consideration should be given to identify
      the particular version persistence of
      registration information:

      - registration version number: starting with 1, incrementing by 1
        with each new version
      - registration date: date submitted to the IANA, using usability of the format
            YYYY-MM-DD
        as outlined URN.  This is particularly
      important in [ISO8601].

   Declared registrant of the namespace:

      Required: Name and e-mail address.
      Recommended:  Affiliation, address, etc.

   Declaration case of syntactic structure: URN namespaces providing global
      resolution.

      Possible answers include, but are not limited to:

      - quality of service considerations

   Process of identifier assignment:

      This section should outline any structural features of identifiers
      in this namespace.  At detail 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 mechanisms and/or authorities for single-quotes), these
      assigning URNs to resources.  It should
      be listed here. 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 might could include, but are not
      limited to:

      - the structure assignment is opaque (no exposition) 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 regular expression private
        organization)

   Process for parsing identifier resolution:

      If a namespace is intended to be accessible for global resolution,
      it must be registerd in an RDS (Resolution Discovery System, see
      [RFC2276]) such as DDDS.  Resolution then proceeds according to
      standard URI resolution processes, and the identifier into components, including naming
        authorities

   Relevant ancillary documentation:

      This mechanisms of the RDS.
      What this section should list any RFCs, standards, or other published
      documentation that defines or explains all or part of outline is the requirements for becoming
      a recognized resolver of URNs in this namespace structure. (and being so-
      listed in the RDS registry).

      Answers might may include, but are not limited to:

      - RFCs outlining syntax of the namespace is not listed with an RDS; this is not relevant
      - Other of the defining community's (e.g., ISO) documents
        outlining syntax of the resolution mirroring is completely open, with a mechanism for
        updating an appropriate RDS
      - resolution is controlled by entities to which assignment has
        been delegated

   Rules for Lexical Equivalence:

      If there are particular algorithms for determining equivalence
      between two identifiers in the underlying namespace
      - Explanatory material introducing the namespace

   Identifier uniqueness considerations: This section should address (hence, in the
   requirement that
      URN identifiers string itself), rules can be assigned uniquely -- they are
   assigned to at most one resource, provided here.

      Some examples include:

      - equivalence between hyphenated 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 non-hyphenated groupings in
        the content is dynamic.)

   Possible answers include, but are not limited to: identifier string
      - exposition of the structure of the identifiers, equivalence between single-quotes and partitioning
        of the space of identifiers amongst assignment authorities which double-quotes
      - Namespace-defined equivalences between specific characters, such
        as "character X with or without diacritic marks".

      Note that these are individually responsible not normative statements for any kind of best
      practice for respecting uniqueness rules
      - identifiers handling equivalences between characters; they are assigned sequentially
      - information is withheld;
      statements limited to reflecting the namespace is opaque

   Identifier persistence considerations:

      Although non-reassignment of URN identifiers ensures that a namespace's own rules.

   Conformance with URN
      will persist in identifying a particular resource even after the
      "lifetime of the resource", some consideration Syntax:

      This section should be given to
      the persistence of the usability of outline any special considerations required
      for conforming with the URN. URN syntax.  This is particularly
      important
      applicable in the case of URN namespaces providing global
      resolution.

      Possible answers include, but legacy naming systems that are not limited to:

      - quality used in
      the context of service considerations

   Process URNs.

      For example, if a namespace is used in contexts other than URNs,
      it may make use of identifier assignment: characters that are reserved in the URN syntax.
      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 flag any such characters, and outline
      necessary mappings 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 conform to authorities recognized URN syntax.  Normally, this will
      be handled by a
        particular organization (e.g., hex encoding the Digital Object Identifier
        Foundation controls symbol.

      For example, see the DOI assignment space and its delegation)
      - assignment is completely closed (e.g., section on SICIs in [RFC2288].

   Validation mechanism:

      Apart from attempting resolution of a URN, a URN namespace may
      provide mechanism for "validating" a private
        organization)

   Process for identifier resolution:

      If URN -- i.e., determining
      whether a given string is currently a validly-assigned URN.  For
      example, even if an ISBN URN namespace is intended to be accessible for global resolution, created, it must be registerd in is not clear
      that all ISBNs will translate directly into "assigned URNs".

      A validation mechanims might be:

      - a syntax grammar
      - an RDS (Resolution Discovery System, see
      [RFC2276]) such as DDDS.  Resolution then proceeds according to
      standard URI resolution processes, and on-line service
      - an off-line service

   Scope:

      This section should outline the mechanisms scope of the RDS.
      What use of the
      identifiers in this namespace.  Apart from considerations of
      private vs. public namespaces, this section should outline is critical in
      evaluating the requirements for becoming
      a recognized resolver applicability of URNs in this a requested NID.  For example, a
      namespace (and being so-
      listed claiming to deal in "social security numbers" should
      have a global scope and address all social security number
      structures (unlikely).  On 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 other hand, at a mechanism for
        updating an appropriate RDS
      - resolution national level, it
      is controlled by entities reasonable to which assignment has
        been delegated

   Rules propose a URN namespace for Lexical Equivalence:

      If there are particular algorithms "this nation's social
      security numbers".

10.0 Appendix B -- Illustration

10.1 Example Template

   The following example is provided for determining equivalence
      between two identifiers in the underlying namespace (hence, purposes of illustration of
   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 string itself), rules can WG, there are still technical and
   infrastructural issues that would have to be provided here.

      Some examples include:

      - equivalence between hyphenated resolved before such a
   namespace could be properly and non-hyphenated groupings in completely described.

   Namespace ID:
      To be assigned

   Registration Information:

      Version 1
      Date: <when submitted>

   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 string
      - equivalence between single-quotes structure is as follows:

      URN:<assigned number>:<FQDN>:<assigned string>

      where FQDN is a fully-qualified domain name, and double-quotes the assigned
      string is conformant to URN syntax requirements.

   Relevant ancillary documentation:

      Definition of domain names, found in:

      P. Mockapetris, "DOMAIN NAMES - Namespace-defined equivalences between specific characters, such IMPLEMENTATION AND SPECIFICATION",
      RFC1035, November 1987.

   Identifier uniqueness considerations:

      Uniqueness is guaranteed as long 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 assigned string is never
      reassigned for conforming with a given FQDN, and that the URN syntax. 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 particularly
      applicable in the case one of legacy naming systems that are used in the context of URNs.

      For example, if reasons that this example makes a poor URN
      namespace is used in contexts other than URNs, practice, and is therefore not seriously being
      proposed as it may make use stands.

   Identifier persistence considerations:

      Persistence of characters that are reserved in identifiers is dependent upon suitable delegation
      of resolution at the URN syntax.
      This section should flag any such characters, level of "FQDN"s, and outline
      necessary mappings to conform persistence of FQDN
      assignment.

      Same note as above.

   Process of identifier assignment:

      Assignment of these URNs delegated to URN syntax.  Normally, this will
      be handled by hex encoding the symbol.

      For example, see individual domain name
      holders (for FQDNs).  The holder of the section on SICIs FQDN registration is
      required to maintain an entry (or delegate it) in [RFC2288].

   Validation mechanism:

      Apart from attempting resolution the DDDS.
      Within each of a URN, a URN namespace these delegated name partitions, the string may
      provide mechanism be
      assigned per local requirements.

      e.g.  urn:<assigned number>:thinkingcat.com:001203

   Process for "validating" a 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 -- i.e., determining
      whether a given string

              urn:<assigned number>:<FQDN>:

      is currently a validly-assigned URN.  For
      example, even if an ISBN case-insenstive for matches.  The remainder of the identifier
      must be considered case-sensitve.

   Conformance with URN namespace is created, it is not clear
      that all ISBNs will translate directly into "assigned URNs".

      A validation mechanims might be:

      - a syntax grammar
      - an on-line service
      - an off-line service Syntax:

      No special considerations.

   Validation mechanism:

      None specified.

   Scope:

      This section should outline the scope

      Global.

10.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 use registration template.  This may be done as part
     of an Internet-Draft.

     2.  Communicate the
      identifiers in this namespace.  Apart 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 considerations of
      private vs. public namespaces, this section is critical in
      evaluating comments, and
     repeat steps 2 and 3 as necessary.

     4. Once comments have been addressed (and the applicability of a requested NID.  For example, review period has
     expired) end a
      namespace claiming request to deal in "social security numbers" should
      have a global scope IANA with the revised registration
     template.

   Formal NID:

     1. Write an Internet-Draft describing the namespace and address all social security number
      structures (unlikely).  On including
     the other hand, at registration template, duly completed.

     2. Send the Internet-Draft to the I-D editor, and send a national level, it
      is reasonable copy to propose
     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 URN namespace 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 "this nation's social
      security numbers". publication as an RFC,
     send a request to IANA to register the requested NID.