Network Working Group R. Petke Request for Comments: 2717 UUNET Technologies BCP: 35 I. King Category: Best Current Practice Microsoft Corporation November 1999 Registration Procedures for URL Scheme Names Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.
AbstractThis document defines the process by which new URL scheme names are registered. RFC 2396  defines the general syntax and semantics of URIs, and, by inclusion, URLs. URLs are designated by including a "<scheme>:" and then a "<scheme-specific-part>". Many URL schemes are already defined, however, new schemes may need to be defined in the future in order to accommodate new Internet protocols and/or procedures. A registration process is needed to ensure that the names of all such new schemes are guaranteed not to collide. Further, the registration process ensures that URL schemes intended for wide spread, public use are developed in an orderly, well-specified, and public manner. This document defines the registration procedures to be followed when new URL schemes are created. A separate document, RFC 2718, Guidelines for URL Schemes , provides guidelines for the creation of new URL schemes. The primary focus of this document is on the <scheme> portion of new URL schemes, referred to as the "scheme name" throughout this document.
RFC 2396. RFC 2718, such as "demonstrated utility" within the Internet Architecture; the IESG shall have broad discretion in determining whether an Informational RFC is suitable in any given case, and may either recommend changes to such document prior to publication, or reject it for publication. An Informational RFC purporting to describe a URL scheme shall not be published without IESG approval. This is a departure from practice for Informational RFCs as set forth in RFC 2026, for the purpose of ensuring that the registration of URL schemes shall serve the best interests of the Internet community. The NAMES of schemes registered in the IETF tree MUST NOT contain the dash (also known as the hyphen and minus sign) character ('-') USASCII value 2Dh. Use of this character can cause confusion with schemes registered in alternative trees (see section 3.3). An analysis of the security issues inherent in the new URL scheme is REQUIRED. (This is in accordance with the basic requirements for all IETF protocols.) URL schemes registered in the IETF tree should not introduce additional security risks into the Internet Architecture. For example, URLs should not embed information which should remain confidential, such as passwords, nor should new schemes subvert the security of existing schemes or protocols (i.e. by layering or tunneling).
The "owner" of a URL scheme name registered in the IETF tree is assumed to be the IETF itself. Modification or alteration of the specification requires the same level of processing (e.g. Informational or Standards Track RFC) as used for the initial registration. Schemes originally defined via an Informational RFC may, however, be replaced with Standards Track documents. RFC 2223 ). The defining document for an alternative tree may require public exposure and/or review for schemes defined in that tree via a mechanism other than the IETF Internet-Draft mechanism. URL schemes created in an alternative tree must conform to the generic URL syntax, RFC 2396. The tree's defining document may set forth additional syntax and semantics requirements above and beyond those specified in RFC 2396. All new URL schemes SHOULD follow the Guidelines for URL Schemes, set forth in RFC 2718 . An analysis of the security issues inherent in the new URL 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 absolutely no requirement that URL schemes created in an alternative tree be secure or completely free from risks. Nevertheless, the tree's defining document must set forth the standard for security considerations, and in any event all known security risks SHOULD be identified. Change control must be defined for a new tree. Change control may be vested in the IETF, or in an individual, group or other entity. The change control standard for the tree must be approved by the IESG.
The syntax for alternative trees shall be as follows: each tree will be identified by a unique prefix, which must be established in the same fashion as a URL scheme name in the IETF tree, except that the prefix must be defined by a Standards Track document. Scheme names in the new tree are then constructed by prepending the prefix to an identifier unique to each scheme in that tree, as prescribed by that tree's identifying document: <prefix>'-'<tree-specific identifier> For instance, the "foo" tree would allow creation of scheme names of the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes an arbitrary USASCII string following the tree's unique prefix. section 6 of this document. After all issues raised during a review period of no less than 4 weeks have been addressed, submit the draft to the IESG for review. The IESG will review the proposed new scheme and either refer the scheme to a working group (existing or new) or directly present the scheme to the IESG for a last call. In the former case, the working group is responsible for submitting a final version of the draft to the IESG for approval at such time as it has received adequate review and deliberation.
will not accept it. (For instance, if an IANA registration mechanism is proposed, IESG might reject the tree if its mechanism would create undue liability on the part of IANA.) While the template in section 6 of this document is intended to apply to URL scheme names in the IETF tree, it is also offered as a guideline for those documenting alternative trees.
RFC 2718 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 URL (e.g. mailto:), explain the action that should be initiated by the consumer of the URL. If there is a MIME type associated with this resource, please identify it. Applications and/or protocols which use this URL scheme name. Including references to documentation which defines the applications and/or protocols cited is especially useful. Interoperability considerations. If you are aware of any details regarding your scheme which 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 underlying protocol (if scheme is tunneled over another protocol). Security considerations. Relevant publications. Person & email address to contact for further information. Author/Change controller. Applications and/or protocols which use this URL scheme name.
 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.  Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.