templates for provisional registration may be included in an
Internet Draft; when the documents expire or are approved for
publication as an RFC, the registration will be updated.
6. IANA Considerations
This document replaces the current "URL Scheme" registry with a new
Uniform Resource Identifier scheme registry, and establishes a new
registration template and a new process for registration. The
process is based on [3] "Expert Review" with an initial (optional)
mailing list review.
The template has an additional field for the status of the URI name
scheme, and the procedures for entering new name schemes have been
augmented. Section 5 establishes the process for new URI scheme
registration.
To transition to the new registry, all URL name schemes in the
existing table should be entered as URI schemes, with ’permanent’
status.
7. Security Considerations
All registered values are expected to contain accurate security
consideration sections; ’permanent’ registered scheme names are
expected to contain complete definitions.
Information concerning possible security vulnerabilities of a
protocol may change over time. Consequently, claims as to the
security properties of a registered URI scheme may change as well.
As new vulnerabilities are discovered, information about such
vulnerabilities may need to be attached to existing documentation, so
that users are not misled as to the true security properties of a
registered URI scheme.
8. Acknowledgements
Many thanks to Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel,
Tony Hammond, Charles Lindsey, Mark Baker, and other members of the
uri@w3.org mailing list for their comments on earlier versions.
Parts of this document are based on [7], [8] and [10]. Some of the
ideas about use of URIs were taken from the "Architecture of the
World Wide Web" [11].
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978,
March 2005.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[6] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
9.2. Informative References
[7] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, November 1999.
[8] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
[9] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.
[10] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[11] W3C Technical Architecture Group, "Architecture of the World
Wide Web, Volume One", December 2004,
<http://www.w3.org/TR/webarch/>.
Authors’ Addresses
Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA
EMail: tony+urireg@maillennium.att.com
Ted Hardie
Qualcomm, Inc.
675 Campbell Technology Parkway
Campbell, CA
USA
EMail: hardie@qualcomm.com
Larry Masinter
Adobe Systems
345 Park Ave
San Jose, CA 95110
US
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
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).