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/rfc4198.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc4198.txt (limited to 'doc/rfc/rfc4198.txt') 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] + -- cgit v1.2.3