idnits 2.17.1 draft-hazelton-mace-urn-namespace-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 157 has weird spacing: '...ries of immed...' -- 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 (November 19, 2002) is 7830 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) -- Looks like a reference, but probably isn't: 'XMLORG' on line 247 ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 3120 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 3121 (ref. '4') ** Obsolete normative reference: RFC 2611 (ref. '5') (Obsoleted by RFC 3406) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Morgan 3 Internet-Draft Univ. of Washington 4 Expires: May 20, 2003 K. Hazelton 5 Univ. of Wisconsin-Madison 6 November 19, 2002 8 A URN Namespace for MACE 9 draft-hazelton-mace-urn-namespace-02 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 20, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document describes a proposed URN (Uniform Resource Name) 41 namespace that would be managed by the Internet2 Middleware 42 Architecture Committee for Education (MACE) for naming persistent 43 resources defined by MACE, its working groups and other designated 44 subordinates. 46 1. Introduction and community considerations 48 The Internet2 Middleware Architecture Committee for Education (MACE) 49 produces many kinds of documents: specifications, working drafts, 50 object classes, schemas, stylesheets, etc. It also defines directory 51 attributes and controlled vocabularies for the values of some of 52 those attributes. 54 MACE wishes to provide global, distributed, persistent, location- 55 independent names for these resources. The Uniform Resource Name 56 (URN) variant of URIs meets these requirements. 58 MACE working groups and other MACE-affiliated groups would benefit 59 from the MACE URN proposal by having an easy, efficient way to assign 60 globally unique, persistent identifiers to resources that they 61 create. The nature of MACE work is that it is carried out to serve 62 the needs of one or more communities of interest. A namespace 63 managed so as to facilitate the creation, registration and resolution 64 of unique, persistent identifiers would be of great value for MACE, 65 its affiliates and the higher education community generally. 67 The proposed URN namespace specification is for a formal namespace. 69 2. Specification Template 71 Namespace ID: 73 "mace" requested. 75 Registration Information: 77 Registration Version Number 1 79 Registration Date: 2002-xx-yy 81 Registrant of the namespace: 83 Middleware Architecture Committee for Education (MACE) 84 ATTN: Lisa Hogeboom 85 Internet2 86 3025 Boardwalk Suite 200 87 Ann Arbor, MI 48108 89 Phone: +1 734 913 4250 91 Contact: Keith Hazelton 93 Affiliation: Univ. of Wisconsin-Madison 94 1210 W. Dayton St. 95 Madison, WI 53706 96 Phone: +1 608 262 0771 98 hazelton@doit.wisc.edu 100 Syntactic structure: 102 The Namespace Specific Strings (NSS) of all URNs assigned by 103 MACE will conform to the syntax defined in section 2.2 of 104 RFC2141, "URN Syntax." [1] In addition, all MACE URN NSSs will 105 consist of a left-to-right series of tokens delimited by 106 colons. The left-to-right sequence of colon-delimited tokens 107 corresponds to descending nodes in a tree. To the right of the 108 lowest naming authority node there may be zero, one or more 109 levels of hierarchical naming nodes terminating in a rightmost 110 leaf node. See the section entitled "Identifier assignment" 111 below for more on the semantics of NSSs. This syntax 112 convention is captured in the following normative ABNF rules 113 for MACE NSSs (see RFC2234): [2] 115 MACE-NSS = 1*(subStChar) 0*(":" 1*(subStChar)) 117 subStChar = trans / "%" HEXDIG HEXDIG 119 trans = ALPHA / DIGIT / other / reserved 121 other = "(" / ")" / "+" / "," / "-" / "." / 123 "=" / "@" / ";" / "$" / 125 "_" / "!" / "*" / "'" 127 reserved = "%" / "/" / "?" / "#" 129 The exclusion of the colon from the list of "other" characters 130 means that the colon can only occur as a delimiter between 131 string tokens. Note that this ABNF rule set guarantees that 132 any valid MACE NSS is also a valid RFC2141 NSS. 134 Relevant ancillary documentation: 136 None. 138 Identifier uniqueness: 140 It is the responsibility of MACE directors to guarantee 141 uniqueness of the names of immediately subordinate naming 142 authorities. Each lower-level naming authority in turn 143 inherits the responsibility of guaranteeing uniqueness of names 144 in their branch of the naming tree. 146 Identifier persistence: 148 MACE directors bear ultimate responsibility for maintaining the 149 usability of MACE URNs over time. This responsibility may be 150 delegated to subordinate naming authorities per the discussion 151 in the section below on identifier assignment. That section 152 provides a mechanism for the delegation to be revoked in case a 153 subordinate naming authority ceases to function. 155 Identifier assignment: 157 MACE directors will create an initial series of immediately 158 subordinate naming authorities, and will define a process for 159 adding to that list of authorities. Each top-level working 160 group of MACE will be invited to designate a naming authority 161 and to suggest one or more candidate names for that authority. 162 The MACE-Shibboleth group, for example, might propose creating 163 a naming authority under "urn:mace:shib," "urn:mace:shibboleth" 164 or some other name. 166 Institutions and communities affiliated with MACE may request, 167 through their designated MACE liaison, that they be granted 168 MACE-subordinate naming authority status. They may propose 169 candidate names for that authority. One way for such entities 170 to guarantee uniqueness of their proposed name is to base it on 171 a DNS name. That is, if Georgetown University wished to be 172 designated a subordinate naming authority under MACE, the 173 institutional MACE liaison could propose to MACE directors that 174 they be delegated control over names beginning with 175 "urn:mace:georgetown.edu." Institutions seeking affiliation 176 with MACE should send email to mace-submit@internet2.edu, 177 nominating an institutional liaison and providing contact 178 information for that person. 180 On at least an annual basis, MACE directors will contact the 181 liaisons or directors of each immediately subordinate naming 182 authority. If there is no response, or if the respondent 183 indicates that they wish to relinquish naming authority, the 184 authority over that branch of the tree reverts to MACE. This 185 process will be enforced recursively by each naming authority 186 on its subordinates. This process guarantees that 187 responsibility for each branch of the tree will lapse for less 188 than one year at worst before being reclaimed by a superior 189 authority. 191 Lexical equivalence of two MACE namespace specific strings 192 (NSSs) is defined below as an exact, case-sensitive string 193 match. MACE will assign names of immediately subordinate 194 naming authorities in lower case only. This forestalls the 195 registration of two MACE-subordinate naming authorities whose 196 names differ only in case. 198 Identifier resolution: 200 MACE directors will maintain an index of all MACE and MACE 201 workgroup assigned URNs on its web site, http:// 202 middleware.internet2.edu/MACE. That index will map URNs to 203 resource identifiers, usually URLs. MACE-affiliated naming 204 authorities will specify how to resolve the URNs they assign if 205 they are resolvable. 207 Lexical equivalence: 209 Lexical equivalence of two MACE namespace specific strings 210 (NSSs) is defined as an exact, case-sensitive string match. 212 Conformance with URN syntax: 214 All MACE NSSs fully conform to RFC2141 syntax rules for NSSs. 216 Validation mechanism: 218 As specified in the "Identifier resolution" section above, MACE 219 directors will maintain an index of all MACE and MACE workgroup 220 assigned URNs on its web site, http://middleware.internet2.edu/ 221 MACE. Presence in that index implies that a given URN is 222 valid. MACE-affiliated naming authorities will specify how to 223 validate the URNs they assign. 225 Scope: 227 Global. 229 3. Security Considerations 231 There are no additional security considerations beyond those normally 232 associated with the use and resolution of URNs in general. 234 4. Namespace Considerations 236 Registration of an NID specific to MACE is reasonable given the 237 following considerations: 239 1. MACE would like to assign URNs to some very fine-grained objects 240 (such as specific controlled vocabulary values of an attribute in 241 MACE-defined LDAP object classes). This does not seem to be the 242 primary intended use of the XMLORG namespace (RFC3120) [3], let alone 243 the more tightly controlled OASIS namespace (RFC3121) [4]. 245 2. MACE seeks naming autonomy. We understand that the XMLORG 246 registrants left the door open to subordinate naming authorities, 247 "OASIS may assign portions of its [XMLORG] namespace for assignment 248 by other parties" (RFC3120), but there is no specified process for 249 such assignment. That would in any case mean having a fixed XMLORG- 250 assigned prefix on every single object to which we assign a URN. 251 MACE has a number of active work groups that may well generate a 252 growing number of subordinate naming authorities. Moreover, MACE is 253 not a member of OASIS, so becoming a subordinate naming authority 254 under the OASIS URN space is currently not an option. 256 3. MACE will want to assign URNs to non-XML objects as well. That 257 is another reason that XMLORG may not be an appropriate higher-level 258 naming authority for MACE. 260 Some MACE-developed schema and namespaces may be good candidates for 261 inclusion in the XMLORG registry. The fact that such an object might 262 already have a MACE-assigned URN shouldn't be a hindrance. Work in 263 progress to update RFC2611 [5] includes an explicit statement that 264 two or more URNs may point to the same resource. A resource with a 265 MACE-assigned namespace-specific-string would, of course, be given an 266 XMLORG namespace-specific-string at the time it enters the XMLORG 267 registry. 269 5. IANA Considerations 271 This document is intended as a formal request to IANA for the 272 registration of a "MACE" NID within the IANA registry of URN NIDs. 274 References 276 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 278 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 279 Specifications: ABNF", RFC 2234, November 1997. 281 [3] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120, 282 June 2001. 284 [4] Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121, 285 June 2001. 287 [5] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN 288 Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999. 290 Authors' Addresses 292 RL "Bob" Morgan 293 4545 15th Ave. NE 294 Seattle, WA 98105 295 U.S.A. 297 EMail: rlmorgan@washington.edu 299 Keith D. Hazelton 300 University of Wisconsin-Madison 301 1210 W. Dayton St. 302 Madison, WI 53706 303 U.S.A. 305 EMail: hazelton@doit.wisc.edu 307 Full Copyright Statement 309 Copyright (C) The Internet Society (2002). All Rights Reserved. 311 This document and translations of it may be copied and furnished to 312 others, and derivative works that comment on or otherwise explain it 313 or assist in its implementation may be prepared, copied, published 314 and distributed, in whole or in part, without restriction of any 315 kind, provided that the above copyright notice and this paragraph are 316 included on all such copies and derivative works. However, this 317 document itself may not be modified in any way, such as by removing 318 the copyright notice or references to the Internet Society or other 319 Internet organizations, except as needed for the purpose of 320 developing Internet standards in which case the procedures for 321 copyrights defined in the Internet Standards process must be 322 followed, or as required to translate it into languages other than 323 English. 325 The limited permissions granted above are perpetual and will not be 326 revoked by the Internet Society or its successors or assigns. 328 This document and the information contained herein is provided on an 329 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 330 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 331 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 332 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 333 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 Acknowledgement 337 Funding for the RFC Editor function is currently provided by the 338 Internet Society.