doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc3061.txt b/doc/rfc/rfc3061.txt
new file mode 100644
index 0000000..36594f4
--- /dev/null
+++ b/doc/rfc/rfc3061.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        M. Mealling
+Request for Comments: 3061                                      Verisign
+Category: Informational                                    February 2001
+Obsoletes: 3001
+
+
+                 A URN Namespace of Object Identifiers
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes a Uniform Resource Name (URN) namespace that
+   contains Object Identifiers (OIDs).  It obsoletes RFC 3001.
+
+1. Introduction
+
+   An Object Identifier is a tree of nodes where each node is simply a
+   sequence of digits.  The rules roughly state that once an entity is
+   assigned a node in the Object Identifier (OID) tree, it has sole
+   discretion to further subdelegate sub-trees off of that node. Some
+   examples of OIDs include:
+
+   o  1.3.6.1 - the Internet OID
+   o  1.3.6.1.4.1 - IANA-assigned company OIDs, used for private MIBs
+      and such things
+   o  1.3.6.1.2.1.27 - The Applications MIB
+   o  0.9.2342.19200300.100.4 - Object ID's used in the directory pilot
+      project to identify X.500 Object Classes.  Mostly defined in RFC
+      1274.
+
+   This document specifies the "oid" URN namespace [2].  This namespace
+   is for encoding an Object Identifier as specified in ASN.1 [3] as a
+   URI.  RFC 3001 [1] is obsoleted by this specification.
+
+   The namespace specification is for a formal namespace.
+
+
+
+
+
+
+
+Mealling                     Informational                      [Page 1]
+
+RFC 3061                   OID URN Namespace               February 2001
+
+
+2. Specification Template
+
+   Namespace ID:
+
+      "oid" requested.
+
+   Registration Information:
+
+       Registration Version Number: 1
+       Registration Date: 2000-04-30
+
+   Declared registrant of the namespace:
+
+      The ISO/IEC Joint Technical Committee 1 - SubCommittee 6
+
+         The real authority is the ASN.1 specification itself but SC6 is
+         the committee that has the authority to interpret what that
+         means, thus that committee is listed as the registrant.
+
+   Declaration of structure:
+
+      The NSS portion of the identifier is based on the string encoding
+      rules found in RFC 1778 Section 2.15 [4] which specifies a series
+      of digits separated by a period with the most significant digit
+      being at the left and the least significant being at the right.
+      At no time shall the NSS portion of the URN contain the human
+      readable description of a particular node in the OID tree.  The
+      NSS portion of the name is strictly limited to the digits 0-9 and
+      the '.' character with no leading zeros. No other characters are
+      permitted. This is all expressed in the following ABNF:
+
+           oid             = number *( DOT number )
+           number          = DIGIT / ( LEADDIGIT 1*DIGIT )
+           LEADDIGIT       = %x31-39 ; 1-9
+           DIGIT           = %x30 / LEADDIGIT ; 0-9
+           DOT             = %x2E ; period
+
+      No changes are anticipated since Object Identifiers are fairly
+      simple and have been standardized with no changes for many years.
+
+   Relevant ancillary documentation:
+
+      Relevant documentation can be found in X.660/Amd 2 | ISO/IEC
+      9834-1/Amd 2[3].
+
+
+
+
+
+
+
+Mealling                     Informational                      [Page 2]
+
+RFC 3061                   OID URN Namespace               February 2001
+
+
+   Identifier uniqueness considerations:
+
+      The rules for assignment of OIDs requires that each OID be unique
+      to the OID space and that it cannot be reassigned or reused.  By
+      reference this URN namespace inherents those rules.
+
+   Identifier persistence considerations:
+
+      The rules concerning the use of OIDs requires that they not be
+      reused once assigned.  By reference this URN namespace inherents
+      those rules.
+
+   Process of identifier assignment:
+
+      Once an OID is assigned to some entity, that entity can then
+      create and assign new OIDs below that particular OID.  There are
+      multiple entities that assign new OIDs to the general public.  The
+      top three levels are pre-assigned as follows:
+
+         0 - ITU-T assigned
+         1 - ISO assigned
+         2 - Joint ISO/ITU-T assignment
+
+      several assigned OIDs that are of importance to the Internet are:
+
+         1.3.6.1 - the Internet OID
+         1.3.6.1.4.1 - IANA-assigned company OIDs, used for private
+         MIBs and such things
+
+   Process of identifier resolution:
+
+      At this time no resolution mechanism is defined.
+
+   Rules for Lexical Equivalence:
+
+      OIDs are composed of multiple occurrences of digits and the "."
+      character.  Lexical equivalence is achieved by exact string match.
+
+   Conformance with URN Syntax:
+
+      There are no additional characters reserved.
+
+   Validation mechanism:
+
+      None.
+
+
+
+
+
+
+Mealling                     Informational                      [Page 3]
+
+RFC 3061                   OID URN Namespace               February 2001
+
+
+   Scope:
+
+      Global
+
+3. Examples
+
+   The following examples are taken from the example OIDs from the
+   Introduction:
+
+      urn:oid:1.3.6.1
+      urn:oid:1.3.6.1.4.1
+      urn:oid:1.3.6.1.2.1.27
+      URN:OID:0.9.2342.19200300.100.4
+
+4. Security Considerations
+
+   None not already inherent to using unverifiable OIDs.
+
+5. Acknowledgements
+
+   The author would like to thank Harald Alvestrand for the use of his
+   OID database as a source for examples and references.
+
+References
+
+   [1]  Mealling, M., "A URN Namespace of Object Identifiers", RFC 3001,
+        November 2000.
+
+   [2]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [3]  CCITT, "Specification of Basic Encoding Rules for Abstract
+        Syntax Notation One (ASN.1)", CCITT Recommendation X.209,
+        January 1988.
+
+   [4]  Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
+        Representation of Standard Attribute Syntaxes", RFC 1778, March
+        1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                     Informational                      [Page 4]
+
+RFC 3061                   OID URN Namespace               February 2001
+
+
+Author's Address
+
+   Michael Mealling
+   Verisign
+   505 Huntmar Park Drive
+   Herndon, VA  22070
+   US
+
+   Phone: +1 770 935 5492
+   EMail: michaelm@netsol.com
+   URI:   http://www.netsol.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                     Informational                      [Page 5]
+
+RFC 3061                   OID URN Namespace               February 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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                     Informational                      [Page 6]
+