doc: Add RFC documents

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]
+