idnits 2.17.1 draft-dtessman-urn-namespace-federated-content-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 266. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 258), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2005) is 6950 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 231, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 242, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '3') ** Obsolete normative reference: RFC 2141 (ref. '4') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (ref. '5') (Obsoleted by RFC 8141) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Tessman 2 Expires October 14, 2005 Zelestra 3 April 2005 5 URN Namespace for Federated Content 6 draft-dtessman-urn-namespace-federated-content-01.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on October 14, 2005. 32 Copyright Notice 34 Copyright (C) The Internet Society (2005). All Rights Reserved. 36 Abstract 38 This document describes a URN (Uniform Resource Name) namespace for 39 identifying content resources within federated content collections. 40 A federated content collection often does not have a strong 41 centralized authority but relies upon shared naming, metadata, and 42 access conventions to provide interoperability among its members. 44 1. Introduction 46 Federated content collections are often loose constructs of both 47 small and large content providers, with an active community, but 48 without significant central authority. Members are bound together by 49 shared purpose, and interoperate through shared naming, metadata, 50 and access conventions. Federations may also consist of other 51 federations, creating complex associations and dependencies. 53 A content provider may join or leave a federation at any time and 54 may be part of more than one federation at the same time. Content 55 providers may also cease as organizations altogether, freeing their 56 domain names for use by others. In addition, content identifiers 57 are spread throughout the members of a federation. These identifiers 58 are stored on various media, sometimes for long durations before 59 being used. Therefore, although they work well in situations without 60 a strong content naming authority, URLs are insufficient as content 61 identifiers within a federation because they cannot be uniquely and 62 permanently tied to a specific content resource. 64 This URN namespace provides a mechanism whereby a central naming 65 authority is not required. Providers maintain naming authority over 66 their own content within guidelines that guarantee URNs to be 67 unique and permanent. 69 A simple identifier resolution convention is also recommended to 70 provide a consistent URN resolver interface across all providers. 72 This namespace specification is for a formal namespace. 74 2. Terminology 76 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 77 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 78 and "OPTIONAL" are to be interpreted as described in RFC 2119. 80 3. Specification Template 82 Namespace ID: 84 "fdc" requested. 86 Registration Information: 88 Registration Version Number: 1 89 Registration Date: 2005-01-22 91 Declared registrant of the namespace: 93 Name: Zelestra 94 Address: 2314 Henrietta Avenue 95 La Crescenta, CA 91214-3007 97 Contact: Dave Tessman 98 E-mail: dtessman@zelestra.com 100 Declaration of syntactic structure: 102 The NSS has the following ABNF [2] specification: 104 NSS = ProviderId ":" DateId ":" ResourceId 105 ProviderId = 1*(label ".") toplabel 106 DateId = 1*3(DIGIT) / (CCYY [MM [DD]]) 107 ResourceId = 1*(alphanum / other / ("%" hex hex)) 108 label = alphanum / alphanum *[ alphanum / "-" ] alphanum 109 toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum 110 CCYY = 4(DIGIT) 111 MM = ("0" %x31-39) / ("1" ("0" "1" "2")) 112 DD = ("0" %x31-39) / (( "1" / "2") DIGIT) / "30" / "31" 113 alphanum = ALPHA / DIGIT 114 hex = DIGIT | %x41-46 | %x61-66 115 other = "(" / ")" / "+" / "," / "-" / "." / ":" / "=" / 116 "@" / ";" / "$" / "_" / "!" / "*" / "'" 118 ProviderId is the content provider's identifier. ProviderId MUST 119 be an Internet domain name, and MUST be owned by the organization 120 creating the resource and allocating the URN to the resource, at 121 the date identified by the DateId. 123 DateId is a date in ISO 8601 Basic Format (CCYY[MM[DD]]), and MUST 124 correspond to a date at which the organization allocating the URN 125 owned the domain name specified in the ProviderId. Default value 126 for MM and DD is "01". DateIds of 1 to 3 digits are reserved. 128 ResourceId MUST be unique among all ResourceIds emanating from 129 the same provider and having the same DateId. 131 Relevant ancillary documentation: 133 None. 135 Identifier uniqueness considerations: 137 The combination of ProviderId and DateId serves to uniquely 138 identify the organization that is allocating the URN. That 139 organization is responsible for ensuring the uniqueness of the 140 ResourceId. 142 Identifier persistence considerations: 144 A URN of this namespace may only be allocated by an organization 145 that owns an Internet domain name. The URN identifies a date on 146 which the organization owned that domain name. The combination of 147 domain name and date will serve to uniquely identify that 148 organization for all time. 150 Process of identifier assignment: 152 The organization identified by the ProviderId/DateId combination 153 is responsible for allocating a ResourceId that is unique among 154 all those that it allocates with that DateId. 156 Process of identifier resolution: 158 Content providers are responsible for the provision of a URN 159 resolution service, if any, for URNs they have assigned with a 160 valid ProviderId/DateId combination. 162 Content providers SHOULD support URN resolution by using the HTTP 163 protocol convention described in RFC 2169 [3]. The ProviderId 164 SHOULD be used as the HTTP server location. 166 Rules for Lexical Equivalence: 168 In addition to the rules defined in RFC 2141 [4], normalize the 169 case of the ProviderId before comparison. 171 Conformance with URN Syntax: 173 There are no additional characters reserved. 175 Validation mechanism: 177 None additional to resolution specified. 179 Scope: 181 Global 183 4. Examples 185 The following examples are representative of URNs in this namespace, 186 but may not refer to actual resources. 188 urn:fdc:spacegear.org:2002:A572007 189 urn:fdc:zelestra.com:20010527:img089322-038 191 5. Security Considerations 193 There are no additional security considerations other than those 194 normally associated with the use and resolution of URNs in general. 196 6. Namespace Considerations 198 Distribution of naming authority, identifier flexibility, and a 199 recommended URN resolution mechanism make this namespace a unique and 200 valuable tool to meet the URN requirements of small content providers 201 and federated content collections. 203 7. Community Considerations 205 By establishing a simple, flexible, and efficient means for smaller 206 content providers to uniquely identify and publish their content, 207 this namespace reduces the effort required for these providers to 208 participate in federated collections. A consistent identifier format 209 and resolution mechanism also increases the ability of federations to 210 accept content references from smaller providers and to aggregate 211 themselves into federations of federations. Increased participation 212 and aggregation results in a larger selection of distinctive content 213 that is more accessible to the community. 215 To make use of this namespace, a content provider should further 216 decompose the ResourceId portion of the namespace syntactic structure 217 to meet their internal content identification needs and establish an 218 internal governance mechanism to ensure that all identifiers created 219 follow the requirements of this namespace. It is also recommended 220 that the identifier resolution mechanism described in RFC 2619 [3] 221 be provisioned within an HTTP server designated by the ProviderId 222 portion of the namespace syntactic structure. 224 8. IANA Considerations 226 This document includes a URN NID registration is to be entered into 227 the IANA registry of URN NIDs. 229 References 231 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 232 Levels", RFC 2119, March 1997. 234 [2] D. Crocker, and P. Overell, "Augmented BNF for Syntax 235 Specifications: ABNF", RFC 2234, November 1997. 237 [3] R. Daniel, "A Trivial Convention for using HTTP in URN 238 Resolution", RFC 2169, June 1997 240 [4] R. Moats, "URN Syntax", RFC 2141, May 1997. 242 [5] L. Daigle, D.W. van Gulik, R. Iannella, and P. Faltstrom, 243 "URN Namespace Definition Mechanisms", RFC 3406, October 2002. 245 Author's Address 247 Dave Tessman 248 Zelestra 249 2314 Henrietta Avenue 250 La Crescenta, California 91214-3007 251 Phone: +1 818 957 2582 252 Email: dtessman@zelestra.com 254 Copyright Statement 256 Copyright (C) The Internet Society (2005). This document is subject 257 to the rights, licenses and restrictions contained in BCP 78, and 258 except as set forth therein, the authors retain all their rights. 260 This document and the information contained herein are provided on an 261 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 262 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 263 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 264 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 265 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 266 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.