doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc3121.txt b/doc/rfc/rfc3121.txt
new file mode 100644
index 0000000..3d6e2f1
--- /dev/null
+++ b/doc/rfc/rfc3121.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                            K. Best
+Request for Comments: 3121                                   OASIS, Inc.
+Category: Informational                                         N. Walsh
+                                                  Sun Microsystems, Inc.
+                                                               June 2001
+
+
+                       A URN Namespace for OASIS
+
+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 URN (Uniform Resource Name) namespace that
+   is engineered by the Organization for the Advancement of Structured
+   Information Standards (OASIS) for naming persistent resources
+   published by OASIS (such as OASIS Standards, XML (Extensible Markup
+   Language) Document Type Definitions, XML Schemas, Namespaces,
+   Stylesheets, and other documents).
+
+1. Introduction
+
+   The Organization for the Advancement of Structured Information
+   Standards (OASIS) produces many kinds of documents: specifications,
+   working drafts, technical resolutions, schemas, stylesheets, etc.
+
+   OASIS wishes to provide global, distributed, persistent, location-
+   independent names for these resources.
+
+   The Extensible Markup Language (XML) requires that all resources
+   provide a system identifier, which must be a URI, in addition to an
+   optional public identifier (which provides an alternate mechanism for
+   constructing identifiers) and many evolving specifications require
+   authors to identify documents by URI alone (XML Namespaces, XML
+   Schema, XSLT, etc.).
+
+   Motivated by these observations, OASIS would like to assign URNs to
+   some resources in order to retain unique, permanent location-
+   independent names for them.
+
+
+
+
+Best & Walsh                 Informational                      [Page 1]
+
+RFC 3121               A URN Namespace for OASIS               June 2001
+
+
+   This namespace specification is for a formal namespace.
+
+2. Specification Template
+
+   Namespace ID:
+
+      "oasis" requested.
+
+   Registration Information:
+
+      Registration Version Number: 3
+      Registration Date: 2001-02-05
+
+   Declared registrant of the namespace:
+
+      Karl Best
+      OASIS - Organization for the Advancement of Structured
+      Information Standards
+      Post Office Box 455
+      Billerica, MA USA 01821
+
+      Phone: +1 (978) 667 5115
+
+   Declaration of structure:
+
+      The Namespace Specific String (NSS) of all URNs assigned by OASIS
+      will have the following hierarchical structure:
+
+      There are two branches at the top of the hierarchy: "names" and
+      "member".
+
+   The Names Hierarchy
+
+      The NSS in the names hierarchy begins with a document class
+      identifier.  There are three classes of identifiers:
+
+      "specification", "tc", and "technical".
+
+      Specifications
+
+         The "specification" hierarchy is for OASIS Specifications.  The
+         general structure of the NSS in the specification hierarchy has
+         the form:
+
+            urn:oasis:names:specification:{specification-id}
+                           :{type}{:subtype}?:{document-id}
+
+
+
+
+
+Best & Walsh                 Informational                      [Page 2]
+
+RFC 3121               A URN Namespace for OASIS               June 2001
+
+
+         where "specification-id" is a unique identifier for the
+         specification, "type" identifies the document type (document,
+         schema, stylesheet, entity, xmlns, etc.), the optional
+         "subtype" provides additional information about the document
+         type (for example, stylesheet or schema language), and
+         "document-id" is a unique identifier for the document.
+
+         The Director of Technical Operations at OASIS assigns document
+         types, subtypes, and all unique identifiers.
+
+      Technical Committee Work Products
+
+         The "tc" hierarchy is for work products of OASIS Technical
+         Committees.  The general structure of the NSS in the tc
+         hierarchy has the form:
+
+            urn:oasis:names:tc:{tc-id}:{type}{:subtype}?:{document-id}
+
+         where "tc-id" is a unique identifier for the Technical
+         Committee, and the remaining fields are assigned as per the
+         specification hierarchy.
+
+      Technical Papers
+
+         The "technical" hierarchy identifies legacy documents
+         (Technical Notes, Resolutions, Memoranda, and Research Papers).
+         The general structure of the NSS in the "technical" hierarchies
+         has the form:
+
+            urn:oasis:names:technical:{document-type}
+                           :{document-id}:{amendment-id}
+
+         The document type is one of the following: "note",
+         "resolution", "memorandum", or "researchpaper".
+
+         The document and amendment identifiers are derived from the
+         legacy system for naming these documents.  The document
+         identifier consists of a two digit year and a sequential
+         number, the amendment identifier is the year of the amendment.
+
+      The Members Hierarchy
+
+         The NSS in the members hierarchy begins with a unique member
+         identifier assigned by OASIS.  The string following the member
+         identifier is opaque.  For example:
+
+            urn:oasis:member:A00024:x
+
+
+
+
+Best & Walsh                 Informational                      [Page 3]
+
+RFC 3121               A URN Namespace for OASIS               June 2001
+
+
+         The member identifiers will be assigned by The Director of
+         Technical Operations at OASIS.  The opaque string is defined by
+         the owner of the branch that begins with
+         "urn:oasis:member:{member-id}:".
+
+   Relevant ancillary documentation:
+
+      None
+
+   Identifier uniqueness considerations:
+
+      Identifier uniqueness will be enforced by the Director of
+      Technical Operations who assigns unique identifiers to all
+      documents identified by URN.
+
+   Identifier persistence considerations:
+
+      OASIS is committed to maintaining the accessibility and
+      persistence of all the resources that are assigned URNs.
+
+   Process of identifier assignment:
+
+      Assignment is limited to the owner and those authorities that are
+      specifically designated by the owner.  OASIS will assign portions
+      of its namespace (specifically, those under the members hierarchy)
+      for assignment by other parties.
+
+   Process of identifier resolution:
+
+      The owner will distribute catalogs (OASIS TR9401 Catalogs) that
+      map the assigned URNs to resource identifiers (e.g., URLs).  A
+      more interactive, online resolution system will also be deployed
+      in the near future.
+
+      The owner will authorize additional resolution services as
+      appropriate.
+
+   Rules for Lexical Equivalence:
+
+      URNs are lexically equivalent if they are lexically identical.
+
+   Conformance with URN Syntax:
+
+      No special considerations.
+
+
+
+
+
+
+
+Best & Walsh                 Informational                      [Page 4]
+
+RFC 3121               A URN Namespace for OASIS               June 2001
+
+
+   Validation mechanism:
+
+      None specified.  The owner will publish OASIS TR9401 Catalogs.
+      The presence of a URN in a catalog indicates that it is valid.
+
+   Scope:
+
+      Global
+
+3. Examples
+
+   The following examples are not guaranteed to be real.  They are
+   listed for pedagogical reasons only.
+
+      urn:oasis:names:specification:docbook:dtd:xml:4.1.2
+      urn:oasis:names:tc:docbook:dtd:xml:docbook:5.0b1
+      urn:oasis:names:technical:memo:9502:1995
+      urn:oasis:member:A00024:x
+
+4. Security Considerations
+
+   There are no additional security considerations other than those
+   normally associated with the use and resolution of URNs in general.
+
+References
+
+   [1] Goldfarb, C. F., "ISO (International Organization for
+       Standardization) ISO 8879:1986(E) Information Processing -- Text
+       and Office Systems -- Standard Generalized Markup Language
+       (SGML)", 1986.
+
+   [2] W3C, XML WG, "Extensible Markup Language (XML) 1.0", February
+       1998, <http://www.w3.org/TR/REC-xml>.
+
+   [3] W3C, Namespaces WG, "Namespaces in XML", January 1999,
+       <http://www.w3.org/TR/REC-xml-names>.
+
+   [4] OASIS, Entity Mgmt. TC, "Entity Management: OASIS Technical
+       Resolution 9401:1997 (Amendment 2 to TR 9401)", January 1994,
+       <http://www.oasis-open.org/html/a401.htm>.
+
+   [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [6] Mealling, M. and R. Daniel, "URI Resolution Services Necessary
+       for URN Resolution", RFC 2483, January 1999.
+
+
+
+
+
+
+Best & Walsh                 Informational                      [Page 5]
+
+RFC 3121               A URN Namespace for OASIS               June 2001
+
+
+Authors' Addresses
+
+   Karl Best
+   OASIS, Inc.
+   P.O. Box 455
+   Billerica, MA  01821
+   US
+
+   EMail: karl.best@oasis-open.org
+
+
+   Norman Walsh
+   Sun Microsystems, Inc.
+   One Network Drive
+   MS UBUR02-201
+   Burlington, MA  01803-0902
+   US
+
+   EMail: Norman.Walsh@East.Sun.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Best & Walsh                 Informational                      [Page 6]
+
+RFC 3121               A URN Namespace for OASIS               June 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Best & Walsh                 Informational                      [Page 7]
+