Network Working Group T. Hansen Internet-Draft AT&T Laboratories Updates: 2717,2718 (if approved) T. Hardie Expires: June 8, 2005 Qualcomm, Inc. L. Masinter Adobe Systems December 8, 2004 Guidelines and Registration Procedures for new URI Schemes draft-hansen-2717bis-2718bis-uri-guidelines-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 8, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document provides guidelines and recommendations for the definition of new URI schemes, and a mechanism to register those URI schemes. The registration requirements have been simplified by providing for provisional registrations that need no technical review Hansen, et al. Expires June 8, 2005 [Page 1]
Internet-Draft New URI Schemes December 2004 and may share names with existing scheme names. Please send comments to uri@w3.org [10]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Guidelines for new URI schemes . . . . . . . . . . . . . . . . 4 2.1 Demonstratable, new, long-lived utility . . . . . . . . . 4 2.2 Syntactic compatibility . . . . . . . . . . . . . . . . . 4 2.3 Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Definition of operations . . . . . . . . . . . . . . . . . 5 2.5 Character encoding . . . . . . . . . . . . . . . . . . . . 6 2.6 Clear security considerations . . . . . . . . . . . . . . 6 2.7 Scheme Name considerations . . . . . . . . . . . . . . . . 6 3. URI Scheme Registration Procedure . . . . . . . . . . . . . . 7 3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Provisional URI Scheme Considerations . . . . . . . . . . 8 3.3 Registration Procedures . . . . . . . . . . . . . . . . . 8 3.4 Change Control . . . . . . . . . . . . . . . . . . . . . . 9 3.5 New URI Scheme Registration Template . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 7.2 Informative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Hansen, et al. Expires June 8, 2005 [Page 2]
Internet-Draft New URI Schemes December 2004 1. Introduction A Uniform Resource Identifier (URI) is a compact string representation for identifying resources. RFC XXXX [6] defines the general syntax of URIs. This document provides guidelines for the definition of new URI schemes (for consideration by those who are defining and registering or evaluating those definitions), and a process and mechanism for registering URI schemes. This document replaces both RFCs 2717 [2] and 2718 [3]. The original terminology for the URI protocol element attempted to draw a distinction between 'locators' -- identifiers used for accessing resources available on the Internet, and 'names' -- identifiers used for naming possibly abstract resources, independent of any mechanism for accessing them. The intent was to use the designation "URL" (Uniform Resource Locator) for those identifiers that were locators, and "URN" (Uniform Resource Name) for those identifiers that were names. In practice, the line between 'locator' and 'name' has been difficult to draw: locators can be used as names, and names can be used as locators. As a result, recent documents have used the term "URI" for all resource identifiers, avoiding the term "URL", and reserving the term "URN" explicitly for those URIs using the "urn" scheme name (RFC 2141 [1]). URNs remain a distinct class of URIs because of the requirements set out in RFC 3406 [8]; this document's procedures do not update or supersede the procedures set out in RFC 3406. RFC 2717 defined a set of registration trees in which URI schemes could be registered, one of which was called the IETF Tree, to be managed by IANA. RFC 2717 proposed that additional registration trees might be approved by the IESG, however, no such registration trees have been approved. This document eliminates RFC 2717's distinction between different 'trees' for URI schemes; instead there is a single namespace for registered values. Within that namespace, there are values that are approved as meeting a set of criteria for URI schemes. Other scheme names may also be registered provisionally or without necessarily passing any review process or criteria. The intent of the registry is to: o provide a low barrier for provisional registrations of URI scheme names o provide a central point of discovery for established URI scheme names, and easy location of their defining documents; o discourage, but not prevent, multiple definitions of URI scheme names for different purposes; Hansen, et al. Expires June 8, 2005 [Page 3]
Internet-Draft New URI Schemes December 2004 o help those proposing new URI scheme names to discern established trends and conventions, and avoid names that might be confused with existing ones. 2. Guidelines for new URI schemes This section gives some considerations when defining new URI schemes. These are useful for all schemes (whether or not standards track); IETF standards track URI schemes may require review against these criteria. 2.1 Demonstratable, new, long-lived utility Because URI schemes are a single, global namespace, the unbounded registration of new schemes is harmful to the Internet community. For this reason, new URI schemes should have clear utility to the broad Internet community, beyond that available with already registered URI schemes. 2.2 Syntactic compatibility RFC XXXX [6] defines a generic syntax for URI schemes with hierarchical components and a naming authority. New URI schemes should follow this syntax. URI schemes that are not intended for use with relative URIs should avoid use of the forward slash "/" character, which is used for hierarchical delimiters. If there is a strong reason for a URI scheme to not use the RFC XXXX syntax, the new scheme definition should follow the syntax of other previously registered schemes, if possible. Avoid improper use of "//". The use of double slashes in the first part of a URI is not simply an artistic indicator that what follows is a URI: Double slashes are used ONLY when the syntax of the URI's <scheme-specific-part> contains a hierarchical structure as described in RFC XXXX. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section ???? of RFC XXXX for more details.) URI schemes that do not contain a conformant hierarchical structure in their <scheme-specific-part> should not use double slashes following the "<scheme>:" string. 2.3 Well-Defined While URIs may or may not be useful as locators in practice, a URI scheme definition itself should be clear as to how it is expected to Hansen, et al. Expires June 8, 2005 [Page 4]
Internet-Draft New URI Schemes December 2004 function. Schemes that are not intended to be used as locators should still describe how the resource indicated can be identified by software that obtains a URI of that scheme. For schemes that function as locators, it is important that the mechanism of resource location be clearly defined. This might mean different things depending on the nature of the URI scheme. In many cases, new URI schemes are defined as ways to translate other protocols and name spaces into the general framework of URIs. For example, the "ftp" URI scheme translates from the FTP protocol, while the "mid" URI scheme translates from the Message-ID field of messages. For such schemes, the description of the mapping must be complete, must describe how characters get encoded or not in URIs, must describe exactly how all legal values of the base standard can be represented using the URI scheme, and exactly which modifiers, alternate forms and other artifacts from the base standards are included or not included. These requirements are elaborated below. In some cases, URI schemes do not have particular network protocols associated with them, because their use as a locator is limited to contexts where the access method is understood. This is the case, for example, with the "cid" and "mid" URI schemes. For these URI schemes, the specification should describe the notation of the scheme, the contexts of use, and a complete mapping of the locator from its source. 2.4 Definition of operations In addition to the definition of how a URI identifies a resource, a URI scheme definition should also define, if applicable, the set of operations that may be performed on a resource using the URI as its identifier. The basis for this model is HTTP; a HTTP resource can be operated on by GET, POST, PUT and a number of other operations available through the HTTP protocol. The URI scheme definition should describe all well-defined operations on the URI identifier, and what they are supposed to do. Some URI schemes (for example, "telnet") provide location information for hooking onto bi-directional data streams, and don't fit the "infoaccess" paradigm of most URIs very well; this should be documented. NOTE: It is perfectly valid to say that "no operation apart from GET is defined for this URI". It is also valid to say that "there's only one operation defined for this URI, and it's not very GET-like". The important point is that what is defined on this type is described. Hansen, et al. Expires June 8, 2005 [Page 5]
Internet-Draft New URI Schemes December 2004 2.5 Character encoding When describing URI schemes in which (some of) the elements of the URI are actually representations of sequences of characters, care should be taken not to introduce unnecessary variety in the ways in which characters are encoded into octets and then into URI characters. Unless there is some compelling reason for a particular scheme to do otherwise, translating character sequences into UTF-8 (RFC 2279 [4]) and then subsequently using the %HH encoding for unsafe octets is recommended. 2.6 Clear security considerations Definitions of URI schemes should be accompanied by a clear analysis of the security implications for systems that use the URI scheme. o Does the user need to be warned that such a thing is happening without an explicit request (GET for the source of an IMG tag, for instance)? o Is it possible to fake URIs of this type that point to different things in a dangerous way? o Are there mechanisms for identifying the requester that can be used or need to be used with this mechanism (the From: field in a mailto: URI, or the Kerberos login required for AFS access in the AFS: URI, for instance)? o Does the mechanism contain passwords or other security information that are passed inside the referring document in the clear (as in the "ftp" URI, for instance)? o URI schemes should not subvert the security of existing schemes or protocols (e.g., by layering or tunneling). 2.7 Scheme Name considerations URI scheme names should be short, but also sufficiently descriptive and distinguished to avoid problems. Avoid trademark names or other symbols that might have problems with the 'ownership' or rights to use the name in Internet protocols. Avoid using names that are either very general purpose or associated in the community with some other application or protocol. Organizations that desire a private name space for URI scheme names are encouraged to use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com-example-info might be registered by the vendor that owns the example.com domain name. Any scheme starting with the letters "U" and "R", in particular if it Hansen, et al. Expires June 8, 2005 [Page 6]
Internet-Draft New URI Schemes December 2004 attaches any of the meanings "uniform", "universal" or "unifying" to the first letter, is going to cause intense debate, and generate much heat (but maybe little light). Any such proposal should either make sure that there is a large consensus behind it that it will be the only scheme of its type, or pick another name. 3. URI Scheme Registration Procedure 3.1 General The goals for registering URI Schemes are to avoid (when possible) duplicate use of the same URI scheme name for different purposes, to allow implementors of software that processes URIs to find appropriate information about URI schemes, and to encourage and facilitate technical review of URI scheme definitions before corresponding software is deployed. To allow others to determine the results of technical review, the URI scheme registration process has two outcomes for URI scheme proposals: a 'provisional' status for URI schemes whose definitions have not been reviewed or were not accepted by the review process, and a 'permanent' status for those schemes that have been accepted by IETF review. Review is based on general agreement that the URI scheme definition proposed meets the requirements in Section 2. Provisional status is useful for registering legacy URI schemes that have already been widely deployed without registration, and for which review at this time would be inappropriate. Provisional status may also be useful for private or experimental use. Permanent status is intended for use by IETF standards-track protocols. The status requires a substantive review and approval process. A person wishing to register a URI scheme should first determine whether the scheme is appropriate for 'permanent' status, meets the guidelines, and if 'permanent' status is desirable. Provisional registration of a URI scheme merely requires providing IANA with the information in the URI scheme registration template (Section 3.5). It is useful to also provide this information in an Internet Draft, especially if the scheme is intended for ultimate registration as a 'permanent' URI scheme. Permanent registration of a URI scheme requires IETF review and IESG approval. In many cases, permanent registration involves the promotion of an existing provisional registration. In general, the creation of a new permanent URI scheme requires a Standards Track Hansen, et al. Expires June 8, 2005 [Page 7]
Internet-Draft New URI Schemes December 2004 RFC. In some cases, a URI scheme registration in an Informational RFC may be approved by the IESG for 'permanent' URI registration. 3.2 Provisional URI Scheme Considerations Registration of a provisional URI scheme does not require or imply any kind of endorsement by the IETF, IANA or any other body. The main requirement for a provisional URI scheme is that there MUST NOT already be a corresponding permanent entry with the same URI scheme name. In cases where separate communities have already established differing uses of the same URI scheme name for different purposes, it is possible to have two or more provisional registrations for the same URI scheme name. A provisional registration MUST also identify the person submitting the registration, and SHOULD contain a citable specification for the URI scheme definition, unless credible reasons for not providing this are given. All new provisional URI schemes SHOULD follow the Guidelines for URI Schemes, set forth in Section 2. In particular, an analysis of the security issues inherent in the new URI scheme is encouraged. Regardless of what security analysis is or is not performed, all descriptions of security issues must be as accurate as possible. In particular, a statement that there are "no security issues associated with this scheme" must not be confused with "the security issues associates with this scheme have not been assessed" or "the security issues associated with this scheme cannot be predicted because of <reason>". There is not a requirement that provisional URI name schemes be secure or completely free from risks, but all known security risks SHOULD be identified. Previously unregistered URI schemes discovered in use may be registered by third parties on behalf of those who created the URI scheme. 3.3 Registration Procedures Someone wishing to register a URI scheme should: 1. Check the IANA URI scheme registry to see whether or not there is already an entry for the desired name. If there is already a permanent entry under the name, choose a different URI scheme name. 2. Prepare a URI scheme registration template, as specified in Section 3.5. The URI scheme registration template may be contained in an Internet Draft, to facilitate discussion or if Hansen, et al. Expires June 8, 2005 [Page 8]
Internet-Draft New URI Schemes December 2004 the URI scheme is intended for permanent status. 3. If desired, send a copy of the template or a pointer to the Internet Draft (and containing section number) to the mailing list uri-review@ietf.org; participate in the discussion and review of the URI scheme; allow a reasonable period (at least 2 weeks) for discussion and comments. 4. Submit the registration template (or a pointer to the Internet Draft and containing section number) to IANA at iana@iana.org [11]. Upon receipt of a URI scheme registration request, IANA: 1. Checks the submission for completeness; if sections are missing or citations are not correct, IANA rejects the registration request. 2. Checks the current registry for a 'permanent' entry of that name; if such a registry exists, IANA rejects the registration request. 3. Adds the registration to the 'provisional' registry. Registration of a 'permanent' URI scheme happens through the approval of publication of an RFC that contains instructions for registration in the 'IANA considerations' section of the document. The IETF review should consider whether the URI scheme meets the guidelines in Section 2; in addition, permanent registration when there are multiple provisional registrations for the same scheme name should be avoided. In some cases, a new 'permanent' URI scheme will upgrade a previous 'provisional' registration; IANA should remove the corresponding entry from the provisional registry, unless the IANA considerations section specifies otherwise. 3.4 Change Control Permanent URI name schemes are "owned" by the IETF itself and may be changed, as needed, by updating the RFC that describes them. Schemes described by Standards Track RFC may be replaced with new Standards Track RFCs. Informational RFCs may be replaced by new Informational RFCs or Standards Track RFCs. Provisional URL schemes that are undocumented may be changed by their owner at any time without notifying the IETF. Provisional URL schemes that have been documented by an Informational RFC, may be changed at any time by the owner. However, an updated Informational RFC that details the changes made, must be submitted to the IESG. The owner of a provisional URL scheme and documented by an Hansen, et al. Expires June 8, 2005 [Page 9]
Internet-Draft New URI Schemes December 2004 Informational RFC may pass responsibility for the registration to another person or agency by informing the IESG. The IESG may reassign responsibility for a provisional URL scheme that had been documented by an Informational RFC. The most common case of this will be to enable changes to be made to schemes where the scheme name is privately owned, and the owner of the scheme name has died, moved out of contact or is otherwise unable to make changes that are important to the community. A URL scheme that has been registered by a third party may be reassigned to the proper owners of that scheme name. The IESG may reclassify a URI scheme as "historic", if it determines that the scheme is no longer in use. (This may be done in conjunction with marking a protocol as "historic".) IANA may remove any provisional URI scheme entry whose corresponding specification document is no longer available (e.g., the Internet-draft expired, or the URL citation is no longer resolvable). Anyone may notify IANA of any such cases by sending an email to iana@iana.org [12]. Before removing an entry for this reason, IANA SHOULD contact the registered Author/Change controller to determine whether a replacement for the specification document is available. 3.5 New URI Scheme Registration Template The following issues should be addressed when documenting a new URI scheme: URI scheme name. Status. This will be one of 'permanent', 'provisional' or 'historic'. URI scheme syntax. This should be expressed in a clear and concise manner. The use of ABNF is encouraged. Please refer to Section 2 for guidance on designing and explaining your scheme's syntax. Character encoding considerations. It is important to identify what your scheme supports in this regard. It is obvious that for interoperability, it is best if there is a means to support character sets beyond USASCII, but, especially for private schemes, this may not be the case. Intended usage. What sort of resource is being identified? If this is not a 'resource' type of URI (e.g. mailto:), explain the action that should be initiated by the consumer of the URI. If there is a MIME type associated with this resource, please identify it. Hansen, et al. Expires June 8, 2005 [Page 10]
Internet-Draft New URI Schemes December 2004 Applications and/or protocols that use this URI scheme name. Including references to documentation that defines the applications and/or protocols cited is especially useful. Interoperability considerations. If you are aware of any details regarding your scheme that might impact interoperability, please identify them here. For example: proprietary or uncommon encoding method; inability to support multibyte character sets; incompatibility with types or versions of any underlying protocol (if the scheme is tunneled over another protocol). Security considerations. Relevant publications. For the case of provisional URI scheme entries, this may be the URL of a document more completely describing the scheme. Contact. Person & email address to contact for further information. Author/Change controller. Application/protocol. Applications and/or protocols that use this URI scheme name. 4. IANA Considerations This document updates the Uniform Resource Identifier (URI) Schemes registration table. 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. All existing URI name schemes in the existing table should be given the status of 'permanent'. This document updates the procedures to be followed by IANA when receiving a URI scheme name registration template. 5. Security Considerations New URI schemes are expected to address all security considerations in their definitions. Information that creates or updates a registration needs to be authenticated. 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. 6. Acknowledgements Some of the text for the provisional registration status is based on Hansen, et al. Expires June 8, 2005 [Page 11]
Internet-Draft New URI Schemes December 2004 [9]. 7. References 7.1 Normative References [1] Moats, R., "URN Syntax", RFC 2141, May 1997. [2] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999. [3] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999. [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", October 2004. 7.2 Informative References [7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [8] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [9] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. URIs [10] <mailto:uri@w3.org> [11] <mailto:iana@iana.org> [12] <mailto:iana@iana.org> Hansen, et al. Expires June 8, 2005 [Page 12]
Internet-Draft New URI Schemes December 2004 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 Suite 200 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 Hansen, et al. Expires June 8, 2005 [Page 13]
Internet-Draft New URI Schemes December 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hansen, et al. Expires June 8, 2005 [Page 14]
