idnits 2.17.1 draft-vandesompel-info-uri-04.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 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 778. ** 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. 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In this document the keywords "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", "MAY NOT", and "RECOMMENDED" are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: ; Note that "info" URIs containing dot-segments (i.e. segments ; whose full content consists of "." or "..") MAY NOT be suitable ; for use with applications that perform dot-segment normalization == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Note that "info" URIs containing dot-segments (i.e. segments whose full content consists of "." or "..") MAY NOT be suitable for use with applications that perform dot-segment normalization. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Existing URI schemes are not suitable for employment as the "info" URI scheme admits of no global dereference mechanism. While examples of resource identifiers minted under other URI schemes MAY not always be dereferenceable, nevertheless there is always a common expectation that such URIs can be dereferenced by various resolution mechanisms, whether they be location-dependent or location-independent resource identifiers. The "info" URI scheme applies to a class of resource identifiers whose Namespace Authorities MAY or MAY NOT choose to disclose service mechanisms. Nevertheless, Namespace Authorities are encouraged to disclose in the "info" registration record references to any such service mechanisms in order to provide a greater utility to network applications. -- 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 (August 12, 2005) is 6831 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) ** Downref: Normative reference to an Informational RFC: RFC 1737 ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2718 (Obsoleted by RFC 4395) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Van de Sompel 3 Internet-Draft LANL 4 Expires: February 13, 2006 T. Hammond 5 NPG 6 E. Neylon 7 Manifest Solutions 8 S. Weibel 9 OCLC 10 August 12, 2005 12 The "info" URI Scheme for Information Assets with Identifiers in Public 13 Namespaces 14 draft-vandesompel-info-uri-04 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on February 13, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document defines the "info" Uniform Resource Identifier (URI) 48 scheme for information assets with identifiers in public namespaces. 50 Namespaces participating in the "info" URI scheme are regulated by an 51 "info" Registry mechanism. 53 Editorial Note 55 Any feedback on this draft should be directed to 56 . 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2 Information Assets . . . . . . . . . . . . . . . . . . . . 3 63 2. Application of the "info" URI Scheme . . . . . . . . . . . . 5 64 3. The "info" Registry . . . . . . . . . . . . . . . . . . . . 6 65 3.1 Management Characteristics of the "info" Registry . . . . 6 66 3.2 Functional Characteristics of the "info" Registry . . . . 6 67 3.3 Maintenance of the "info" Registry . . . . . . . . . . . . 7 68 4. The "info" URI Scheme . . . . . . . . . . . . . . . . . . . 8 69 4.1 Definition of "info" URI Syntax . . . . . . . . . . . . . 8 70 4.2 Allowed Characters Under the "info" URI Scheme . . . . . . 10 71 4.3 Examples of "info" URIs . . . . . . . . . . . . . . . . . 10 72 5. Normalization and Comparison of "info" URIs . . . . . . . . 13 73 6. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 6.1 Why Create a New URI Scheme for Identifiers from Public 75 Namespaces? . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.2 Why Not Use an existing URI Scheme for Identifiers from 77 Public Namespaces? . . . . . . . . . . . . . . . . . . . . 15 78 6.3 Why Not Create a New URN Namespace ID for Identifiers 79 from Public Namespaces? . . . . . . . . . . . . . . . . . 15 80 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 10.1 Normative References . . . . . . . . . . . . . . . . . . 20 85 10.2 Informative References . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 87 Intellectual Property and Copyright Statements . . . . . . . 22 89 1. Introduction 91 This document defines the "info" Uniform Resource Identifier (URI) 92 scheme for information assets that have identifiers in public 93 namespaces but are not part of the URI allocation. By information 94 asset this document intends any information construct that has 95 identity within a public namespace. 97 1.1 Terminology 99 In this document the keywords "MUST", "MUST NOT", "SHALL", "SHALL 100 NOT", "SHOULD", "SHOULD NOT", "MAY", "MAY NOT", and "RECOMMENDED" are 101 to be interpreted as described in RFC 2119 [RFC2119] and indicate 102 requirement levels for compliant implementations. 104 1.2 Information Assets 106 There exist many information assets with identifiers in public 107 namespaces that are not referenceable by URI schemes. Examples of 108 such namespaces include Dewey Decimal Classifications [DEWEY], 109 Library of Congress Control Numbers [LCCN], NISO Serial Item and 110 Contribution Identifiers [SICI], NASA Astrophysics Data System 111 Bibcodes [BIBCODE], and National Library of Medicine PubMed 112 identifiers [PMID]. Other candidate namespaces include Publisher 113 Item Identifiers [PII], Online Computer Library Center OCLC Numbers 114 [OCLCNUM], and NISO OpenURL Framework identifiers [OFI]. 116 The "info" URI scheme facilitates the referencing of information 117 assets that have identifiers in such public namespaces by means of 118 URIs. When referencing an information asset by means of its "info" 119 URI, the asset SHALL be considered a "resource" as defined in RFC 120 3986 [RFC3986] and SHALL enjoy the same common syntactic, semantic 121 and shared language benefits that the URI presentation confers. As 122 such, the "info" URI scheme enables public namespaces that are not 123 part of the URI allocation to be represented within the allocation. 124 The "info" URI scheme thus provides a bridging mechanism to allow 125 public namespaces to become part of the URI allocation. 127 Namespaces declared under the "info" URI scheme are regulated by an 128 "info" Registry mechanism. The "info" Registry allows a public 129 namespace that is not part of the URI allocation to be declared in a 130 registration process by the organization that manages it (the 131 Namespace Authority). The "info" Registry supports the declaration 132 of public namespaces that are not part of the URI allocation in a 133 manner that facilitates the construction of URIs for information 134 assets without imposing the burdens of independent URI registration 135 and maintenance of resource representations on the Namespace 136 Authority. Information assets identified within a registered 137 namespace SHALL be added or deleted according to the business 138 processes of the Namespace Authority, and yet MAY be referenced 139 within network applications via the "info" URI in an open, 140 standardized way without additional action on the part of the 141 Namespace Authority. 143 The "info" URI scheme exists primarily for identification purposes. 144 Implementations MUST NOT assume that an "info" URI can be 145 dereferenced to a representation of the resource identified by the 146 URI although Namespace Authorities MAY disclose in the registration 147 record references to service mechanisms pertaining to identifiers 148 from the registered namespace. Applications of the "info" URI scheme 149 are restricted to the identification of information assets and the 150 declaration of normalization rules for comparing identifiers of such 151 information assets regardless of whether any services relating to 152 such information assets are accessible via the Internet. References 153 to such services MAY be disclosed within an "info" registration 154 record but these services SHALL NOT be regarded as authoritative. 155 The "info" URI scheme does not support global resolution methods. 157 2. Application of the "info" URI Scheme 159 Public namespaces that are used for the identification of information 160 assets, and that are not part of the URI allocation, MAY be 161 registered as namespaces within the "info" Registry. Namespace 162 Authorities MAY register these namespaces in the "info" Registry, 163 thereby making these namespaces available to applications that need 164 to reference information assets by means of a URI. Registrations of 165 public namespaces that are not part of the URI allocation by parties 166 other than the Namespace Authority SHALL NOT be permitted, thereby 167 insuring against hostile usurpation or inappropriate usage of 168 registered service marks or the public namespaces of others. 170 Registration of a public namespace under the "info" Registry implies 171 no particular functionalities of the identifiers from the registered 172 namespace other than the identification of information assets. No 173 resolution mechanisms can be assumed for the "info" URI scheme, 174 though for any particular namespace there MAY exist mechanisms for 175 resolving identifiers to network services. The definition of such 176 services falls outside the scope of the "info" URI scheme. 177 Registration does not define namespace-specific semantics for 178 identifiers within a registered namespace, though allowable character 179 sets and normalization rules are specified in Sections 4 and 5 so as 180 to ensure that the URIs created using such identifiers are compliant 181 with applications that use URIs. 183 The registration of a public namespace in the "info" Registry SHALL 184 NOT preclude further development of services associated with that 185 namespace which MAY qualify the namespace for additional publication 186 elsewhere within the URI allocation. 188 3. The "info" Registry 190 The "info" Registry provides a mechanism for the registration of 191 public namespaces that are used for the identification of information 192 assets, and that are not part of the URI allocation. 194 NISO [NISO], the National Information Standards Organization, will 195 act as the Maintenance Agency for the "info" Registry, and will 196 delegate the day-to-day operation of the "info" Registry to a 197 Registry Operator. As the Maintenance Agency, NISO will ensure that 198 the Registry Operator operates the "info" Registry in accordance with 199 a publicly articulated policy document established under NISO 200 governance and made available on the "info" website 201 . The "info" Registry policy defines a review 202 process for candidate namespaces and provides measures of quality 203 control and suitability for entry of namespaces. 205 3.1 Management Characteristics of the "info" Registry 207 The "info" Registry will be managed according to policies established 208 under the auspices of NISO. All such policies, as well as the 209 namespace declarations in the "info" Registry, will be public. 211 3.2 Functional Characteristics of the "info" Registry 213 The "info" Registry will be publicly accessible and will support 214 discovery (by both humans and machines) of: 216 o string literals identifying the namespaces for which the Registry 217 provides a guarantee of uniqueness and persistence 219 o names and contact information of Namespace Authorities 221 o syntax requirements for identifiers maintained in such namespaces 223 o normalization methodologies for identifiers maintained in such 224 namespaces 226 o network references to a description of service mechanisms (if any) 227 for identifiers maintained in such namespaces 229 o ancillary documentation 231 Registry entries refer to the corresponding "namespace" and 232 "identifier" components which are defined in the ABNF given in 233 Section 4.1 of this document. 235 3.3 Maintenance of the "info" Registry 237 The public namespaces that MAY be registered in the "info" Registry 238 will be those of interest to the communities served by NISO and 239 therefore NISO is committed to act as Maintenance Authority for the 240 "info" Registry, and to assign a Registry Operator to operate it. 242 NISO, a non-profit association accredited by the American National 243 Standards Institute (ANSI), identifies, develops, maintains, and 244 publishes technical standards to manage information in the digital 245 environment. NISO standards apply technologies to the full range of 246 information-related needs, including retrieval, re-purposing, 247 storage, metadata, and preservation. 249 Founded in 1939, incorporated as a not-for-profit education 250 association in 1983, and assuming its current name the following 251 year, NISO draws its support from the communities it serves. The 252 leaders of over 70 organizations in the fields of publishing, 253 libraries, IT and media serve as its voting members. Hundreds of 254 experts and practitioners serve on NISO committees and as officers of 255 the association. 257 NISO has been designated by ANSI to represent US interests to the 258 International Organization for Standardization's (ISO) Technical 259 Committee 46 on Information and Documentation. 261 The NISO headquarters office is located at: 4733 Bethesda Ave., 262 Bethesda, MD 20814, USA. (For further information, see the NISO 263 website .) 265 4. The "info" URI Scheme 267 4.1 Definition of "info" URI Syntax 269 The "info" URI syntax presented in this document is conformant with 270 the generic URI syntax defined in RFC 3986 [RFC3986]. This 271 specification uses the Augmented Backus-Naur Form (ABNF) notation of 272 RFC 2234 [RFC2234] to define the URI. The following core ABNF 273 productions are used by this specification as defined by Section 6.1 274 of RFC 2234: ALPHA, DIGIT, HEXDIG. 276 The "info" URI syntax is presented in two parts. Part A contains 277 productions specific to the "info" URI scheme, while Part B contains 278 generic productions from the RFC 3986 [RFC3986] which are repeated 279 here both for completeness and for reference. The following set of 280 productions (Part A) are specific to the "info" URI scheme: 282 ; Part A: 283 ; productions specific to the "info" URI scheme 285 info-URI = info-scheme ":" info-identifier [ "#" fragment ] 287 info-scheme = "info" 289 info-identifier = namespace "/" identifier 291 namespace = scheme 293 identifier = *( pchar / "/" ) 295 ; Note that "info" URIs containing dot-segments (i.e. segments 296 ; whose full content consists of "." or "..") MAY NOT be suitable 297 ; for use with applications that perform dot-segment normalization 299 This next set of productions (Part B) are generic productions 300 reproduced from the RFC 3986 [RFC3986]: 302 ; Part B: 303 ; generic productions from RFC 3986 304 [RFC3986] 306 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 308 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 310 fragment = *( pchar / "/" / "?" ) 312 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 314 pct-encoded = "%" HEXDIG HEXDIG 316 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 317 / "*" / "+" / "," / ";" / "=" 319 An "info" URI has an "info-identifier" as its scheme-specific part 320 and MAY take an optional "fragment" component. An "info-identifier" 321 is constructed by appending an "identifier" component to a 322 "namespace" component separated by a slash "/" character. The "info" 323 URI scheme is supportive of hierarchical processing as indicated by 324 the presence of the slash "/" character although the slash "/" 325 character SHOULD NOT be interpreted as a strict hierarchy delimiter. 327 Values for the "namespace" component of the "info" URI are name 328 tokens composed of URI scheme characters only (cf. the "scheme" 329 production). They identify the public namespace in which the 330 (unescaped) value for the "identifier" component originates, and are 331 registered in the "info" Registry, which guarantees their uniqueness 332 and persistence. Although the "namespace" component is case- 333 insensitive, the canonical form is lowercase and documents that 334 specify values for the "namespace" component SHOULD do so using 335 lowercase letters. An implementation SHOULD accept uppercase letters 336 as equivalent to lowercase in "namespace" names, for the sake of 337 robustness, but SHOULD only generate lowercase "namespace" names, for 338 consistency. 340 Values for the "identifier" component of the "info" URI MAY be viewed 341 as being hierarchical strings composed of path segments built from 342 path segment characters (cf. the "pchar" production), the segments 343 being separated by slash "/" characters, although any semantic 344 interpretation of the "/" character as a hierarchy delimiter MUST NOT 345 be assumed. In their originating public namespace, the (unescaped) 346 values for the "identifier" component identify information assets. 347 The values for the "identifier" component MUST be %-escaped as 348 required by this syntax. The "identifier" component SHOULD be 349 treated as case-sensitive, although the "info" Registry MAY record 350 the case-sensitivity of identifiers from particular registered public 351 namespaces. The "info" Registry MAY also disclose additional 352 normalization rules regarding the treatment of punctuation characters 353 and the like. 355 Values for the "fragment" component of the "info" URI are strings 356 composed of path segment characters (cf. the "pchar" production) plus 357 the slash "/" character and the question-mark "?" character. No 358 semantic role is assigned to the the slash "/" character and the 359 question-mark "?" character within the "fragment" component. The 360 (unescaped) values for the "fragment" component identify secondary 361 information assets with respect to the primary information asset 362 which is referenced by the "info-identifier". The values for the 363 "fragment" component MUST be %-escaped as required by this syntax. 364 The "fragment" component MUST be treated as being case-sensitive. 366 4.2 Allowed Characters Under the "info" URI Scheme 368 The "info" URI syntax uses the same set of allowed US-ASCII 369 characters as specified in RFC 3986 [RFC3986] for a generic URI. An 370 "info" URI string SHOULD be represented as a UNICODE [UNICODE] string 371 and be encoded in UTF-8 [RFC2279] form. Reserved characters as well 372 as excluded US-ASCII characters and non-US-ASCII characters MUST be 373 %-escaped before forming the URI. Details of the %-escape encoding 374 can be found in RFC 3986 [RFC3986], Section 2.4. 376 4.3 Examples of "info" URIs 378 Some examples of syntactically valid "info" URIs are given below: 380 a) info:ddc/22/eng//004.678 382 where "ddc" is the "namespace" component for a Dewey Decimal 383 Classification [DEWEY] namespace and "22/eng//004.678" is the 384 "identifier" component for an identifier of an information asset 385 within that namespace. 387 The information asset identified by the identifier "22/eng//004.678" 388 in the namespace for (22nd Ed.) English-language Dewey Decimal 389 Classifications is the classification 391 "Internet" 393 b) info:lccn/2002022641 395 where "lccn" is the "namespace" component for a Library of Congress 396 Control Number [LCCN] namespace and "2002022641" is the "identifier" 397 component for an identifier of an information asset within that 398 namespace. 400 The information asset identified by the identifier "2002022641" in 401 the namespace for Library of Congress Control Numbers is the metadata 402 record 404 "Newcomer, Eric. Understanding Web services: XML, WSDL, 405 SOAP, and UDDI. Boston: Addison-Wesley, 2002." 407 c) info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V 409 where "sici" is the "namespace" component for a of Serial Item and 410 Contribution Identifier [SICI] namespace and "0363- 411 0277(19950315)120:5%3C%3E1.0.TX;2-V" is the "identifier" component 412 for an identifier of an information asset in that namespace in 413 %-escaped form, or in unescaped form "0363- 414 0277(19950315)120:5<>1.0.TX;2-V". 416 The information asset identified by the identifier "0363- 417 0277(19950315)120:5<>1.0.TX;2-V" in the namespace for Serial Item and 418 Contribution Identifiers is the journal issue 420 "Library Journal, Vol. 120, no. 5. March 15, 1995." 422 d) 424 where "bibcode" is the "namespace" component for a NASA ADS Bibcode 425 [BIBCODE] namespace and "2003Icar..163..263Z " is the "identifier" 426 component for an identifier of an information asset within that 427 namespace. This example further shows an application of an "info" 428 URI as the subject of an RDF statement. 430 The information asset identified by the identifier 431 "2003Icar..163..263Z" in the namespace for NASA ADS Bibcodes is the 432 metadata record in the ADS system that describes the journal article 434 "K. Zahnle, P. Schenk, H. Levison and L. Dones, Cratering rates 435 in the outer Solar System, Icarus, 163 (2003) pp. 263-289." 437 e) info:pmid/12376099 439 where "pmid" is the "namespace" component for a PubMed Identifier 440 [PMID] namespace and "12376099" is the "identifier" component for an 441 identifier of an information asset in that namespace. 443 The information asset identified by the identifier "12376099" in the 444 namespace for PubMed Identifiers is the metadata record in the PubMed 445 database that describes the journal article 447 "Wijesuriya SD, Bristow J, Miller WL. Localization and analysis 448 of the principal promoter for human tenascin-X. Genomics. 2002 449 Oct;80(4):443-52." 451 5. Normalization and Comparison of "info" URIs 453 In order to facilitate comparison of "info" URIs, a sequence of 454 normalization steps SHOULD be applied as detailed below. After 455 normalizing the URI strings, comparison of two "info" URIs is then 456 applied on a character by character basis as prescribed by RFC 3986 457 [RFC3986], Section 6.2.1. 459 The following generic normalization steps SHOULD anyway be applied by 460 applications processing "info" URIs: 462 a) Normalize the case of the "scheme" component to be 463 lowercase 464 b) Normalize the case of the "namespace" component to be 465 lowercase 466 c) Unescape all unreserved %-escaped characters in the 467 "namespace" and "identifier" components 468 d) Normalize the case of any %-escaped characters in the 469 "namespace" and "identifier" components to be 470 uppercase 472 Further normalization steps MAY be applied by applications to "info" 473 URIs based on rules recorded in the "info" Registry for a registered 474 public namespace but such normalization steps remain outside of the 475 scope of the "info" URI definition. 477 Since the "info" URI SHOULD be treated as being case-sensitive, a 478 canonical form MAY only be arrived at by consulting the "info" 479 Registry for possible information on the case-sensitivity for 480 identifiers from a registered public namespace, and any case 481 normalization step to apply. The "info" Registry MAY also disclose 482 additional normalization rules regarding the treatment of punctuation 483 characters and the like. 485 In cases, however, where no single canonical form of the "identifier" 486 component exists, it is nevertheless RECOMMENDED that a Namespace 487 Authority nominate a preferred form which SHOULD be used wherever 488 possible within an "info" URI so that applications MAY have an 489 increased chance of successful comparison of two "info" URIs. 491 Note that "info" URIs containing dot-segments (i.e. segments whose 492 full content consists of "." or "..") MAY NOT be suitable for use 493 with applications that perform dot-segment normalization. 495 The following unnormalized forms of an "info" URI 496 U1. INFO:PII/S0888-7543(02)96852-7 497 U2. info:PII/S0888754302968527 498 U3. info:pii/S0888%2D7543%2802%2996852%2D7 499 U4. info:pii/s0888-7543(02)96852-7 501 are normalized to the following respective forms 503 N1. info:pii/S0888-7543(02)96852-7 504 N2. info:pii/S0888754302968527 505 N3. info:pii/S0888-7543(02)96852-7 506 N4. info:pii/s0888-7543(02)96852-7 508 The "info" URI definition does not prescribe further normalization 509 steps although applications MAY apply additional normalization steps 510 according to any rules recorded in the "info" Registry for a 511 registered public namespace. 513 6. Rationale 515 6.1 Why Create a New URI Scheme for Identifiers from Public Namespaces? 517 Under RFC 2718, "Guidelines for new URL Schemes" [RFC2718], it is 518 stated that a URI scheme SHOULD have a "demonstrated utility", and in 519 particular SHOULD be applied to "things that cannot be referred to in 520 any other way". The "info" URI scheme allows identifiers within 521 public namespaces, used for the identification of information assets, 522 to be referred to within the URI allocation. Once a namespace is 523 registered in the "info" Registry, the "info" URI scheme enables an 524 information asset with an identifier in that namespace to be 525 referenced by means of a URI. As a result, the information asset 526 SHALL be considered a resource as defined in RFC 3986 [RFC3986] and 527 SHALL enjoy the same common syntactic, semantic and shared language 528 benefits that the URI presentation confers. 530 6.2 Why Not Use an existing URI Scheme for Identifiers from Public 531 Namespaces? 533 Existing URI schemes are not suitable for employment as the "info" 534 URI scheme admits of no global dereference mechanism. While examples 535 of resource identifiers minted under other URI schemes MAY not always 536 be dereferenceable, nevertheless there is always a common expectation 537 that such URIs can be dereferenced by various resolution mechanisms, 538 whether they be location-dependent or location-independent resource 539 identifiers. The "info" URI scheme applies to a class of resource 540 identifiers whose Namespace Authorities MAY or MAY NOT choose to 541 disclose service mechanisms. Nevertheless, Namespace Authorities are 542 encouraged to disclose in the "info" registration record references 543 to any such service mechanisms in order to provide a greater utility 544 to network applications. 546 6.3 Why Not Create a New URN Namespace ID for Identifiers from Public 547 Namespaces? 549 RFC 2141 [RFC2141] states that "Uniform Resource Names (URNs) are 550 intended to serve as persistent, location-independent, resource 551 identifiers." The "info" URI scheme, on the other hand, does not 552 assert the persistence of the identifiers created under this scheme 553 but rather of the public namespaces grandfathered under this scheme. 554 It exists primarily to disclose the identity of information assets 555 and to facilitate a lightweight registration mechanism for public 556 namespaces of identifiers managed according to the policies and 557 business models of the Namespace Authorities. The "info" URI scheme 558 is neutral with respect to identifier persistence. Moreover, for 559 "info" to operate as a URN NID would require that "info" be 560 constituted as a delegated naming authority. It is not clear that a 561 URN NID would be an appropriate choice for naming authority 562 delegation. 564 Further, the "info" URI scheme is not globally dereferenceable in 565 contrast to the specific recommendation given in RFC 1737, 566 "Functional Requirements for Uniform Resource Names" [RFC1737] that 567 "It is strongly recommended that there be a mapping between the names 568 generated by each naming authority and URLs.". Individual Namespace 569 Authorities registered in the "info" Registry MAY, however, disclose 570 references to service mechanisms and are encouraged to do so. 572 An extra consideration is that the "urn" URI syntax explicitly 573 excludes generic URI hierarchy by reserving the slash "/" character. 574 An "info" URI, on the other hand, admits of hierarchical processing, 575 while remaining neutral with respect to supporting actual hierarchy, 576 and thus allows the slash "/" character (as well as more liberally 577 allowing the ampersand "&" and tilde "~" characters). It therefore 578 represents a lower barrier to entry for Namespace Authorities in 579 keeping with its intention of acting as a bridging mechanism to allow 580 public namespaces to become part of the URI allocation. In sum, an 581 "info" URI is more widely supportive of "human transcribability" as 582 discussed in RFC 3986 [RFC3986] than is a "urn" URI. 584 Additionally the "urn" URI syntax does not support "fragment" 585 components as does the "info" URI syntax for indirect identification 586 of secondary resources. 588 7. Security Considerations 590 The "info" URI scheme syntax is subject to the same security 591 considerations as the generic URI syntax described in RFC 3986 592 [RFC3986]. 594 While some "info" Namespace Authorities MAY choose to disclose 595 service mechanisms, any security considerations resulting from the 596 execution of such services fall outside the scope of this document. 597 It is strongly recommended that the registration record of an "info" 598 namespace include any such considerations. 600 8. IANA Considerations 602 The IANA registry for URI schemes 603 SHOULD be updated to 604 include an entry for the "info" URI scheme when the "info" URI scheme 605 is accepted for publication as an RFC. This entry SHOULD contain the 606 following values: 608 Scheme Name: info 610 Description: Information assets with identifiers in public namespaces 612 Reference: (reference to the RFC under which the "info" URI scheme is 613 described) 615 9. Acknowledgements 617 The authors acknowledge the contributions of Michael Mealling, 618 Verisign, and Patrick Hochstenbach, Ghent University. 620 10. References 622 10.1 Normative References 624 [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for 625 Uniform Resource Names", RFC 1737, December 1994. 627 Retrieved July 9, 2004 from 628 . 630 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 631 Requirements Levels", BCP 14, RFC 2119, March 1997. 633 Retrieved September 20, 2003 from 634 . 636 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 638 Retrieved July 9, 2004 from 639 . 641 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 642 Specifications: ABNF", RFC 2234, November 1997. 644 Retrieved September 20, 2003 from 645 . 647 [RFC2279] Yergeau, F., "UTF-8, A Transformation Format for Unicode 648 and ISO10646", RFC 2279, October 1996. 650 Retrieved September 20, 2003 from 651 . 653 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 654 "Guidelines for new URL Schemes", RFC 2718, November 1999. 656 Retrieved September 20, 2003 from 657 . 659 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 660 Resource Identifier (URI): Generic Syntax", RFC 3986, 661 January 2005. 663 Retrieved August 3, 2005 from 664 . 666 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 667 4.0.0, defined by: The Unicode Standard, Version 4.0". 669 (Reading, MA, Addison-Wesley, 2003). ISBN 0-321-18578-1. 671 10.2 Informative References 673 [BIBCODE] "NASA Astrophysics Data System Bibliographic Code". 675 Retrieved August 1, 2003 from 676 . 678 [DEWEY] "Dewey Decimal Classification". 680 Retrieved September 20, 2003 from 681 . 683 [LCCN] "Library of Congress Control Number". 685 Retrieved August 1, 2003 from 686 . 688 [NISO] "National Information Standards Organization". 690 Retrieved August 1, 2003 from . 692 [OCLCNUM] "Online Computer Library Center OCLC Control Number". 694 Retrieved November 25, 2003 from 695 . 697 [OFI] "ANSI/NISO Z39.88-2004, "The OpenURL Framework for 698 Context-Sensitive Services", 1-880124-61-0". 700 Retrieved August 3, 2005 from 701 . 703 [PII] "Publisher Item Identifier as a means of document 704 identification". 706 Retrieved September 25, 2003 from 707 . 709 [PMID] "PubMed Overview". 711 Retrieved September 25, 2003 from 712 . 715 [SICI] "ANSI/NISO Z39.56-1996 (R2002), "Serial Item and 716 Contribution Identifier (SICI)", ISBN 1-880124-28-9". 718 Retrieved September 25, 2003 from 719 . 721 Authors' Addresses 723 Herbert Van de Sompel 724 Los Alamos National Laboratory 725 Research Library, MS-P362 726 PO Box 1663 727 Los Alamos, NM 87545-1362 728 USA 730 Email: herbertv@lanl.gov 732 Tony Hammond 733 Nature Publishing Group 734 Macmillan House 735 4 Crinan Street 736 London N1 9XW 737 UK 739 Email: t.hammond@nature.com 741 Eamonn Neylon 742 Manifest Solutions 743 Bicester, Oxfordshire OX26 2HX 744 UK 746 Email: eneylon@manifestsolutions.com 748 Stuart L. Weibel 749 OCLC Online Computer Library Center, Inc. 750 6565 Frantz Road 751 Dublin, OH 43017-3395 752 USA 754 Email: weibel@oclc.org 756 Intellectual Property Statement 758 The IETF takes no position regarding the validity or scope of any 759 Intellectual Property Rights or other rights that might be claimed to 760 pertain to the implementation or use of the technology described in 761 this document or the extent to which any license under such rights 762 might or might not be available; nor does it represent that it has 763 made any independent effort to identify any such rights. Information 764 on the procedures with respect to rights in RFC documents can be 765 found in BCP 78 and BCP 79. 767 Copies of IPR disclosures made to the IETF Secretariat and any 768 assurances of licenses to be made available, or the result of an 769 attempt made to obtain a general license or permission for the use of 770 such proprietary rights by implementers or users of this 771 specification can be obtained from the IETF on-line IPR repository at 772 http://www.ietf.org/ipr. 774 The IETF invites any interested party to bring to its attention any 775 copyrights, patents or patent applications, or other proprietary 776 rights that may cover technology that may be required to implement 777 this standard. Please address the information to the IETF at 778 ietf-ipr@ietf.org. 780 Disclaimer of Validity 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 785 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 786 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 787 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Copyright Statement 792 Copyright (C) The Internet Society (2005). This document is subject 793 to the rights, licenses and restrictions contained in BCP 78, and 794 except as set forth therein, the authors retain all their rights. 796 Acknowledgment 798 Funding for the RFC Editor function is currently provided by the 799 Internet Society.