INTERNET-DRAFT Rich Petke <draft-ietf-urlreg-procedures-00.txt> CompuServe Network Services March 13, 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 ds.internic.net (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 September 13, 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 for the definition of new URL schemes, for consideration by those who are defining and registering or evaluating those definitions. 2.0 Scope The URL scheme registration process is restricted to the registration of new URL scheme names. 3.0 Classifications of Scheme Names Not all URL scheme names are created equal. This section defines the various classifications for URL scheme names. Section 4 of this document defines the registration procedures to be followed to register a scheme name. 3.1 Class 1 - Common Names If the name proposed for a new URL scheme is a common word, meaningful to a large and/or wide population, then the 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. the acronym 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 Names and Registered Trade Names Scheme names that echo registered trade names and vanity names are considered to be Class 3 scheme names. Examples of such names include: AOL RealAudio STTNG 3.4 Class 4 - Private Schemes Scheme names based on IANA assigned domain names and matching the syntax specified below are considered to be Class 4 scheme names. The syntax of a class 4 URL scheme name is: "NOREG+" <domain> [ "+" <extension>] ":" where - <domain> is defined in [STD13], section 3.5. <extension> is optional and may contain any legal scheme name characters as defined in RFC [URI-SYNTAX]. Examples of valid Class 4 URL scheme names include: noreg+compuserve.net+rpa: noreg+nt.microsoft.com: 4.0 Registration Procedures (to be followed by a requestor) To register a new URL scheme name: 1. Determine which scheme name class (as described in section 3) best describes the proposed URL scheme name. If the proposed scheme name does not appear to clearly belong to any one classification, request the IESG to classify the scheme name. 2. Complete the URL scheme name registration form found in appendix A of this document. 3. For Class 4 URL scheme names ONLY, forward the completed form to IANA directly. 4. For all other URL scheme name classes, forward the completed form to the IESG. With the exception of Class 4 URL scheme names, which are easily recognizable, the IESG has the right to reclassify any proposed URL scheme names that have been incorrectly classified. The IESG should process applications for the registration of new URL scheme names in a timely manner. It may delay the approval of any application for just cause, such as lack of consensus within the IETF (when a Class 1 scheme name registration is requested), or multiple parties attempting to register the same or similar scheme names. 5.0 Registration Procedures (to be followed by the IESG) 5.1 Class 1 Procedures (Common Names) Registering a Class 1 URL scheme name requires the consensus of the IETF. The IESG will seek input on the prospective new URL scheme name and will either approve or reject the registration on behalf of the IETF. The IESG may require the proposed scheme to be documented in an RFC (standards track, informational, or BCP). If the IESG approves the registration, it will forward the registration form to IANA for recording. 5.2 Class 2 Procedures (Acronyms) Registering a Class 2 URL scheme name requires only the consensus of the IESG. The IESG must require the proposed scheme to be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. If the IESG approves the registration and supporting documentation, it will forward the registration form to IANA for recording. 5.3 Class 3 Procedures (Vanity Names and Registered Trade Names) Class 3 URL scheme names are approved on a first come, first served basis. The IESG will verify that the requested URL scheme name is indeed a class 3 name, that the party requesting the scheme name indeed has reasonable rights to register the scheme name, and that sufficiently stable "point of contact" information has been supplied in the registration form. After verification, the IESG will forward the application to IANA for recording. The IESG may require the scheme to be documented in an RFC. 6.0 Registration Procedures (to be followed by IANA) 6.1 Procedures for Class 1, 2, and 3 URL Scheme Names IANA will only accept completed URL scheme name registration forms which have been approved by the IESG for recording. 6.2 Class 4 Procedures (Private Schemes) Upon receipt of a completed URL scheme name registration form, IANA shall: 1. Verify that the proposed URL scheme name conforms to the syntax specified for Class 4 URL scheme names 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 that the "point of contact" information is sufficiently stable. 4. Record the registration. 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 registrations, so that users are not misled as to the true security properties of a registered URL schemes. Delegations of a name space should only be assigned to someone with adequate security. 8.0 References [STD 13] [RFC-URI-SYNTAX] [RFC-URL-GUIDELINES] 9.0 Author's Address Rich Petke CompuServe Network Services Inc. (WorldCom) 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 Phone: 614-723-4157 Email: firstname.lastname@example.org Appendix A 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): Point 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 4 URL scheme names ONLY, send this form to: email@example.com For all other URL scheme name classes, including URL scheme names of an unknown class, send this form to: firstname.lastname@example.org.