An IETF URN Sub-namespace for Registered Protocol Parameters
RFC 3553
Document | Type |
RFC - Best Current Practice
(June 2003; No errata)
Also known as BCP 73
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | Legacy | ||
Formats | plain text pdf html bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3553 (Best Current Practice) | |
Telechat date | |||
Responsible AD | Patrik Fältström | ||
IESG note | 2003-06: Published as RFC 3553. | ||
Send notices to | <michaelm@neonym.net>, <hardie@qualcomm.com> |
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 theShow full document text