INTERNET-DRAFT Rich Petke
<draft-ietf-urlreg-procedures-00.txt><draft-ietf-urlreg-procedures-01.txt> CompuServe Network Services March 13,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 learnview the current statusentire list of any Internet-Draft,current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.netftp.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), nic.nordu.net (Europe),or ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).Coast). Distribution of this memo is unlimited. This Internet Draft expires September 13,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. RFC [URL-GUIDELINES] provides guidelines fordefined, however, new schemes may need to be defined in the definition offuture in order to accommodate new URL schemes, for consideration by those who are defining and registering or evaluating those definitions. 2.0 Scope The URL schemeInternet protocols and/or procedures. A registration process is restrictedneeded to ensure that the registration of new URL scheme names. 3.0 Classificationsnames of Scheme Names Notall URL scheme namessuch new schemes are created equal. This section definesguaranteed not to collide. Further, the various classifications forregistration process ensures that URL scheme names. Section 4 of thisschemes intended for wide spread, public use are developed in an orderly, well-specified, and public manner. This document defines theregistration procedures to be followed to registerwhich use the Internet Assigned Numbers Authority (IANA) as a central registry for such URL scheme name. 3.1 Class 1 - Common Names Ifnames and the name proposedIETF 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 common word, meaningfulfashion appropriate to a large and/or wide population, thenthe tree involved. The URL scheme name is considered a Class 1 name. Examples of such names include: Telephone Phone Fax TV Weather Music 3.2 Class 2 - Acronyms Short acronyms for technical terms which do not themselves create common words (i.e.then registered if the acronymproposal is not a Class 1 name), are considered to be Class 2 scheme names. Examples of such names include: HTTP FTP NNTP TELNET WAIS 3.3 Class 3 - Vanity Namesacceptable. The following sections describe the requirements and Registered Trade Names Scheme names that echo registered trade namesprocedures used for each of the different registration trees. 2.1. Registration Trees and vanity names are consideredURL Schemes In order to be Class 3 scheme names. Examplesincrease the efficiency and flexibility of such names include: AOL RealAudio STTNG 3.4 Class 4 - Private Schemes Scheme names based on IANA assigned domainthe registration process, three different formats of URL scheme names and matchingmay be registered. The registration requirements for each format differ allowing the syntax specified below are consideredregistration procedure to accommodate the different natural requirements for URL schemes. For example, a scheme that will be Class 4recommended for wide support and implementation by the Internet Community requires a more complete review than a scheme names.that is used with resources associated with proprietary software. The syntax of a class 4following subsections define registration "trees" and the associated URL scheme name is: "NOREG+" <domain> [ "+" <extension>] ":" where - <domain> is defined in [STD13], section 3.5. <extension> is optional and may contain any legalformats 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 charactersregistration 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 defineddetailed 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]. ExamplesURL 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 valid Class 4the security issues inherent in the new URL scheme names include: noreg+compuserve.net+rpa: noreg+nt.microsoft.com: 4.0 Registration Procedures (tois 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 followed byas accurate as possible regardless of registration tree. In particular, a requestor) To registerstatement 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 newURL scheme name: 1. Determine whichname, 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 class (asname" mechanism described in section 3) best describessubsequent 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 proposedURL scheme name. Ifnames registration tree itself. Other than in the proposedIETF tree, the registration of a URL scheme name does not appear to clearly belong to any one classification, requestimply endorsement, approval, or recommendation by IANA or IETF or even certification that the IESG to classifyspecification 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 name. 2. Completenames. 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 namenames. 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 form foundin appendix Athe IETF tree, the normal IETF processes should be followed, treating posting of this document. 3.an internet-draft and announcement on the ietf-types list (as described in the next subsection) as a first step. For Class 4registrations in the vendor or personal tree, the initial review step described below may be omitted and the URL scheme names ONLY, forwardname may be registered directly by submitting the completed formtemplate and an explanation directly to IANA directly. 4. For all other(at email@example.com). However, authors of vendor or personal URL scheme name classes, forwardspecifications are encouraged to seek community review and comment whenever that is feasible. 2.3.1. Present the completed formURL Scheme Name to the IESG. WithCommunity for Review Send a proposed URL scheme name registration to the "firstname.lastname@example.org" mailing list for a two week review period. This mailing list has been established for the exceptionpurpose of Class 4reviewing proposed URL schemes. URL scheme names, whichnames proposed to this mailing list are easily recognizable,not formally registered and should not be used until the IESG hasregistration procedure is complete. The intent of the rightpublic posting is to reclassifysolicit comments and feedback on the choice of scheme name, the syntax and semantics of the scheme, and a review of any proposedinteroperability 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 that have been incorrectly classified. Theregistered in the IETF tree must be submitted to the IESG should process applicationsfor approval. 2.3.3. IANA Registration Provided that the registration of newURL scheme name meets the requirements for URL scheme names in a timely manner. It may delay theand has obtained approval of any application for just cause, such as lack of consensus withinthat is necessary, the author may submit the IETF (when a Class 1 scheme nameregistration is requested), or multiple parties attemptingrequest to the IANA, which will register the same or similarscheme names. 5.0 Registration Procedures (to be followed byname and make the IESG) 5.1 Class 1 Procedures (Common Names) Registering a Class 1URL scheme name requiresregistration available to the consensuscommunity. 2.4. Comments on URL Scheme Name Registrations Comments on registered URL scheme names may be submitted by members of the IETF. The IESGcommunity to IANA. These comments will seek inputbe passed on to the "owner" of the prospective newURL scheme name and will either approve or reject the registration on behalfif possible. Submitters of the IETF. The IESGcomments may require the proposed scheme torequest that their comment be documented in an RFC (standards track, informational, or BCP). Ifattached to the IESGURL scheme name registration itself, and if IANA approves of this the registration, itcomment will forwardbe made accessible in conjunction with the scheme name registration form to IANA for recording. 5.2 Class 2 Procedures (Acronyms) Registering a Class 2itself. 2.5. Location of Registered URL Scheme Name List URL scheme name requires only the consensus of the IESG. The IESG must requireregistrations will be posted in the proposedanonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/" and all registered URL scheme tonames will be documentedlisted in anthe periodically issued "Assigned Numbers" RFC or other permanent[currently STD 2, RFC 1700]. The scheme syntax and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. If the IESG approves the registrationsemantics description and other supporting documentation,material may also be published as an Informational RFC by sending it will forwardto "email@example.com" (please follow the registration forminstructions to RFC authors [RFC-1543]). 2.6. IANA for recording. 5.3 Class 3Procedures (Vanity Names and Registered Trade Names) Class 3for Registering URL scheme names are approved on a first come, first served basis.The IESGIANA will verify that the requestedonly register URL scheme name is indeednames in the IETF tree in response to a class 3 name,communication from the IESG stating that a given registration has been approved. Vendor and personal types will be registered by the party requestingIANA 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 indeedhas reasonable rightsbeen published by IANA, the author may request a change to registerits definition. The descriptions of the scheme name, and that sufficiently stable "pointdifferent registration trees above designate the "owners" of contact" information has been supplied ineach type of registration. The change request follows the same procedure as the registration form. After verification,request: (1) Publish the IESG will forwardrevised template on the application to IANAietf-types list. (2) Leave at least two weeks for recording. The IESG may require the scheme tocomments. (3) Publish using IANA after formal review if required. Changes should be documentedrequested only when there are serious omission or errors in an RFC. 6.0 Registration Procedures (tothe published specification. When review is required, a change request may be followed by IANA) 6.1 Procedures for Class 1, 2, and 3 URL Scheme Names IANA will only accept completeddenied if it renders entities that were valid under the previous definition invalid under the new definition. The owner of a URL scheme nameregistration forms which have been approvedmay 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 recording. 6.2 Class 4 Procedures (Private Schemes) Upon receipt ofa completedURL scheme namename. The most common case of this will be to enable changes to be made to schemes where the author of the registration form, IANA shall: 1. Verifyhas died, moved out of contact or is otherwise unable to make changes that are important to the proposedcommunity. URL scheme name conforms to the syntax specifiedregistrations may not be deleted; URL scheme names which are no longer believed appropriate for Class 4use can be declared OBSOLETE by a change to their "intended use" field; such URL scheme names will be clearly marked in section 3.4 of this document. 2. Verify that the requestor is affiliated with the owner of the DNS name specified in the registration form. 3. Verify thatthe "pointlists published by IANA. 2.8. Registration Template To: firstname.lastname@example.org Subject: Registration of contact"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 is sufficiently stable. 4. Recordthat the registration. 7.0author 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 schemes.scheme. Delegations of a name space should only be assigned to someone with adequate security. 8.04.0 References [STD 13] [RFC-URI-SYNTAX] [RFC-URL-GUIDELINES] 9.0RFC [URI-SYNTAX] RFC [URL-GUIDELINES] 5.0 Author's Address Rich Petke CompuServe Network Services Inc. (WorldCom)CNS/WorldCom 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000430 USA Phone: 614-723-4157 Email:+1 614 723 4157 Fax: +1 614 723 1333 EMail: email@example.com Appendix A -- Grandfathered URL Scheme Name Registration Form URL Scheme Name to be Registered (case insensitive): URL Scheme Name Class (1, 2, 3, 4, or unknown): Person Requesting Registration (name, title, affiliation, postal address, telephone numbers, email address): PointNames A number of Contact for this Registration (name, title, affiliation, postal address, telephone numbers, email address): Published specification(s) for this Scheme Name (I-Ds, RFCs, etc.): Other Relevant Information Regarding this Application: For Class 4URL scheme names ONLY, sendnames, in use prior to 1998, would, if registered under the guidelines in this form to: firstname.lastname@example.org For all other URL scheme name classes, including URL scheme namesdocument, be placed into either the vendor or personal trees. Re-registration of an unknown class, sendthose types to reflect the appropriate trees is encouraged, but not required. Ownership and change control principles outlined in this form to: email@example.com apply to those types as if they had been registered in the trees described above.