rfc2611.txt

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


RFC 2611          URN Namespace Definition Mechanisms          June 1999


                                  "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 section 3.0), duly completed, to the

                               [e-mail]

           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:
                                  [e-mail]

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

           Registrations may be updated by the original registrant, or
           an entity designated by the registrant, by updating the
           registration template, submitting it to the discussion list
           for a further 2 week discussion period, and finally
           resubmitting it to IANA, as described above.

      III. Formal:  These are processed through an RFC review process.
           The RFC need not be standards-track.  The template defined in
           section 3.0 may be included as part of an RFC defining some
           other aspect of the namespace, or it may be put forward as an
           RFC in its own right.  The proposed template should be sent
           to the

                               [e-mail]

           mailing list to allow for a 2 week discussion period  for
           clarifying the expression of the registration information,
           before the IESG progresses the document to RFC status.

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




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


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

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

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

   URN namespace registrations will be posted in the anonymous FTP
   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-
   namespaces/".

5.0 Example

   The following example is provided for the purposes of illustration of
   the URN NID template described in section 3.0.  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>

   Declared registrant of the namespace:

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




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


   Declared registrant of the namespace:

      Name:           T. Cat
      E-mail:         [e-mail]
      Affiliation:    Thinking Cat Enterprises
      Address:        1 ThinkingCat Way
                      Trupville, NewCountry

   Declaration of structure:

      The identifier structure is as follows:

      URN:<assigned number>:<FQDN>:<assigned US-ASCII 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",
      RFC1035, 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 10]

RFC 2611          URN Namespace Definition Mechanisms          June 1999


   Process of identifier assignment:

      Assignment of these URNs 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 NAPTR RDS.
      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-insenstive for matches.  The remainder of the identifier
      must be considered case-sensitve.

   Conformance with URN Syntax:

      No special considerations.

   Validation mechanism:

      None specified.

   Scope:

      Global.

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








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


7.0 References

   [RFC2168]   Daniel, R. and M. Mealling, "Resolution of Uniform
               Resource Identifiers using the Domain Name System", RFC
               2168, June 1997.

   [RFC2169]   Daniel, R., "A Trivial Convention for using HTTP in URN
               Resolution", RFC 2169, June 1997.

   [ISO8601]   ISO 8601 : 1988 (E), "Data elements and interchange
               formats - 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.

   [NAPTR-REG] Mealling, M., "Assignment Procedures for NAPTR DNS URI
               Resolution", Work in Progress.

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




















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


8.0 Authors' Addresses

   Leslie L. Daigle
   Thinking Cat Enterprises

   EMail:  [e-mail]


   Dirk-Willem van Gulik
   ISIS/STA/CEO - TP 270
   Joint Research Centre Ispra
   21020 Ispra (Va)
   Italy.

   Phone: [phone] or 5044
   Fax:   [phone]
   EMail:  [e-mail]


   Renato Iannella
   DSTC Pty Ltd
   Gehrmann Labs, The Uni of Queensland
   AUSTRALIA, 4072

   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]


   Patrik Faltstrom
   Tele2/Swipnet
   Borgarfjordsgatan 16
   P.O. Box 62
   S-164 94 Kista
   SWEDEN

   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]












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


9.0  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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 14]