doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc4198.txt b/doc/rfc/rfc4198.txt
new file mode 100644
index 0000000..0a2d0b2
--- /dev/null
+++ b/doc/rfc/rfc4198.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         D. Tessman
+Request for Comments: 4198                                      Zelestra
+Category: Informational                                    November 2005
+
+
+     A Uniform Resource Name (URN) Namespace for Federated Content
+
+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 (2005).
+
+Abstract
+
+   This document describes a URN (Uniform Resource Name) namespace for
+   identifying content resources within federated content collections.
+   A federated content collection often does not have a strong
+   centralized authority but relies upon shared naming, metadata, and
+   access conventions to provide interoperability among its members.
+
+1.  Introduction
+
+   Federated content collections are often loose constructs of both
+   small and large content providers, with an active community, but
+   without significant central authority.  Members are bound together by
+   shared purpose and interoperate through shared naming, metadata, and
+   access conventions.  Federations may also consist of other
+   federations, creating complex associations and dependencies.
+
+   A content provider may join or leave a federation at any time and may
+   be part of more than one federation at the same time.  Content
+   providers may also cease as organizations altogether, freeing their
+   domain names for use by others.  In addition, content identifiers are
+   spread throughout the members of a federation.  These identifiers are
+   stored on various media, sometimes for long durations before being
+   used.  Therefore, although they work well in situations without a
+   strong content naming authority, URLs are insufficient as content
+   identifiers within a federation because they cannot be uniquely and
+   permanently tied to a specific content resource.
+
+
+
+
+
+
+
+Tessman                      Informational                      [Page 1]
+
+RFC 4198          URN Namespace for Federated Content      November 2005
+
+
+   This URN namespace provides a mechanism whereby a central naming
+   authority is not required.  Providers maintain naming authority over
+   their own content within guidelines that guarantee URNs to be unique
+   and permanent.
+
+   A simple identifier resolution convention is also recommended to
+   provide a consistent URN resolver interface across all providers.
+
+   This namespace specification is for a formal namespace.
+
+2.  Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
+
+3.  Specification Template
+
+   Namespace ID:
+
+      "fdc"
+
+   Registration Information:
+
+      Registration Version Number: 1
+      Registration Date: 2005-04-25
+
+   Declared registrant of the namespace:
+
+      Name:       Zelestra
+      Address:    2314 Henrietta Avenue
+                  La Crescenta, CA 91214-3007
+                  USA
+
+      Contact:    Dave Tessman
+      E-mail:     dtessman@zelestra.com
+
+   Declaration of syntactic structure:
+
+      The NSS has the following ABNF [2] specification:
+
+      NSS         = ProviderId ":" DateId ":" ResourceId
+      ProviderId  = 1*(label ".") toplabel
+      DateId      = (CCYY [MM [DD]]) / 1*3(DIGIT)
+      ResourceId  = 1*(alphanum / other / ("%" hex hex))
+      label       = alphanum / alphanum *(alphanum / "-") alphanum
+      toplabel    = ALPHA / ALPHA *(alphanum / "-") alphanum
+      CCYY        = 4(DIGIT)
+
+
+
+Tessman                      Informational                      [Page 2]
+
+RFC 4198          URN Namespace for Federated Content      November 2005
+
+
+      MM          = ("0" %x31-39) / ("1" %x30-32)
+      DD          = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"
+      alphanum    = ALPHA / DIGIT
+      hex         = DIGIT / %x41-46 / %x61-66
+      other       = "(" / ")" / "+" / "," / "-" / "." / ":" / "=" /
+                    "@" / ";" / "$" / "_" / "!" / "*" / "'"
+
+      ProviderId is the content provider's identifier.  ProviderId MUST
+      be an Internet domain name and MUST be owned by the organization
+      creating the resource and allocating the URN to the resource.
+
+      DateId is a date in ISO 8601 Basic Format (CCYY[MM[DD]]), and MUST
+      correspond to a specific day on which the organization allocating
+      the URN owned the domain name specified in the ProviderId.  If not
+      included, the default value for MM and DD is "01".  DateIds of 1
+      to 3 digits are reserved.
+
+      ResourceId MUST be unique among all ResourceIds emanating from the
+      same provider and having the same DateId.
+
+   Relevant ancillary documentation:
+
+      None.
+
+   Identifier uniqueness considerations:
+
+      The combination of ProviderId and DateId serves to uniquely
+      identify the organization that is allocating the URN.  That
+      organization is responsible for ensuring the uniqueness of the
+      ResourceId.
+
+   Identifier persistence considerations:
+
+      A URN of this namespace may only be allocated by an organization
+      that owns an Internet domain name.  The URN identifies a date on
+      which the organization owned that domain name.  The combination of
+      domain name and date will serve to uniquely identify that
+      organization for all time.
+
+   Process of identifier assignment:
+
+     The organization identified by the ProviderId/DateId combination is
+     responsible for allocating a ResourceId that is unique among all
+     those that it allocates with that DateId.
+
+
+
+
+
+
+
+Tessman                      Informational                      [Page 3]
+
+RFC 4198          URN Namespace for Federated Content      November 2005
+
+
+   Process of identifier resolution:
+
+     Content providers are responsible for the provision of a URN
+     resolution service, if any, for URNs they have assigned with a
+     valid ProviderId/DateId combination.
+
+     Content providers SHOULD support URN resolution by using the HTTP
+     protocol convention described in RFC 2169 [3].  The ProviderId
+     SHOULD be used as the HTTP server location.
+
+   Rules for Lexical Equivalence:
+
+      In addition to the rules defined in RFC 2141 [4], normalize the
+      case of the ProviderId to lower case before comparison.
+
+   Conformance with URN Syntax:
+
+      There are no additional characters reserved.
+
+   Validation mechanism:
+
+      None additional to resolution specified.
+
+   Scope:
+
+      Global
+
+4.  Examples
+
+   The following examples are representative of URNs in this namespace,
+   but may not refer to actual resources.
+
+   urn:fdc:example.com:2002:A572007
+   urn:fdc:example.net:200406:ivr:51089
+   urn:fdc:example.org:20010527:img089322-038
+
+5.  Security Considerations
+
+   There are no additional security considerations other than those
+   normally associated with the use and resolution of URNs in general.
+
+6.  Namespace Considerations
+
+   Distribution of naming authority, identifier flexibility, and a
+   recommended URN resolution mechanism make this namespace a unique and
+   valuable tool to meet the URN requirements of small content providers
+   and federated content collections.
+
+
+
+
+Tessman                      Informational                      [Page 4]
+
+RFC 4198          URN Namespace for Federated Content      November 2005
+
+
+7.  Community Considerations
+
+   By establishing a simple, flexible, and efficient means for smaller
+   content providers to uniquely identify and publish their content,
+   this namespace reduces the effort required for these providers to
+   participate in federated collections.  A consistent identifier format
+   and resolution mechanism also increases the ability of federations to
+   accept content references from smaller providers and to aggregate
+   themselves into federations of federations.  Increased participation
+   and aggregation results in a larger selection of distinctive content
+   that is more accessible to the community.
+
+   To make use of this namespace, a content provider should further
+   decompose the ResourceId portion of the namespace syntactic structure
+   to meet their internal content identification needs and establish an
+   internal governance mechanism to ensure that all identifiers created
+   follow the requirements of this namespace.  It is also recommended
+   that the identifier resolution mechanism described in RFC 2169 [3] be
+   provisioned within an HTTP server designated by the ProviderId
+   portion of the namespace syntactic structure.
+
+8.  IANA Considerations
+
+   This document includes a URN NID registration that conforms to RFC
+   3406 [5] and has been entered into the IANA registry of URN NIDs.
+
+Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 4234, October 2005.
+
+   [3]  Daniel, R., "A Trivial Convention for using HTTP in URN
+        Resolution", RFC 2169, June 1997.
+
+   [4]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+Informative References
+
+   [5]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
+        "Uniform Resource Names (URN) Namespace Definition Mechanisms",
+        BCP 66, RFC 3406, October 2002.
+
+
+
+
+
+
+
+Tessman                      Informational                      [Page 5]
+
+RFC 4198          URN Namespace for Federated Content      November 2005
+
+
+Author's Address
+
+   Dave Tessman
+   Zelestra
+   2314 Henrietta Avenue
+   La Crescenta, California 91214-3007
+   USA
+
+   Phone: +1 818 249 8906
+   EMail: dtessman@zelestra.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tessman                      Informational                      [Page 6]
+
+RFC 4198          URN Namespace for Federated Content      November 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Tessman                      Informational                      [Page 7]
+