An IETF URN Sub-namespace for Registered Protocol Parameters
RFC 3553

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 14

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