summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3553.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3553.txt')
-rw-r--r--doc/rfc/rfc3553.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3553.txt b/doc/rfc/rfc3553.txt
new file mode 100644
index 0000000..c88d4bd
--- /dev/null
+++ b/doc/rfc/rfc3553.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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: michael@verisignlabs.com, michael@neonym.net
+ URI: 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: hardie@qualcomm.com
+
+
+ Graham Klyne
+ Nine by Nine
+
+ EMail: GK-IETF@ninebynine.org
+ 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]
+