idnits 2.17.1 draft-dtessman-urn-namespace-federated-content-03.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 272. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 264), 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 : ---------------------------------------------------------------------------- No issues found here. 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 6948 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: '5' is defined on line 248, 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 informational reference (is this intentional?): RFC 3406 (ref. '5') (Obsoleted by RFC 8141) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Tessman 2 Expires October 27, 2005 Zelestra 3 April 2005 5 URN Namespace for Federated Content 6 draft-dtessman-urn-namespace-federated-content-03.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 27, 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 [1]. 80 3. Specification Template 82 Namespace ID: 84 "fdc" requested. 86 Registration Information: 88 Registration Version Number: 1 89 Registration Date: 2005-04-25 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 = (CCYY [MM [DD]]) / 1*3(DIGIT) 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" %x30-32) 112 DD = ("0" %x31-39) / (%x31-32 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 specific day on which the organization allocating 125 the URN owned the domain name specified in the ProviderId. If not 126 included, the default value for MM and DD is "01". DateIds of 1 127 to 3 digits are reserved. 129 ResourceId MUST be unique among all ResourceIds emanating from 130 the same provider and having the same DateId. 132 Relevant ancillary documentation: 134 None. 136 Identifier uniqueness considerations: 138 The combination of ProviderId and DateId serves to uniquely 139 identify the organization that is allocating the URN. That 140 organization is responsible for ensuring the uniqueness of the 141 ResourceId. 143 Identifier persistence considerations: 145 A URN of this namespace may only be allocated by an organization 146 that owns an Internet domain name. The URN identifies a date on 147 which the organization owned that domain name. The combination of 148 domain name and date will serve to uniquely identify that 149 organization for all time. 151 Process of identifier assignment: 153 The organization identified by the ProviderId/DateId combination 154 is responsible for allocating a ResourceId that is unique among 155 all those that it allocates with that DateId. 157 Process of identifier resolution: 159 Content providers are responsible for the provision of a URN 160 resolution service, if any, for URNs they have assigned with a 161 valid ProviderId/DateId combination. 163 Content providers SHOULD support URN resolution by using the HTTP 164 protocol convention described in RFC 2169 [3]. The ProviderId 165 SHOULD be used as the HTTP server location. 167 Rules for Lexical Equivalence: 169 In addition to the rules defined in RFC 2141 [4], normalize the 170 case of the ProviderId to lower case before comparison. 172 Conformance with URN Syntax: 174 There are no additional characters reserved. 176 Validation mechanism: 178 None additional to resolution specified. 180 Scope: 182 Global 184 4. Examples 186 The following examples are representative of URNs in this namespace, 187 but may not refer to actual resources. 189 urn:fdc:example.com:2002:A572007 190 urn:fdc:example.net:200406:ivr:51089 191 urn:fdc:example.org:20010527:img089322-038 193 5. Security Considerations 195 There are no additional security considerations other than those 196 normally associated with the use and resolution of URNs in general. 198 6. Namespace Considerations 200 Distribution of naming authority, identifier flexibility, and a 201 recommended URN resolution mechanism make this namespace a unique and 202 valuable tool to meet the URN requirements of small content providers 203 and federated content collections. 205 7. Community Considerations 207 By establishing a simple, flexible, and efficient means for smaller 208 content providers to uniquely identify and publish their content, 209 this namespace reduces the effort required for these providers to 210 participate in federated collections. A consistent identifier format 211 and resolution mechanism also increases the ability of federations to 212 accept content references from smaller providers and to aggregate 213 themselves into federations of federations. Increased participation 214 and aggregation results in a larger selection of distinctive content 215 that is more accessible to the community. 217 To make use of this namespace, a content provider should further 218 decompose the ResourceId portion of the namespace syntactic structure 219 to meet their internal content identification needs and establish an 220 internal governance mechanism to ensure that all identifiers created 221 follow the requirements of this namespace. It is also recommended 222 that the identifier resolution mechanism described in RFC 2619 [3] 223 be provisioned within an HTTP server designated by the ProviderId 224 portion of the namespace syntactic structure. 226 8. IANA Considerations 228 This document includes a URN NID registration that is to be entered 229 into the IANA registry of URN NIDs. 231 References 233 Normative References 235 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 236 Levels", RFC 2119, March 1997. 238 [2] D. Crocker, and P. Overell, "Augmented BNF for Syntax 239 Specifications: ABNF", RFC 2234, November 1997. 241 [3] R. Daniel, "A Trivial Convention for using HTTP in URN 242 Resolution", RFC 2169, June 1997 244 [4] R. Moats, "URN Syntax", RFC 2141, May 1997. 246 Informative References 248 [5] L. Daigle, D.W. van Gulik, R. Iannella, and P. Faltstrom, 249 "URN Namespace Definition Mechanisms", RFC 3406, October 2002. 251 Author's Address 253 Dave Tessman 254 Zelestra 255 2314 Henrietta Avenue 256 La Crescenta, California 91214-3007 257 Phone: +1 818 957 2582 258 Email: dtessman@zelestra.com 260 Copyright Statement 262 Copyright (C) The Internet Society (2005). This document is subject 263 to the rights, licenses and restrictions contained in BCP 78, and 264 except as set forth therein, the authors retain all their rights. 266 This document and the information contained herein are provided on an 267 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 268 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 269 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 270 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 271 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 272 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.