doc: Add RFC documents

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]
+