Network Working Group                                        M. Mealling
Request for Comments: 3553                                      VeriSign
BCP: 73                                                      L. Masinter
Category: Best Current Practice                            Adobe Systems
                                                              T. Hardie
                                                               Qualcomm
                                                               G. Klyne
                                                           Nine by Nine
                                                              June 2003


     An IETF URN Sub-namespace for Registered Protocol Parameters

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

Abstract

  This document describes a new sub-delegation for the 'ietf' URN
  namespace for registered protocol items.  The 'ietf' URN namespace is
  defined in RFC 2648 as a root for persistent URIs that refer to
  IETF-defined resources.

1.  Introduction

  From time to time IETF standards require the registration of various
  protocol elements in well known central repository.  The Internet
  Assigned Numbers Authority maintains this central repository and
  takes direction from the IETF on what, how and when to add items to
  it.  The IANA maintains lists of items such as all assigned port
  numbers, MIME media types, enterprise numbers, etc.

  Over time there has developed a need to be able to reference these
  elements as URIs in various schema.  In the past this was done in a
  very ad hoc way that easily led to interoperability problems.  This
  document creates a new sub-delegation below the "ietf" [2]URN
  namespace [1] called 'params' which acts as a standardized mechanism
  for naming the items registered for IETF standards.  Any assignments
  below that are specified in an RFC according to the IETF consensus
  process and which include the template found in Section 4.




Mealling, et. al.        Best Current Practice                  [Page 1]

RFC 3553                   IANA URN Namespace                  June 2003


2.  Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119.

3.  IETF Sub-namespace Specifics

  Sub-namespace name:

     params

  Declared registrant of the namespace:

     The Internet Engineering Task Force

  Declaration of structure:

     The namespace is primarily opaque.  The IANA, as operator of the
     registry, may take suggestions for names to assign but they
     reserve the right to assign whatever name they desire, within
     guidelines set by the IESG.  The colon character (":") is used to
     denote a very limited concept of hierarchy.  If a colon is present
     then the items on both sides of it are valid names.  In general,
     if a name has a colon then the item on the left hand side
     represents a class of those items that would contain other items
     of that class.  For example, a name can be assigned to the entire
     list of DNS resource record type codes as well as for each
     individual code.  The URN for the list might look like this:

           urn:ietf:params:dns:rr-type-codes

     while the URN for the SOA records type code might look like this:

           urn:ietf:params:dns:rr-type-codes:soa

  Relevant ancillary documentation:

     [3], [2], [1]

  Identifier uniqueness considerations:

     The IESG uses the IETF consensus process to ensure that
     sub-namespaces generate unique names within that
     sub-namespace.  The IESG delegates to the IANA the task of
     ensuring that the sub-namespace names themselves are unique.
     Until and unless the IESG specifies differently, the IANA is
     directed to ensure uniqueness by comparing the name to be assigned



Mealling, et. al.        Best Current Practice                  [Page 2]

RFC 3553                   IANA URN Namespace                  June 2003


     with the list of previously assigned names.  In the case of a
     conflict the IANA is to request a new string from the registrant
     until the conflict is resolved.

  Identifier persistence considerations:

     Once a name has been allocated it MUST NOT be re-allocated for a
     different purpose.  The rules provided for assignments of values
     within a sub-namespace MUST be constructed so that the meaning of
     values cannot change.  This registration mechanism is not
     appropriate for naming values whose meaning may change over time.
     If a value that changes over time the assignment MUST name the
     container or concept that contains the value, not the value
     itself.  For example, if a parameter called 'foo' has a value that
     changes over time, it is valid to create the name
     'urn:ietf:params:foo-params:foo' that identifies that 'slot'.  It
     is not valid to actually create a name that contains that value
     unless it is a persistent and unique value such as a version
     number.

  Process of identifier assignment:

     Identifiers are assigned only after a particular protocol element
     or number has been registered with the IANA using standard
     policies and procedures, or documented in an RFC describing a
     standards track protocol.  This means that the 'gating' function
     for assignment is the "IETF Consensus" process documented in RFC
     2434 [4].

  Process of identifier resolution:

     At this time no resolution mechanism is defined.

  Rules for Lexical Equivalence:

     Lexical equivalence is achieved by exact string match according to
     the rules for URN syntax found in RFC 2141 [1].  Specifically, due
     to the URN syntax definitions, the 'stringprep' standard found in
     RFC 3454 [7] does not apply.

  Conformance with URN Syntax:

     There are no additional characters reserved.

  Validation mechanism:

     None.




Mealling, et. al.        Best Current Practice                  [Page 3]

RFC 3553                   IANA URN Namespace                  June 2003


  Scope:

     Global

4.  Assigning Names

  The creation of a new registry name will be simple for most flat
  registries.  The only required elements will be the registry name, a
  reference to relevant documents, a statement about which
  current/proposed document repositories contains the authoritative
  data for the registry, and a statement specifying which element in
  the registry is the value to be used in the URN.  In most cases this
  last element will be the index value assigned by the IANA.

  More complex registries (DNS Parameters for example) will need to
  repeat that information for any sub-namespaces.  It should also be
  clear as to whether or not a name is assigned to the sub-namespace
  itself (i.e., is 'urn:ietf:params:dns:rr-types' valid by itself and
  if so, what does it name?).

  The template:

  Registry name: -- The name of the sub-namespace.  In many cases this
     should be the same name that the IANA calls the registry itself.

  Specification: -- Relevant IETF published documents that define the
     registry and the items in it.

  Repository: -- A pointer to the 'current' location of the registry in
     the protocol parameters repository or the relevant RFCs that
     document the items being named.  This value will change over time
     as the entity that maintains the repository moves files and or
     fileservers.  It is not meant as a permanent binding to the
     filename but as a hint to the IANA for what the initial mapping
     would be.

  Index value: -- Description of how a registered value is to be
     embedded in the URI form.  This MUST include details of any
     transformations that may be needed for the resulting string to
     conform to URN syntax rules and any canonicalization needed so
     that the case-sensitive string comparison yields the expected
     equivalences.

  The process for requesting that a URN be assigned is currently to put
  the above template or a reference to it in the IANA considerations
  section of the specifying document.  Other more automated processes
  may be proposed at a latter time if demand requires it.




Mealling, et. al.        Best Current Practice                  [Page 4]

RFC 3553                   IANA URN Namespace                  June 2003


5.  Security Considerations

  None not already inherent to using URNs.  Security considerations for
  URNs in general can be found in RFC 2141 [1].  Further security
  considerations for one specific URN resolution method can be found in
  Dynamic Delegation  Discovery System (DDDS) Part Four: The Uniform
  Resource Identifiers (URI) Resolution Application (RFC 3404) [5]
  which is part of a series starting with Dynamic  Delegation Discovery
  System (DDDS) Part One: The Comprehensive DDDS  (RFC 3401) [6].

6.  IANA Considerations

  This document puts a new and significant burden on the IANA since it
  may require an additional assignment process to happen for each new
  IANA registry.  To minimize the administrative burden on IANA, any
  parameter namespace registration is very clear about the criteria for
  inclusion in that namespace.

  Defining a registry that fits the constraints of a URN namespace will
  impose extra discipline that should take some of the guess-work about
  creating and maintaining that registry.

7.  Intellectual Property Statement

  The IETF takes no position regarding the validity or scope of any
  intellectual property or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; neither does it represent that it
  has made any effort to identify any such rights.  Information on the
  IETF's procedures with respect to rights in standards-track and
  standards-related documentation can be found in BCP-11.  Copies of
  claims of rights made available for publication and any assurances of
  licenses to be made available, or the result of an attempt made to
  obtain a general license or permission for the use of such
  proprietary rights by implementors or users of this specification can
  be obtained from the IETF Secretariat.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights which may cover technology that may be required to practice
  this standard.  Please address the information to the IETF Executive
  Director.








Mealling, et. al.        Best Current Practice                  [Page 5]

RFC 3553                   IANA URN Namespace                  June 2003


8.  Normative References

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

  [2]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
       August 1999.

  [3]  Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
       "Uniform Resource Names (URN) Namespace Definition Mechanisms",
       BCP 66, RFC 3406, October 2002.

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

  [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
       Four: The Uniform Resource Identifiers (URI)", RFC 3404,
       February 2002.

  [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
       One: The Comprehensive DDDS", RFC 3401, May 2002.

  [7]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
       Strings ("stringprep")", RFC 3454, December 2002.




























Mealling, et. al.        Best Current Practice                  [Page 6]

RFC 3553                   IANA URN Namespace                  June 2003


9.  Authors' Addresses

  Michael Mealling
  VeriSign
  21345 Ridgetop Circle
  Sterling, VA  20166
  US

  EMail: [email protected], [email protected]
  URI:   http://www.verisign.com


  Larry Masinter
  Adobe Systems Incorporated
  345 Park Ave
  San Jose, CA  95110
  US

  Phone: +1 408 536-3024
  EMail: [email protected]
  URI:   http://larry.masinter.net


  Ted Hardie
  Qualcomm, Inc.
  675 Campbell Technology Parkway
  Suite 200
  Campbell, CA
  U.S.A.

  EMail: [email protected]


  Graham Klyne
  Nine by Nine

  EMail: [email protected]
  URI:   http://www.ninebynine.net/













Mealling, et. al.        Best Current Practice                  [Page 7]

RFC 3553                   IANA URN Namespace                  June 2003


10.  Full Copyright Statement

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



















Mealling, et. al.        Best Current Practice                  [Page 8]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.