INTERNET-DRAFT R. Petke <draft-ietf-urlreg-procedures-03.txt> WorldCom Advanced Networks August 7, 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 February 7, 1999. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 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] [1] 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 In order to increase the efficiency and flexibility of the URL scheme name registration process, several 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, prior to registration, than a scheme intended to be used for resources associated with proprietary software. Each of the URL scheme name registration trees also imparts a specific syntax to the scheme name being registered. Registration of a new URL scheme name may occur in any ONE of the established registration trees. 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, the desired syntax for the scheme name, and the ability to meet the registration requirements for the desired tree. 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. The following subsections define the registration trees available at this time, the purpose of each tree, the requirements for registration in each tree, and the associated URL scheme name formats that are applied to names registered in each tree. 2.1 General Requirements All new URL scheme NAMES, regardless of registration tree, MUST conform to the syntax specified in RFC [URI-SYNTAX] for scheme names. 2.2 The IETF Tree 2.2.1 Purpose 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; 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. 2.2.2 Registration Requirements 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. All new URL schemes registered in the IETF tree, MUST conform to the generic syntax for URLs as specified in RFC [URI-SYNTAX]. 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 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 names" mechanism described in section 4.0. 2.2.3 Ownership 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.2.4 Syntax of URL Scheme Names URL scheme names in the IETF tree are normally denoted by names that are not explicitly faceted, i.e., do not contain period (".") characters. For example, "http", "ftp", "mailto", etc. 2.3 The Vendor Tree 2.3.1 Purpose 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 (or mechanism) for which there is not currently a URL scheme registered in the IETF tree. The registration of a URL scheme name in the vendor tree 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 and the registration in the IETF tree. 2.3.2 Registration Requirements RFC publication of vendor 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]). While public exposure and review of URL scheme names to be registered in the vendor tree is not required, using the ietf-url-schemes list for review is strongly encouraged to improve the quality of those specifications. URL schemes registered in the vendor tree are encouraged to conform to the generic URL 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]. 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 registered in the vendor tree be secure or completely free from risks. Nevertheless, all known security risks SHOULD be identified in the registration. 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 section 4.0. 2.3.3 Ownership of Registration 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. 2.3.4 Syntax of URL Scheme Names 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.telepathic). IANA will assign unique designations for producer names, ("bigcompany" in the example above). Accordingly, once a producer has successfully registered a scheme name, (e.g. "vnd.bigcompany.telepathic"), only registrations for new scheme names that originate from "bigcompany" will begin with "vnd.bigcompany.". 2.4 The Personal or Private Tree 2.4.1 Purpose Registrations for URL schemes created experimentally or as part of products that are not distributed commercially may be registered in the personal tree. Unlike the IETF and vendor trees which guarantee the uniqueness of registered scheme names, registrations in the personal tree are NOT guaranteed to be unique. Multiple sites may register the same scheme name but use it in different (and incompatible) ways. The registration of a URL scheme name in the personal tree 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 and the registration in the IETF tree. 2.4.2 Registration Requirements RFC publication of personal URL schemes is encouraged but not required. Materials may be published as an Informational RFC by sending it to the RFC Editor (please follow the instructions to RFC authors, RFC-2223 [3]). While public exposure and review of URL scheme names to be registered in the personal tree is not required, using the ietf-url-schemes list for review is strongly encouraged to improve the quality of those specifications. URL schemes registered in the personal tree are encouraged to conform to the generic URL 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]. 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 registered in the personal tree be secure or completely free from risks. Nevertheless, all known security risks SHOULD be identified in the registration. 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 section 4.0. 2.4.3 Ownership of Registration 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. 2.4.4 Syntax of URL Scheme Names Registrations in the personal tree are distinguished by the leading facet "prs.". For example, "prs.fiberreflection". 2.5 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. 3.0 Registration Procedures The following sections detail the procedures to follow to register a new URL scheme name in a specific registration tree. With the exception of registration in the IETF tree, these procedures are not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay. 3.1 The IETF Tree Complete the registration template (section 7.0 of this document) and submit it to the IESG for review. Generally the details of the proposed new URL scheme should already be documented in an Internet-Draft and the registration template should reference this draft. The IESG will review the proposed new scheme and either refer the scheme to a working group (existing or new) or directly present the registration and associated documentation to the IESG for a last call. In the former case, the working group is responsible for re-submitting it to the IESG for approval at such time as it has received adequate review and deliberation. After the IESG has approved the registration, it will forward the registration paperwork and documentation to IANA for publication on the ietf-url-schemes list and official registration in the IETF tree. Authors proposing new URL schemes for the IETF tree are encouraged to present the proposed schemes to the IETF as a whole, via the Internet-Drafts mechanism, well in advance of submission to the IESG. 3.2 The Vendor Tree Complete the registration template (section 7.0 of this document) as completely as possible. While not required, it is recommended and encouraged that vendors submit a copy of the completed registration template (which includes references to any additional documentation), to the ietf-url-schemes list for peer review and comment. The quality of URL schemes can usually be improved through such a process. The amount of feedback received regarding the proposed scheme should serve as an indication of how long to keep the proposal in peer review before proceeding with the registration. Forward the completed registration template to IANA (iana@iana.org). IANA will review the registration template to ensure that it meets the requirements necessary for registration. If it does not meet the necessary requirements, the application will be rejected and returned to the submitter and the registration process will be terminated. Authors may choose to amend the information presented in the registration template and re-submit it to IANA who will treat the re-submission as a new registration request. IANA will assign the unique designation for the producer's name at this time if one has not already been assigned to the producer making the registration request. Regardless of whether or not the accepted registration template has previously been posted to the ietf-url-schemes list for review, IANA will post the template to the list along with an indication that the template has been officially received by IANA for registration. IANA will then wait for two (2) weeks for comments on and community review of the registration request. 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 (if such information is disclosed in the application or associated documentation). IANA will forward all comments received during this review period to the person designated as the contact person in the registration template. The submitter may submit a revised registration, or withdraw the registration completely, at any time. After the two week review period has expired, IANA shall register the URL scheme name in the vendor tree. URL scheme names proposed to this mailing list are not formally registered and should not be used until the registration procedure is completed by IANA. 3.3 The Personal Tree The registration procedure for URL scheme names in the personal tree is identical as that specified for the vendor tree with the exception of IANA assigning the vendor a unique name. 4.0 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. 5.0 Change Control Once a URL scheme name has been published by IANA, the owner of the scheme name 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) Complete the registration template. (2) Publish the revised scheme syntax and semantics on the ietf-url-schemes list if peer review is requested. (3) Submit the revised registration to IANA. 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-url-schemes 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. 6.0 IANA Considerations 6.1 Discussion List A discussion list named "ietf-url-schemes" needs to be created and maintained at "iana.org". The list MUST be open and MUST NOT require the submitter to be subscribed to the list in order to process a post. 6.2 Location of Registered URL Scheme Name List URL scheme name registrations need to be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/". 6.3 Procedures for Registering URL Scheme Names Scheme names in the IETF tree will only be registered in response to a communication from the IESG stating that a given registration has been approved. Scheme names in the vendor tree will be registered automatically provided that the registration template contains at least the information specified below. Assignment of unique scheme names shall be on a first come, first served basis. Scheme names in the personal tree will be registered automatically provided that the registration template contains at least the information specified below. No attempt shall be made to prevent multiple applications from registering the same scheme name even if the use of the schemes are different and incompatible. The following minimal information must be specified for a registration in the vendor or personal tree: Scheme Name Syntax: The syntax of the requested scheme name (including the assigned producer designation in the case of vendor tree registrations), MUST conform to the syntax for such as specified in RFC [URI-SYNTAX]. While encouraged to do so, the syntax for the actual scheme does not have to conform to the general syntax specified in RFC [URI-SYNTAX]. Security Considerations: The application for registration of a scheme name MUST include a discussion of the security considerations inherent in the scheme. Contact Person: The application MUST include accurate information regarding a person to contact about the registration. Author/Change Controller: The application MUST specify the author and/or entity responsible for change control of the proposed scheme. 7.0 Registration Template To: iana@iana.org Subject: Registration of URL Scheme Name <name> URL Scheme Name: Character encoding considerations: 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.) 8.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. 9.0 References [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], 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. 10.0 Author's Address Rich Petke WorldCom Advanced Networks 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 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 procedures specified 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. ABOUT: AOL:
Datatracker
Report a datatracker bug
draft-ietf-urlreg-procedures-03
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2717.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |