INTERNET-DRAFT Rich Petke CompuServe Network Services April 30, 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 view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. This Internet Draft expires October 31, 1998. Abstract This document defines the process by which new URL schemes 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 [URI-SYNTAX] 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 registration procedures which use the Internet Assigned Numbers Authority (IANA) as a central registry for such URL scheme names and the IETF RFC mechanism for scheme review, where appropriate. 2.0 URL Scheme Name Registration Registration of a new URL scheme name starts with the construction of a registration proposal. Registration may occur in several different registration trees, which have different requirements as discussed below. In general, the new registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The URL scheme name is then registered if the proposal is acceptable. The following sections describe the requirements and procedures used for each of the different registration trees. 2.1. Registration Trees and URL Schemes In order to increase the efficiency and flexibility of the registration process, three different formats of URL scheme names may be registered. The registration requirements for each format differ allowing the 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 that is used with resources associated with proprietary software. The following subsections define registration "trees" and the associated URL scheme name formats available at this time. 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.1.1. IETF Tree The IETF tree is intended for URL schemes of general interest to the Internet Community. Registration in the IETF tree requires approval by the IESG and publication of the URL scheme syntax and semantics as some form of RFC, usually a standards track RFC. URL scheme names in the IETF tree are normally denoted by names that are not explicitly faceted, i.e., do not contain period (".") characters. The "owner" of a URL scheme name registration 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. standards track) as required for the initial registration. 2.1.2. Vendor Tree The vendor tree is used for URL schemes associated with commercially available products. "Vendor" or "producer" are construed as equivalent and very broadly in this context. A registration may be placed in the vendor tree by anyone who needs to identify a scheme for (1) specifying the location of a resource available via the Internet (2) which may be accessed using a protocol for which there is not currently a URL scheme registered. The registration formally belongs to the vendor or organization registering the scheme name. Changes to the specification will be made at their request, as discussed in subsequent sections. Registrations in the vendor tree will be distinguished by the leading facet "vnd.". That must be followed by an IANA-approved designation of the producer's name, which is then followed by a URL scheme name or product designation (e.g., vnd.bigcompany.funnypictures). While public exposure and review of URL scheme names to be registered in the vendor tree is not required, using the ietf-types list for review is strongly encouraged to improve the quality of those specifications. Registrations in the vendor tree may be submitted directly to the IANA. 2.1.3. Personal or Vanity Tree Registrations for URL schemes created experimentally or as part of products that are not distributed commercially may be registered in the personal or vanity tree. The registrations are distinguished by the leading facet "prs.". The owner of "personal" registrations and associated specifications is the person or entity making the registration, or one to whom responsibility has been transferred as described below. While public exposure and review of URL scheme names to be registered in the personal tree is not required, using the ietf-types list for review is strongly encouraged to improve the quality of those specifications. Registrations in the personal tree may be submitted directly to the IANA. 2.1.4. Additional Registration Trees From time to time and as required by the community, the IANA may, with the advice and consent of the IESG, create new top-level registration trees. It is explicitly assumed that these trees may be created for external registration and management by well-known permanent bodies, such as scientific societies, for URL schemes specific to the sciences they cover. In general, the quality of review of specifications for one of these additional registration trees is expected to be equivalent to that which IETF would give to registrations in its own tree. Establishment of these new trees will be announced through RFC publication approved by the IESG. 2.2. Registration Requirements URL scheme name registration proposals are all expected to conform to various requirements laid out in the following sections. Note that requirement specifics sometimes vary depending on the registration tree, again as detailed in the following sections. 2.2.1. Scheme Names All new URL scheme names, regardless of registration tree, MUST conform to the syntax specified for scheme names in RFC [URI-SYNTAX]. 2.2.2. URL Syntax All new URL schemes registered in the IETF tree, MUST conform to the generic syntax for URLs as specified in RFC [URI-SYNTAX]. URL schemes registered in the vendor and personal trees are encouraged to conform to the generic syntax but are not required to do so in order to be registered. All new URL schemes should follow the Guidelines for URL Schemes, set forth in RFC [URL-GUIDELINES]. 2.2.3. Security Requirements An analysis of the security issues inherent in the new URL scheme is required for all registrations in the IETF tree. (This is in accordance with the basic requirements for all IETF protocols.) A similar analysis for schemes registered in the vendor or personal trees is encouraged but not required. However, regardless of what security analysis has or has not been done, all descriptions of security issues must be as accurate as possible regardless of registration tree. 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 registered in any tree be secure or completely free from risks. Nevertheless, all known security risks must be identified in the registration of a URL scheme name, again regardless of registration tree. The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular may be extended by use of the "comments on URL scheme name" mechanism described in subsequent sections. 2.2.4. Publication Requirements Proposals for URL schemes registered in the IETF tree must be published as RFCs. RFC publication of vendor and personal URL schemes is encouraged but not required. In all cases IANA will retain copies of all URL scheme proposals and "publish" them as part of the URL scheme names registration tree itself. Other than in the IETF tree, the registration of a URL scheme name does not imply endorsement, approval, or recommendation by IANA or IETF or even certification that the specification is adequate. To become Internet Standards, protocol, data objects, or whatever must go through the IETF standards process. This is too difficult and too lengthy a process for the convenient registration of URL scheme names. The IETF tree exists for URL schemes that do require a substantive review and approval process with the vendor and personal trees exist for those that do not. 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. As discussed above, registration of a top-level type requires standards-track processing and, hence, RFC publication. 2.3. Registration Procedure The following procedure has been implemented by the IANA for review and approval of new URL scheme names. This is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay. For registration in the IETF tree, the normal IETF processes should be followed, treating posting of an internet-draft and announcement on the ietf-types list (as described in the next subsection) as a first step. For registrations in the vendor or personal tree, the initial review step described below may be omitted and the URL scheme name may be registered directly by submitting the template and an explanation directly to IANA (at iana@iana.org). However, authors of vendor or personal URL scheme specifications are encouraged to seek community review and comment whenever that is feasible. 2.3.1. Present the URL Scheme Name to the Community for Review Send a proposed URL scheme name registration to the "ietf-types@iana.org" mailing list for a two week review period. This mailing list has been established for the purpose of reviewing proposed URL schemes. URL scheme names proposed to this mailing list are not formally registered and should not be used until the registration procedure is complete. The intent of the public posting is to solicit comments and feedback on the choice of scheme name, the syntax and semantics of the scheme, and a review of any interoperability or security considerations. The submitter may submit a revised registration, or withdraw the registration completely, at any time. 2.3.2. IESG Approval URL scheme names registered in the IETF tree must be submitted to the IESG for approval. 2.3.3. IANA Registration Provided that the URL scheme name meets the requirements for URL scheme names and has obtained approval that is necessary, the author may submit the registration request to the IANA, which will register the scheme name and make the URL scheme name registration available to the community. 2.4. Comments on URL Scheme Name Registrations Comments on registered URL scheme names may be submitted by members of the community to IANA. These comments will be passed on to the "owner" of the URL scheme name if possible. Submitters of comments may request that their comment be attached to the URL scheme name registration itself, and if IANA approves of this the comment will be made accessible in conjunction with the scheme name registration itself. 2.5. Location of Registered URL Scheme Name List URL scheme name registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/" and all registered URL scheme names will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The scheme syntax and semantics description and other supporting material may also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC-1543]). 2.6. IANA Procedures for Registering URL scheme names The IANA will only register URL scheme names in the IETF tree in response to a communication from the IESG stating that a given registration has been approved. Vendor and personal types will be registered by the IANA automatically and without any formal review as long as the following minimal conditions are met: o Security considerations o TBD 2.7. Change Control Once a URL scheme name has been published by IANA, the author may request a change to its definition. The descriptions of the different registration trees above designate the "owners" of each type of registration. The change request follows the same procedure as the registration request: (1) Publish the revised template on the ietf-types list. (2) Leave at least two weeks for comments. (3) Publish using IANA after formal review if required. Changes should be requested only when there are serious omission or errors in the published specification. When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition. The owner of a URL scheme registration may pass responsibility for the registration to another person or agency by informing IANA and the ietf-types list; this can be done without discussion or review. The IESG may reassign responsibility for a URL scheme name. The most common case of this will be to enable changes to be made to schemes where the author of the registration has died, moved out of contact or is otherwise unable to make changes that are important to the community. URL scheme name registrations may not be deleted; URL scheme names which are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such URL scheme names will be clearly marked in the lists published by IANA. 2.8. Registration Template To: ietf-types@iana.org Subject: Registration of URL Scheme Name XXX URL Scheme Name: Security considerations: Interoperability considerations: Published specification: Applications which use this URL scheme name: Additional information: Person & email address to contact for further information: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author/Change controller: (Any other information that the author deems interesting may be added below this line.) 3.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 registrations, so that users are not misled as to the true security properties of a registered URL scheme. Delegations of a name space should only be assigned to someone with adequate security. 4.0 References RFC [URI-SYNTAX] RFC [URL-GUIDELINES] 5.0 Author's Address Rich Petke CNS/WorldCom 5000 Britton Road P. O. Box 5000 Hilliard, OH 430 USA Phone: +1 614 723 4157 Fax: +1 614 723 1333 EMail: rpetke@compuserve.net Appendix A -- Grandfathered URL Scheme Names A number of URL scheme names, in use prior to 1998, would, if registered under the guidelines in this document, be placed into either the vendor or personal trees. Re-registration of those types to reflect the appropriate trees 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 trees described above.