rfc2611.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          L. Daigle
Request for Comments: 2611                      Thinking Cat Enterprises
BCP: 33                                                     D. van Gulik
Category: Best Current Practice                      ISIS/CEO, JRC Ispra
                                                             R. Iannella
                                                            DSTC Pty Ltd
                                                            P. Faltstrom
                                                           Tele2/Swipnet
                                                               June 1999


                  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 (1999).  All Rights Reserved.

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 ([RFC2168, RFC2169]). 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".

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



Daigle, et al.           Best Current Practice                  [Page 1]

RFC 2611          URN Namespace Definition Mechanisms          June 1999


   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
   NAPTR system [RFC2168], is necessary.  See [NAPTR-REG] for
   information on obtaining registration in the NAPTR 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.






Daigle, et al.           Best Current Practice                  [Page 2]

RFC 2611          URN Namespace Definition Mechanisms          June 1999


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

   Information in the template is as follows:

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

   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
            YYYY-MM-DD
        as outlined in [ISO8601].

   Declared registrant of the namespace:

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






Daigle, et al.           Best Current Practice                  [Page 3]

RFC 2611          URN Namespace Definition Mechanisms          June 1999


   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 4]

RFC 2611          URN Namespace Definition Mechanisms          June 1999


   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 registerd in an RDS (Resolution Discovery System, see
      [RFC2276]) such as NAPTR.  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 5]

RFC 2611          URN Namespace Definition Mechanisms          June 1999


   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 mechanism for "validating" a URN -- i.e., determining
      whether a given string is currently a validly-assigned URN.  For
      example, even if an ISBN 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





Daigle, et al.           Best Current Practice                  [Page 6]

RFC 2611          URN Namespace Definition Mechanisms          June 1999


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

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 [RFC2434] document suggests the need to
   specify update mechanisms for registrations -- who is given the
   authority to do so, from time to time, and what are the processes.
   Since URNs are meant to be persistently useful, few (if any) changes
   should be made to the structural interpretation of URN strings (e.g.,
   adding or removing rules for lexical equivalence that might affect
   the interpretation of URN IDs already assigned).  However, it may be
   important to introduce clarifications, expand the list of authorized
   URN assigners, etc, over the natural course of a namespace's
   lifetime.  Specific processes are outlined below.

   There are 3 categories of URN namespaces defined here, distinguished
   by expected level of service and required procedures for
   registration.  Furthermore, registration maintenance procedures vary
   slightly from one category to another.

      I.   Experimental: These are not explicitly registered with IANA.
           They take the form

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

      II.  Informal:  These are registered with IANA and are assigned a
           number sequence as an identifier, in the format:




Daigle, et al.           Best Current Practice                  [Page 7]