The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces

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.

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 and indicate requirement levels for compliant implementations.

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 , Library of Congress Control Numbers , NISO Serial Item and Contribution Identifiers , NASA Astrophysics Data System Bibcodes , and National Library of Medicine PubMed identifiers . Other candidate namespaces include Publisher Item Identifiers , Online Computer Library Center OCLC Numbers , and NISO OpenURL Framework identifiers . 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 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 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.

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 insuring 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. The registration of a public namespace in the "info" Registry SHALL NOT preclude further development of services associated with that namespace which MAY qualify the namespace for additional publication elsewhere within the URI allocation.

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 , 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 . The "info" Registry policy defines a review process for candidate namespaces and provides measures of quality control and suitability for entry of namespaces.

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.

The "info" Registry will be publicly accessible and will support discovery (by both humans and machines) of: string literals identifying the namespaces for which the Registry provides a guarantee of uniqueness and persistence names and contact information of Namespace Authorities syntax requirements for identifiers maintained in such namespaces normalization methodologies for identifiers maintained in such namespaces network references to a description of service mechanisms (if any) for identifiers maintained in such namespaces 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.

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 .)

The "info" URI syntax presented in this document is conformant with the generic URI syntax defined in RFC 3986 . This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC 2234 to define the URI. The following core ABNF productions are used by this specification as defined by Section 6.1 of RFC 2234: 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 the RFC 3986 which are repeated here both for completeness and for reference. The following set of productions (Part A) are specific to the "info" URI scheme:

; 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 the RFC 3986 :

; Part B: ; generic productions from RFC 3986 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 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 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.

The "info" URI syntax uses the same set of allowed US-ASCII characters as specified in RFC 3986 for a generic URI. An "info" URI string SHOULD be represented as a UNICODE string and be encoded in UTF-8 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 , Section 2.4.

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 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 of Serial Item and Contribution Identifier 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."

d) <rdf:Description about="info:bibcode/2003Icar..163..263Z"/> where "bibcode" is the "namespace" component for a NASA ADS 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 an 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 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."

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 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.

Under RFC 2718, "Guidelines for new URL Schemes" , it is stated that a URI scheme SHOULD have a "demonstrated utility", and in particular SHOULD be applied to "things that cannot be referred to in any other way". 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 and SHALL enjoy the same common syntactic, semantic and shared language benefits that the URI presentation confers.

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.

RFC 2141 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 "info" to operate as a URN 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" 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 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.

The "info" URI scheme syntax is subject to the same security considerations as the generic URI syntax described in RFC 3986 . 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.

The IANA registry for URI schemes 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: info Information assets with identifiers in public namespaces (reference to the RFC under which the "info" URI scheme is described)

The authors acknowledge the contributions of Michael Mealling, Verisign, and Patrick Hochstenbach, Ghent University.