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.
AbstractThis 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. 2]URN namespace  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.
RFC 2119. 3], ,  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
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 . 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 . Specifically, due to the URN syntax definitions, the 'stringprep' standard found in RFC 3454  does not apply. Conformance with URN Syntax: There are no additional characters reserved. Validation mechanism: None.
RFC 2141 . 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)  which is part of a series starting with Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401) .
 Moats, R., "URN Syntax", RFC 2141, May 1997.  Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.  Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, February 2002.  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, May 2002.  Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
http://www.verisign.com Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 US Phone: +1 408 536-3024 EMail: LMM@acm.org URI: http://larry.masinter.net Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A. EMail: email@example.com Graham Klyne Nine by Nine EMail: GK-IETF@ninebynine.org URI: http://www.ninebynine.net/
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.