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

公開名前空間中の識別子を持つ、 URI scheme により参照可能でない情報資産は多く存在します。 そのような名前空間の例としては、 デューイ十進分類法、 米国議会図書館管理番号、NISO逐次刊行物及び寄稿識別子、 NASA宇宙物理学データ・システム書誌符号、 米国国立医学図書館PubMed識別子などがあります。 その他の名前空間の候補としては、 オンライン計算機図書館センター PCLC番号や NISO OpenURL枠組識別子があります。

   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.

info URI scheme は、 このような公開名前空間に識別子を持つ情報資産の URI による参照を促進します。情報資産をその info URI により参照する時は、その情報資産は RFC 3986 で定義された資源と考慮しなければなりませんし、 URI 表現により与えられる同じ共通の構文的、意味的、 そして共通言語の利益を享受しなければなりません。 ですから、 info URI scheme は URI が割当てられていなかった公開名前空間に URI を割当てて使用することを可能とします。従いまして、 info URI scheme は公開名前空間が URI 割当の一部となるような橋梁機構を提供します。

   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.

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.

[2] この文書に示す info URI 構文は RFC 3986 で定義された共通 URI 構文に適合します。 この仕様書は URI を定義するために RFC 4234 の増補バッカス・ナウア形式 (ABNF) 記法を使います。 RFC 4234 の附属書 B.1 で定義されている中核 ABNF 生成規則 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:

info URI 構文は二部に分けて示します。 A部は info URI scheme に固有の生成規則です。 B部は RFC 3986 にある共通の生成規則で、 完全性と参照のためにここに再録します。 次の生成規則 (A部) は 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 RFC 3986 [RFC3986]:

次の生成規則 (B部) は RFC 3986 の共通の生成規則を再録したものです。

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

scheme 固有部として info-identifier を持つ info URI は、任意選択の fragment 部品を保持して構いません。 info-identifier は、 namespace 部品の後に斜線 / 文字と identifier 部品を連結して構築します。 info URI scheme は斜線 / 文字を使うことにより階層的な処理に支援的です。 ただし、斜線 / 文字は厳密な階層区切りとして解釈するべきではありません。

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

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

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

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

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.

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