From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3553.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc3553.txt (limited to 'doc/rfc/rfc3553.txt') 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] + -- cgit v1.2.3