diff options
Diffstat (limited to 'doc/rfc/rfc4452.txt')
| -rw-r--r-- | doc/rfc/rfc4452.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc4452.txt b/doc/rfc/rfc4452.txt new file mode 100644 index 0000000..253e1be --- /dev/null +++ b/doc/rfc/rfc4452.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group H. Van de Sompel +Request for Comments: 4452 LANL +Category: Informational T. Hammond + NPG + E. Neylon + Manifest Solutions + S. Weibel + OCLC + April 2006 + + + The "info" URI Scheme + for Information Assets with Identifiers in Public Namespaces + +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 (2006). + +Abstract + + This document defines the "info" Uniform Resource Identifier (URI) + scheme for information assets with identifiers in public namespaces. + Namespaces participating in the "info" URI scheme are regulated by an + "info" Registry mechanism. + + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 1] + +RFC 4452 The "info" URI Scheme April 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Terminology ................................................3 + 1.2. Information Assets .........................................3 + 2. Application of the "info" URI Scheme ............................4 + 3. The "info" Registry .............................................5 + 3.1. Management Characteristics of the "info" Registry ..........5 + 3.2. Functional Characteristics of the "info" Registry ..........5 + 3.3. Maintenance of the "info" Registry .........................6 + 4. The "info" URI Scheme ...........................................6 + 4.1. Definition of "info" URI Syntax ............................6 + 4.2. Allowed Characters Under the "info" URI Scheme .............8 + 4.3. Examples of "info" URIs ....................................9 + 5. Normalization and Comparison of "info" URIs ....................10 + 6. Rationale ......................................................12 + 6.1. Why Create a New URI Scheme for Identifiers from Public + Namespaces? ...............................................12 + 6.2. Why Not Use an Existing URI Scheme for Identifiers + from Public Namespaces? ...................................12 + 6.3. Why Not Create a New URN Namespace ID for + Identifiers from Public Namespaces? .......................12 + 7. Security Considerations ........................................13 + 8. IANA Considerations ............................................14 + 9. Acknowledgements ...............................................14 + 10. References ....................................................14 + 10.1. Normative References .....................................14 + 10.2. Informative References ...................................15 + + + + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 2] + +RFC 4452 The "info" URI Scheme April 2006 + + +1. Introduction + + This document defines the "info" Uniform Resource Identifier (URI) + scheme for information assets that have identifiers in public + namespaces but are not part of the URI allocation. By "information + asset" this document intends any information construct that has + identity within a public namespace. + +1.1. Terminology + + 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. + +1.2. Information Assets + + There exist many information assets with identifiers in public + namespaces that are not referenceable by URI schemes. Examples of + such namespaces include Dewey Decimal Classifications [DEWEY], + Library of Congress Control Numbers [LCCN], NISO Serial Item and + Contribution Identifiers [SICI], NASA Astrophysics Data System + Bibcodes [BIBCODE], and National Library of Medicine PubMed + identifiers [PMID]. Other candidate namespaces include Online + Computer Library Center OCLC Numbers [OCLCNUM] and NISO OpenURL + Framework identifiers [OFI]. + + The "info" URI scheme facilitates the referencing of information + assets that have identifiers in such public namespaces by means of + URIs. When referencing an information asset by means of its "info" + URI, the asset SHALL be considered a "resource" as defined in RFC + 3986 [RFC3986] and SHALL enjoy the same common syntactic, semantic, + and shared language benefits that the URI presentation confers. As + such, the "info" URI scheme enables public namespaces that are not + part of the URI allocation to be represented within the allocation. + The "info" URI scheme thus provides a bridging mechanism to allow + public namespaces to become part of the URI allocation. + + Namespaces declared under the "info" URI scheme are regulated by an + "info" Registry mechanism. The "info" Registry allows a public + namespace that is not part of the URI allocation to be declared in a + registration process by the organization that manages it (the + Namespace Authority). The "info" Registry supports the declaration + of public namespaces that are not part of the URI allocation in a + manner that facilitates the construction of URIs for information + assets without imposing the burdens of independent URI registration + and maintenance of resource representations on the Namespace + Authority. Information assets identified within a registered + + + +Van de Sompel, et al. Informational [Page 3] + +RFC 4452 The "info" URI Scheme April 2006 + + + namespace SHALL be added or deleted according to the business + processes of the Namespace Authority, and yet MAY be referenced + within network applications via the "info" URI in an open, + standardized way without additional action on the part of the + Namespace Authority. + + The "info" URI scheme exists primarily for identification purposes. + Implementations MUST NOT assume that an "info" URI can be + dereferenced to a representation of the resource identified by the + URI although Namespace Authorities MAY disclose in the registration + record references to service mechanisms pertaining to identifiers + from the registered namespace. Applications of the "info" URI scheme + are restricted to the identification of information assets and the + declaration of normalization rules for comparing identifiers of such + information assets regardless of whether any services relating to + such information assets are accessible via the Internet. References + to such services MAY be disclosed within an "info" registration + record, but these services SHALL NOT be regarded as authoritative. + The "info" URI scheme does not support global resolution methods. + +2. Application of the "info" URI Scheme + + Public namespaces that are used for the identification of information + assets and that are not part of the URI allocation MAY be registered + as namespaces within the "info" Registry. Namespace Authorities MAY + register these namespaces in the "info" Registry, thereby making + these namespaces available to applications that need to reference + information assets by means of a URI. Registrations of public + namespaces that are not part of the URI allocation by parties other + than the Namespace Authority SHALL NOT be permitted, thereby ensuring + against hostile usurpation or inappropriate usage of registered + service marks or the public namespaces of others. + + Registration of a public namespace under the "info" Registry implies + no particular functionalities of the identifiers from the registered + namespace other than the identification of information assets. No + resolution mechanisms can be assumed for the "info" URI scheme, + though for any particular namespace there MAY exist mechanisms for + resolving identifiers to network services. The definition of such + services falls outside the scope of the "info" URI scheme. + Registration does not define namespace-specific semantics for + identifiers within a registered namespace, though allowable character + sets and normalization rules are specified in Sections 4 and 5 so as + to ensure that the URIs created using such identifiers are compliant + with applications that use URIs. + + + + + + +Van de Sompel, et al. Informational [Page 4] + +RFC 4452 The "info" URI Scheme April 2006 + + + The registration of a public namespace in the "info" Registry SHALL + NOT preclude further development of services associated with that + namespace that MAY qualify the namespace for additional publication + elsewhere within the URI allocation. + +3. The "info" Registry + + The "info" Registry provides a mechanism for the registration of + public namespaces that are used for the identification of information + assets and that are not part of the URI allocation. + + NISO [NISO], the National Information Standards Organization, will + act as the Maintenance Agency for the "info" Registry and will + delegate the day-to-day operation of the "info" Registry to a + Registry Operator. As the Maintenance Agency, NISO will ensure that + the Registry Operator operates the "info" Registry in accordance with + a publicly articulated policy document established under NISO + governance and made available on the "info" website, + <http://info-uri.info/>. The "info" Registry policy defines a review + process for candidate namespaces and provides measures of quality + control and suitability for entry of namespaces. + +3.1. Management Characteristics of the "info" Registry + + The "info" Registry will be managed according to policies established + under the auspices of NISO. All such policies, as well as the + namespace declarations in the "info" Registry, will be public. + +3.2. Functional Characteristics of the "info" Registry + + The "info" Registry will be publicly accessible and will support + discovery (by both humans and machines) of: + + o string literals identifying the namespaces for which the Registry + provides a guarantee of uniqueness and persistence + o names and contact information of Namespace Authorities + o syntax requirements for identifiers maintained in such namespaces + o normalization methodologies for identifiers maintained in such + namespaces + o network references to a description of service mechanisms (if any) + for identifiers maintained in such namespaces + o ancillary documentation + + Registry entries refer to the corresponding "namespace" and + "identifier" components, which are defined in the ABNF given in + Section 4.1 of this document. + + + + + +Van de Sompel, et al. Informational [Page 5] + +RFC 4452 The "info" URI Scheme April 2006 + + +3.3. Maintenance of the "info" Registry + + The public namespaces that MAY be registered in the "info" Registry + will be those of interest to the communities served by NISO, and + therefore NISO is committed to act as Maintenance Authority for the + "info" Registry and to assign a Registry Operator to operate it. + + NISO, a non-profit association accredited by the American National + Standards Institute (ANSI), identifies, develops, maintains, and + publishes technical standards to manage information in the digital + environment. NISO standards apply technologies to the full range of + information-related needs, including retrieval, re-purposing, + storage, metadata, and preservation. + + Founded in 1939, incorporated as a not-for-profit education + association in 1983, and assuming its current name the following + year, NISO draws its support from the communities it serves. The + leaders of over 70 organizations in the fields of publishing, + libraries, IT, and media serve as its voting members. Hundreds of + experts and practitioners serve on NISO committees and as officers of + the association. + + NISO has been designated by ANSI to represent US interests to the + International Organization for Standardization's (ISO) Technical + Committee 46 on Information and Documentation. + + The NISO headquarters office is located at 4733 Bethesda Ave., + Bethesda, MD 20814, USA. (For further information, see the NISO + website, <http://www.niso.org/>.) + +4. The "info" URI Scheme + +4.1. Definition of "info" URI Syntax + + The "info" URI syntax presented in this document is conformant with + the generic URI syntax defined in RFC 3986 [RFC3986]. This + specification uses the Augmented Backus-Naur Form (ABNF) notation of + RFC 4234 [RFC4234] to define the URI. The following core ABNF + productions are used by this specification as defined by Appendix B.1 + of RFC 4234: ALPHA, DIGIT, HEXDIG. + + The "info" URI syntax is presented in two parts. Part A contains + productions specific to the "info" URI scheme, while Part B contains + generic productions from RFC 3986 [RFC3986], which are repeated here + both for completeness and for reference. The following set of + productions (Part A) is specific to the "info" URI scheme: + + + + + +Van de Sompel, et al. Informational [Page 6] + +RFC 4452 The "info" URI Scheme April 2006 + + + ; Part A: + ; productions specific to the "info" URI scheme + + info-URI = info-scheme ":" info-identifier [ "#" fragment ] + + info-scheme = "info" + + info-identifier = namespace "/" identifier + + namespace = scheme + + identifier = *( pchar / "/" ) + + ; 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 + + This next set of productions (Part B) are generic productions + reproduced from RFC 3986 [RFC3986]: + + ; Part B: + ; generic productions from RFC 3986 [RFC3986] + + scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) + + pchar = unreserved / pct-encoded / sub-delims / ":" / "@" + + fragment = *( pchar / "/" / "?" ) + + unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" + + pct-encoded = "%" HEXDIG HEXDIG + + sub-delims = "!" / "$" / "&" / "'" / "(" / ")" + / "*" / "+" / "," / ";" / "=" + An "info" URI has an "info-identifier" as its scheme-specific part + and MAY take an optional "fragment" component. An "info-identifier" + is constructed by appending an "identifier" component to a + "namespace" component separated by a slash "/" character. The "info" + URI scheme is supportive of hierarchical processing as indicated by + the presence of the slash "/" character, although the slash "/" + character SHOULD NOT be interpreted as a strict hierarchy delimiter. + + Values for the "namespace" component of the "info" URI are name + tokens composed of URI scheme characters only (cf. the "scheme" + production). They identify the public namespace in which the + (unescaped) value for the "identifier" component originates, and are + registered in the "info" Registry, which guarantees their uniqueness + + + +Van de Sompel, et al. Informational [Page 7] + +RFC 4452 The "info" URI Scheme April 2006 + + + and persistence. Although the "namespace" component is + case-insensitive, the canonical form is lowercase and documents that + specify values for the "namespace" component SHOULD do so using + lowercase letters. An implementation SHOULD accept uppercase letters + as equivalent to lowercase in "namespace" names, for the sake of + robustness, but SHOULD only generate lowercase "namespace" names, for + consistency. + + Values for the "identifier" component of the "info" URI MAY be viewed + as being hierarchical strings composed of path segments built from + path segment characters (cf. the "pchar" production), the segments + being separated by slash "/" characters, although any semantic + interpretation of the "/" character as a hierarchy delimiter MUST NOT + be assumed. In their originating public namespace, the (unescaped) + values for the "identifier" component identify information assets. + The values for the "identifier" component MUST be %-escaped as + required by this syntax. The "identifier" component SHOULD be + treated as case-sensitive, although the "info" Registry MAY record + the case-sensitivity of identifiers from particular registered public + namespaces. The "info" Registry MAY also disclose additional + normalization rules regarding the treatment of punctuation characters + and the like. + + Values for the "fragment" component of the "info" URI are strings + composed of path segment characters (cf. the "pchar" production) plus + the slash "/" character and the question mark "?" character. No + semantic role is assigned to the slash "/" character and the question + mark "?" character within the "fragment" component. The (unescaped) + values for the "fragment" component identify secondary information + assets with respect to the primary information asset, which is + referenced by the "info-identifier". The values for the "fragment" + component MUST be %-escaped as required by this syntax. The + "fragment" component MUST be treated as being case-sensitive. + +4.2. Allowed Characters Under the "info" URI Scheme + + The "info" URI syntax uses the same set of allowed US-ASCII + characters as specified in RFC 3986 [RFC3986] for a generic URI. An + "info" URI string SHOULD be represented as a Unicode [UNICODE] string + and be encoded in UTF-8 [RFC3629] form. Reserved characters as well + as excluded US-ASCII characters and non-US-ASCII characters MUST be + %-escaped before forming the URI. Details of the %-escape encoding + can be found in RFC 3986 [RFC3986], Section 2.4. + + + + + + + + +Van de Sompel, et al. Informational [Page 8] + +RFC 4452 The "info" URI Scheme April 2006 + + +4.3. Examples of "info" URIs + + Some examples of syntactically valid "info" URIs are given below: + + a) info:ddc/22/eng//004.678 + + where "ddc" is the "namespace" component for a Dewey Decimal + Classification [DEWEY] namespace and "22/eng//004.678" is the + "identifier" component for an identifier of an information asset + within that namespace. + + The information asset identified by the identifier "22/eng//004.678" + in the namespace for (22nd Ed.) English-language Dewey Decimal + Classifications is the classification + + "Internet" + + + b) info:lccn/2002022641 + + where "lccn" is the "namespace" component for a Library of Congress + Control Number [LCCN] namespace and "2002022641" is the "identifier" + component for an identifier of an information asset within that + namespace. + + The information asset identified by the identifier "2002022641" in + the namespace for Library of Congress Control Numbers is the metadata + record + + "Newcomer, Eric. Understanding Web services: XML, WSDL, + SOAP, and UDDI. Boston: Addison-Wesley, 2002." + + + c) info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V + + where "sici" is the "namespace" component for a Serial Item and + Contribution Identifier [SICI] namespace and + "0363-0277(19950315)120:5%3C%3E1.0.TX;2-V" is the "identifier" + component for an identifier of an information asset in that namespace + in %-escaped form, or in unescaped form + "0363-0277(19950315)120:5<>1.0.TX;2-V". + + The information asset identified by the identifier + "0363-0277(19950315)120:5<>1.0.TX;2-V" in the namespace for Serial + Item and Contribution Identifiers is the journal issue + + "Library Journal, Vol. 120, no. 5. March 15, 1995." + + + + +Van de Sompel, et al. Informational [Page 9] + +RFC 4452 The "info" URI Scheme April 2006 + + + d) <rdf:Description about="info:bibcode/2003Icar..163..263Z"/> + + where "bibcode" is the "namespace" component for a NASA Astrophysics + Data System (ADS) Bibcode [BIBCODE] namespace and + "2003Icar..163..263Z" is the "identifier" component for an identifier + of an information asset within that namespace. This example further + shows an application of an "info" URI as the subject of a Resource + Description Framework (RDF) statement. + + The information asset identified by the identifier + "2003Icar..163..263Z" in the namespace for NASA ADS Bibcodes is the + metadata record in the ADS system that describes the journal article + + "K. Zahnle, P. Schenk, H. Levison and L. Dones, Cratering rates + in the outer Solar System, Icarus, 163 (2003) pp. 263-289." + + + e) info:pmid/12376099 + + where "pmid" is the "namespace" component for a PubMed Identifier + [PMID] namespace and "12376099" is the "identifier" component for an + identifier of an information asset in that namespace. + + The information asset identified by the identifier "12376099" in the + namespace for PubMed Identifiers is the metadata record in the PubMed + database that describes the journal article + + "Wijesuriya SD, Bristow J, Miller WL. Localization and analysis + of the principal promoter for human tenascin-X. Genomics. 2002 + Oct;80(4):443-52." + +5. Normalization and Comparison of "info" URIs + + In order to facilitate comparison of "info" URIs, a sequence of + normalization steps SHOULD be applied as detailed below. After + normalizing the URI strings, comparison of two "info" URIs is then + applied on a character-by-character basis as prescribed by RFC 3986 + [RFC3986], Section 6.2.1. + + The following generic normalization steps SHOULD anyway be applied by + applications processing "info" URIs: + + a) Normalize the case of the "scheme" component to be + lowercase + b) Normalize the case of the "namespace" component to be + lowercase + c) Unescape all unreserved %-escaped characters in the + "namespace" and "identifier" components + + + +Van de Sompel, et al. Informational [Page 10] + +RFC 4452 The "info" URI Scheme April 2006 + + + d) Normalize the case of any %-escaped characters in the + "namespace" and "identifier" components to be + uppercase + + Further normalization steps MAY be applied by applications to "info" + URIs based on rules recorded in the "info" Registry for a registered + public namespace, but such normalization steps remain outside of the + scope of the "info" URI definition. + + Since the "info" URI SHOULD be treated as being case-sensitive, a + canonical form MAY only be arrived at by consulting the "info" + Registry for possible information on the case-sensitivity for + identifiers from a registered public namespace, and any case + normalization step to apply. The "info" Registry MAY also disclose + additional normalization rules regarding the treatment of punctuation + characters and the like. + + In cases, however, where no single canonical form of the "identifier" + component exists, it is nevertheless RECOMMENDED that a Namespace + Authority nominate a preferred form, which SHOULD be used wherever + possible within an "info" URI so that applications MAY have an + increased chance of successful comparison of two "info" URIs. + + 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 following unnormalized forms of an "info" URI + + U1. INFO:PII/S0888-7543(02)96852-7 + U2. info:PII/S0888754302968527 + U3. info:pii/S0888%2D7543%2802%2996852%2D7 + U4. info:pii/s0888-7543(02)96852-7 + + are normalized to the following respective forms + + N1. info:pii/S0888-7543(02)96852-7 + N2. info:pii/S0888754302968527 + N3. info:pii/S0888-7543(02)96852-7 + N4. info:pii/s0888-7543(02)96852-7 + + The "info" URI definition does not prescribe further normalization + steps, although applications MAY apply additional normalization steps + according to any rules recorded in the "info" Registry for a + registered public namespace. + + + + + + +Van de Sompel, et al. Informational [Page 11] + +RFC 4452 The "info" URI Scheme April 2006 + + +6. Rationale + +6.1. Why Create a New URI Scheme for Identifiers from Public + Namespaces? + + Under RFC 4395, "Guidelines and Registration Procedures for New URI + Schemes" [RFC4395], it is stated in Section 2.1 "Demonstrable, New, + Long-Lived Utility" that "New URI schemes SHOULD have clear utility + to the broad Internet community, beyond that available with already + registered URI schemes". The "info" URI scheme allows identifiers + within public namespaces, used for the identification of information + assets, to be referred to within the URI allocation. Once a + namespace is registered in the "info" Registry, the "info" URI scheme + enables an information asset with an identifier in that namespace to + be referenced by means of a URI. As a result, the information asset + SHALL be considered a resource as defined in RFC 3986 [RFC3986] and + SHALL enjoy the same common syntactic, semantic, and shared language + benefits that the URI presentation confers. + +6.2. Why Not Use an Existing URI Scheme for Identifiers from Public + Namespaces? + + 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. + +6.3. Why Not Create a New URN Namespace ID for Identifiers from Public + Namespaces? + + RFC 2141 [RFC2141] states that "Uniform Resource Names (URNs) are + intended to serve as persistent, location-independent, resource + identifiers". The "info" URI scheme, on the other hand, does not + assert the persistence of the identifiers created under this scheme + but rather of the public namespaces grandfathered under this scheme. + It exists primarily to disclose the identity of information assets + and to facilitate a lightweight registration mechanism for public + namespaces of identifiers managed according to the policies and + business models of the Namespace Authorities. The "info" URI scheme + is neutral with respect to identifier persistence. Moreover, for + + + +Van de Sompel, et al. Informational [Page 12] + +RFC 4452 The "info" URI Scheme April 2006 + + + "info" to operate as a URN Network Identifier (NID) would require + that "info" be constituted as a delegated naming authority. It is + not clear that a URN NID would be an appropriate choice for naming + authority delegation. + + Further, the "info" URI scheme is not globally dereferenceable in + contrast to the specific recommendation given in RFC 1737, + "Functional Requirements for Uniform Resource Names" [RFC1737] that + "It is strongly recommended that there be a mapping between the names + generated by each naming authority and URLs". Individual Namespace + Authorities registered in the "info" Registry MAY, however, disclose + references to service mechanisms and are encouraged to do so. + + An extra consideration is that the "urn" URI syntax explicitly + excludes generic URI hierarchy by reserving the slash "/" character. + An "info" URI, on the other hand, admits of hierarchical processing, + while remaining neutral with respect to supporting actual hierarchy, + and thus allows the slash "/" character (as well as more liberally + allowing the ampersand "&" and tilde "~" characters). It therefore + represents a lower barrier to entry for Namespace Authorities in + keeping with its intention of acting as a bridging mechanism to allow + public namespaces to become part of the URI allocation. In sum, an + "info" URI is more widely supportive of "human transcribability" as + discussed in RFC 3986 [RFC3986] than is a "urn" URI. + + Additionally, the "urn" URI syntax does not support "fragment" + components as does the "info" URI syntax for indirect identification + of secondary resources. + +7. Security Considerations + + The "info" URI scheme syntax is subject to the same security + considerations as the generic URI syntax described in RFC 3986 + [RFC3986]. + + While some "info" Namespace Authorities MAY choose to disclose + service mechanisms, any security considerations resulting from the + execution of such services fall outside the scope of this document. + It is strongly recommended that the registration record of an "info" + namespace include any such considerations. + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 13] + +RFC 4452 The "info" URI Scheme April 2006 + + +8. IANA Considerations + + The IANA registry for URI schemes + <http://www.iana.org/assignments/uri-schemes.html> SHOULD be updated + to include an entry for the "info" URI scheme when the "info" URI + scheme is accepted for publication as an RFC. This entry SHOULD + contain the following values: + + Scheme Name: info + + Description: Information Assets with Identifiers in Public + Namespaces + + Reference: RFC 4452 + +9. Acknowledgements + + The authors acknowledge the contributions of Michael Mealling, + Verisign, and Patrick Hochstenbach, Ghent University. + +10. References + +10.1. Normative References + + [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for + Uniform Resource Names", RFC 1737, December 1994. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and + Registration Procedures for New URI Schemes", BCP 115, RFC + 4395, February 2006. + + + + + + +Van de Sompel, et al. Informational [Page 14] + +RFC 4452 The "info" URI Scheme April 2006 + + + [UNICODE] The Unicode Consortium, "The Unicode Standard, Version + 4.0.0, defined by: The Unicode Standard, Version 4.0". + (Reading, MA, Addison-Wesley, 2003). ISBN 0-321-18578-1. + +10.2. Informative References + + [BIBCODE] "NASA Astrophysics Data System Bibliographic Code", + <http://adsdoc.harvard.edu/abs_doc/help_pages/data.html>. + + [DEWEY] "Dewey Decimal Classification", + <http://www.oclc.org/dewey/>. + + [LCCN] "Library of Congress Control Number", + <http://lcweb.loc.gov/marc/lccn_structure.html>. + + [NISO] "National Information Standards Organization", + <http://www.niso.org/>. + + [OCLCNUM] "Online Computer Library Center OCLC Control Number", + <http://www.oclc.org/bibformats/en/fixedfield/oclc.shtm>. + + [OFI] "ANSI/NISO Z39.88-2004, "The OpenURL Framework for + Context-Sensitive Services", ISBN 1-880124-61-0", + <http://www.niso.org/standards/resources/Z39_88_2004.pdf>. + + [PMID] "PubMed Overview", <http://www.ncbi.nlm.nih.gov/entrez/ + query/static/overview.html>. + + [SICI] "ANSI/NISO Z39.56-1996 (R2002), "Serial Item and + Contribution Identifier (SICI)", ISBN 1-880124-28-9", + <http://www.niso.org/standards/resources/Z39-56.pdf>. + + + + + + + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 15] + +RFC 4452 The "info" URI Scheme April 2006 + + +Authors' Addresses + + Herbert Van de Sompel + Los Alamos National Laboratory + Research Library, MS-P362 + PO Box 1663 + Los Alamos, NM 87545-1362 + USA + + EMail: herbertv@lanl.gov + + + Tony Hammond + Nature Publishing Group + Macmillan House + 4 Crinan Street + London N1 9XW + UK + + EMail: t.hammond@nature.com + + + Eamonn Neylon + Manifest Solutions + Bicester, Oxfordshire OX26 2HX + UK + + EMail: eneylon@manifestsolutions.com + + + Stuart L. Weibel + OCLC Online Computer Library Center, Inc. + 6565 Frantz Road + Dublin, OH 43017-3395 + USA + + EMail: weibel@oclc.org + + + + + + + + + + + + + + +Van de Sompel, et al. Informational [Page 16] + +RFC 4452 The "info" URI Scheme April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Van de Sompel, et al. Informational [Page 17] + |