INTERNET-DRAFT R. Petke MCIWORLDCOM Advanced Networks November 1, 1998 Registration Procedures for URL Scheme Names Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. This Internet-Draft expires April 30, 1999. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document defines the process by which new URL scheme names are registered. 1.0 Introduction A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. RFC 2396 [1] defines the general syntax and semantics of URIs, and, by inclusion, URLs. URLs are designated by including a ":" and then a "". 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 [URL-GUIDELINES], Guidelines for URL Schemes [2], provides guidelines for the creation of new URL schemes. The primary focus of this document is on the portion of new URL schemes, referred to as the "scheme name" throughout this document. 2.0 URL Scheme Name Registration Trees 2.1 General In order to increase the efficiency and flexibility of the URL scheme name registration process, two different registration "trees" have been created. The registration requirements and specific registration procedures for each tree differ, allowing the overall registration procedure to accommodate the different natural requirements for URL schemes. For example, a scheme that will be recommended for wide support and implementation by the Internet community requires a more complete review than a scheme intended to be used for resources associated with proprietary software. The first step in registering a new URL scheme name is to determine which registration tree the scheme should be registered in. Determination of the proper registration tree is based on the intended use for the new scheme and the desired syntax for the scheme name. Note that some URL schemes defined prior to this document do not conform to the naming conventions described below. See Appendix A for a discussion of those schemes. 2.2 The IETF Tree The IETF tree is intended for URL schemes of general interest to the Internet community. The tree exists for URL schemes that require a substantive review and approval process. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, URL schemes that have proven particularly useful in those contexts. 2.3 The OID Tree The OID tree is intended for URL schemes which will be used in a proprietary manner. The trees exists to provide a mechanism for ensuring that scheme names do not collide. The syntax and semantics of URL schemes created in the OID tree do not have to be reviewed or publicly disclosed. Creating a URL scheme name in the OID tree does not imply endorsement, approval, or recommendation by the IETF or even certification that the specification is adequate, even if the scheme was published as an IETF Internet-Draft and/or reviewed by IETF participants. To become Internet Standards, protocols, data objects, or whatever must go through the IETF standards process and registration in the IETF tree. 2.4 Additional Registration Trees From time to time and as required by the community, the IESG may create new top-level registration trees. 3.0 Requirements for Scheme Name Registration 3.1 General Requirements All new URL scheme NAMES, regardless of registration tree, MUST conform to the syntax specified in RFC 2396 for scheme NAMES. 3.2 The IETF Tree Registration in the IETF tree requires publication of the URL scheme syntax and semantics in either an Informational or Standards Track RFC. In addition to having a conforming scheme NAME (see section 3.1), all new URL schemes registered in the IETF tree, MUST conform to the generic syntax for URLs as specified in RFC 2396. 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.) There is absolutely no requirement that all URL schemes registered in the IETF tree be secure or completely free from risks. Nevertheless, all known security risks must be identified. 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. 3.3 The OID Tree While public exposure and review of a URL scheme created in the OID tree is not required, using the IETF Internet-Draft mechanism for peer review is strongly encouraged to improve the quality of the specification. RFC publication of OID tree URL schemes is encouraged but not required. Material may be published as an Informational RFC by sending it to the RFC Editor (please follow the instructions to RFC authors, RFC 2223 [3]). URL schemes created in the OID tree are encouraged to conform to the generic URL syntax, RFC 2396, but are not required to do so. All new URL schemes SHOULD follow the Guidelines for URL Schemes, set forth in RFC [URL-GUIDELINES] [2]. While not required, 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". There is absolutely no requirement that URL schemes created in the OID tree be secure or completely free from risks. Nevertheless, all known security risks SHOULD be identified. The registration of a URL scheme created in the OID tree formally belongs to the entity to which the OID is assigned. Changes to the specification of an OID tree URL scheme which is documented by an Informational RFC shall only be accepted from the owner of the OID or with the permission of the owner of the OID. The syntax of URL scheme names for schemes created in the OID tree is simply the text string "OID-" followed by the numeric OID including any embedded hyphens. URL scheme names are case insensitive so the letters in the text string "OID-" need not be capitalized. No variations on this formula are permitted. Examples of valid URL scheme names in the OID tree: OID-2-16-840-1-113779-2-1: Oid-2-16-840-1-113779-2-1-100: OiD-2-16-840-1-113779-3: oid-2-16-840-1-113779-123: 4.0 Registration Procedures 4.1 The IETF Tree The first step in registering a new URL scheme in the IETF tree is to publish an IETF Internet-Draft detailing the syntax and semantics of the proposed scheme. The draft must, minimally, address all of the items covered by the template provided in 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. 4.2 The OID Tree Registration of URL schemes created in the OID tree is automatic because the scheme name is based on a previously registered entity, an OID. There is no requirement to publish any documentation for the URL scheme, however, doing so may be advantageous and is encouraged. The recommended form for documenting a URL scheme created in the OID tree is via an Informational RFC. The RFC should address all of the items covered by the template provided in section 6 of this document. 5.0 Change Control 5.1 Schemes in the IETF Tree URL schemes created in the IETF tree 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 but be replaced with new Standards Track RFCs. Informational RFCs may be replaced by new Informational RFCs or Standards Track RFCs. 5.2 Schemes in the OID Tree Undocumented URL schemes created in the OID tree may be changed by their owner at any time without notifying the IETF. URL schemes created in the OID tree that have been documented by an Informational RFC, may be changed at any time by the owner, however, an updated Informational RFC which details the changes made, must be submitted to the IESG. The owner of a URL scheme registered in the OID tree and documented by an Informational RFC may pass responsibility for the registration to another person or agency by informing the IESG. The IESG may reassign responsibility for a URL scheme registered in the OID tree and documented by an Informational RFC. The most common case of this will be to enable changes to be made to schemes where the owner of the OID has died, moved out of contact or is otherwise unable to make changes that are important to the community. The IESG may reclassify a URL scheme created in the OID tree and documented via an Informational RFC as "historic" if it determines that the scheme is no longer in use. 6.0 Registration Template The following issues should be addressed when documenting a new URL scheme: URL scheme name. URL scheme syntax. This should be expressed in a clear and concise manner. The use of ABNF is encouraged. Please refer to RFC [URL-GUIDELINES] 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. 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. 7.0 Security Considerations 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 URL 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 URL scheme. 8.0 References [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998 [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998 [3] Postel, J., Reynolds, J., "Instructions to RFC Authors", RFC 2223, October 1997. 9.0 Author's Address Rich Petke MCIWORLDCOM Advanced Networks 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 USA Phone: +1 614 723 4157 Fax: +1 614 723 8407 EMail: rpetke@wcom.net Appendix A -- Grandfathered URL Scheme Names A number of URL scheme names, in use prior to 1998, would, if registered under the procedures specified in this document, be placed into the OID tree. Re-registration of those types to reflect the appropriate tree or documentation of the schemes in an Informational RFC is encouraged, but not required. Ownership and change control principles outlined in this document apply to those types as if they had been registered in the OID tree. ABOUT: (No information available at this time.) AOL: (No information available at this time.)