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.
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.
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.
[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-1996.pdf>.
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
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).