draft-ietf-urlreg-procedures-00.txt   draft-ietf-urlreg-procedures-01.txt 
INTERNET-DRAFT Rich Petke INTERNET-DRAFT Rich Petke
<draft-ietf-urlreg-procedures-00.txt> CompuServe Network Services <draft-ietf-urlreg-procedures-01.txt> CompuServe Network Services
March 13, 1998 April 30, 1998
Registration Procedures for URL Scheme Names Registration Procedures for URL Scheme Names
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ds.internic.net (US East Coast), nic.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
Rim). (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet Draft expires September 13, 1998. This Internet Draft expires October 31, 1998.
Abstract Abstract
This document defines the process by which new URL schemes are This document defines the process by which new URL schemes are
registered. registered.
1.0 Introduction 1.0 Introduction
A Uniform Resource Locator (URL) is a compact string representation A Uniform Resource Locator (URL) is a compact string representation
of the location for a resource that is available via the Internet. of the location for a resource that is available via the Internet.
RFC [URI-SYNTAX] defines the general syntax and semantics of URIs, RFC [URI-SYNTAX] defines the general syntax and semantics of URIs,
and, by inclusion, URLs. URLs are designated by including a and, by inclusion, URLs. URLs are designated by including a
"scheme" and then a "scheme-specific part". Many URL schemes are "scheme" and then a "scheme-specific part". Many URL schemes are
already defined. already defined, however, new schemes may need to be defined in the
future in order to accommodate new Internet protocols and/or
procedures.
RFC [URL-GUIDELINES] provides guidelines for the definition of new A registration process is needed to ensure that the names of all
URL schemes, for consideration by those who are defining and such new schemes are guaranteed not to collide. Further, the
registering or evaluating those definitions. registration process ensures that URL schemes intended for wide
spread, public use are developed in an orderly, well-specified,
and public manner.
2.0 Scope 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.
The URL scheme registration process is restricted to the 2.0 URL Scheme Name Registration
registration of new URL scheme names.
3.0 Classifications of Scheme Names 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.
Not all URL scheme names are created equal. This section defines 2.1. Registration Trees and URL Schemes
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 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.
If the name proposed for a new URL scheme is a common word, 2.1.1. IETF Tree
meaningful to a large and/or wide population, then the scheme name
is considered a Class 1 name. Examples of such names include:
Telephone The IETF tree is intended for URL schemes of general interest to the
Phone Internet Community. Registration in the IETF tree requires approval
Fax by the IESG and publication of the URL scheme syntax and semantics
TV as some form of RFC, usually a standards track RFC.
Weather
Music
3.2 Class 2 - Acronyms URL scheme names in the IETF tree are normally denoted by names that
are not explicitly faceted, i.e., do not contain period (".")
characters.
Short acronyms for technical terms which do not themselves create The "owner" of a URL scheme name registration in the IETF tree is
common words (i.e. the acronym is not a Class 1 name), are assumed to be the IETF itself. Modification or alteration of the
considered to be Class 2 scheme names. Examples of such names specification requires the same level of processing (e.g. standards
include: track) as required for the initial registration.
HTTP 2.1.2. Vendor Tree
FTP
NNTP
TELNET
WAIS
3.3 Class 3 - Vanity Names and Registered Trade Names 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.
Scheme names that echo registered trade names and vanity names are A registration may be placed in the vendor tree by anyone who needs
considered to be Class 3 scheme names. Examples of such names to identify a scheme for (1) specifying the location of a resource
include: 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.
AOL Registrations in the vendor tree will be distinguished by the
RealAudio leading facet "vnd.". That must be followed by an IANA-approved
STTNG designation of the producer's name, which is then followed by a URL
scheme name or product designation
(e.g., vnd.bigcompany.funnypictures).
3.4 Class 4 - Private Schemes 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.
Scheme names based on IANA assigned domain names and matching the 2.1.3. Personal or Vanity Tree
syntax specified below are considered to be Class 4 scheme names.
The syntax of a class 4 URL scheme name is: 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.".
"NOREG+" <domain> [ "+" <extension>] ":" 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.
where - 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.
<domain> is defined in [STD13], section 3.5. 2.1.4. Additional Registration Trees
<extension> is optional and may contain any legal scheme name From time to time and as required by the community, the IANA may,
characters as defined in RFC [URI-SYNTAX]. 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.
Examples of valid Class 4 URL scheme names include: 2.2. Registration Requirements
noreg+compuserve.net+rpa: URL scheme name registration proposals are all expected to conform
noreg+nt.microsoft.com: 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.
4.0 Registration Procedures (to be followed by a requestor) 2.2.1. Scheme Names
To register a new URL scheme name: All new URL scheme names, regardless of registration tree, MUST
conform to the syntax specified for scheme names in RFC
[URI-SYNTAX].
1. Determine which scheme name class (as described in section 3) 2.2.2. URL Syntax
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 All new URL schemes registered in the IETF tree, MUST conform to the
A of this document. 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.
3. For Class 4 URL scheme names ONLY, forward the completed form to All new URL schemes should follow the Guidelines for URL Schemes,
IANA directly. set forth in RFC [URL-GUIDELINES].
4. For all other URL scheme name classes, forward the completed form 2.2.3. Security Requirements
to the IESG.
With the exception of Class 4 URL scheme names, which are easily An analysis of the security issues inherent in the new URL scheme is
recognizable, the IESG has the right to reclassify any proposed URL required for all registrations in the IETF tree. (This is in
scheme names that have been incorrectly classified. 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".
The IESG should process applications for the registration of new URL There is absolutely no requirement that URL schemes registered in
scheme names in a timely manner. It may delay the approval of any any tree be secure or completely free from risks. Nevertheless, all
application for just cause, such as lack of consensus within the known security risks must be identified in the registration of a URL
IETF (when a Class 1 scheme name registration is requested), or scheme name, again regardless of registration tree.
multiple parties attempting to register the same or similar scheme
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. names.
5.0 Registration Procedures (to be followed by the IESG) 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.
5.1 Class 1 Procedures (Common Names) As discussed above, registration of a top-level type requires
standards-track processing and, hence, RFC publication.
Registering a Class 1 URL scheme name requires the consensus of the 2.3. Registration Procedure
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 The following procedure has been implemented by the IANA for review
(standards track, informational, or BCP). 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.
If the IESG approves the registration, it will forward the 2.3.1. Present the URL Scheme Name to the Community for Review
registration form to IANA for recording.
5.2 Class 2 Procedures (Acronyms) 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.
Registering a Class 2 URL scheme name requires only the consensus of The intent of the public posting is to solicit comments and feedback
the IESG. The IESG must require the proposed scheme to be on the choice of scheme name, the syntax and semantics of the
documented in an RFC or other permanent and readily available scheme, and a review of any interoperability or security
reference, in sufficient detail so that interoperability between considerations. The submitter may submit a revised registration, or
independent implementations is possible. withdraw the registration completely, at any time.
If the IESG approves the registration and supporting documentation, 2.3.2. IESG Approval
it will forward the registration form to IANA for recording.
5.3 Class 3 Procedures (Vanity Names and Registered Trade Names) URL scheme names registered in the IETF tree must be submitted to
the IESG for approval.
Class 3 URL scheme names are approved on a first come, first served 2.3.3. IANA Registration
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. 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.
6.0 Registration Procedures (to be followed by IANA) 2.4. Comments on URL Scheme Name Registrations
6.1 Procedures for Class 1, 2, and 3 URL Scheme Names 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.
IANA will only accept completed URL scheme name registration forms 2.5. Location of Registered URL Scheme Name List
which have been approved by the IESG for recording.
6.2 Class 4 Procedures (Private Schemes) 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]).
Upon receipt of a completed URL scheme name registration form, IANA 2.6. IANA Procedures for Registering URL scheme names
shall:
1. Verify that the proposed URL scheme name conforms to the syntax The IANA will only register URL scheme names in the IETF tree in
specified for Class 4 URL scheme names in section 3.4 of this response to a communication from the IESG stating that a given
document. registration has been approved. Vendor and personal types will be
2. Verify that the requestor is affiliated with the owner of the DNS registered by the IANA automatically and without any formal review
name specified in the registration form. as long as the following minimal conditions are met:
3. Verify that the "point of contact" information is sufficiently
stable.
4. Record the registration.
7.0 Security Considerations 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 Information that creates or updates a registration needs to be
authenticated. authenticated.
Information concerning possible security vulnerabilities of a Information concerning possible security vulnerabilities of a
protocol may change over time. Consequently, claims as to the protocol may change over time. Consequently, claims as to the
security properties of a registered URL scheme may change as well. security properties of a registered URL scheme may change as well.
As new vulnerabilities are discovered, information about such As new vulnerabilities are discovered, information about such
vulnerabilities may need to be attached to existing registrations, vulnerabilities may need to be attached to existing registrations,
so that users are not misled as to the true security properties of so that users are not misled as to the true security properties of a
a registered URL schemes. registered URL scheme.
Delegations of a name space should only be assigned to someone with Delegations of a name space should only be assigned to someone with
adequate security. adequate security.
8.0 References 4.0 References
[STD 13]
[RFC-URI-SYNTAX] RFC [URI-SYNTAX]
[RFC-URL-GUIDELINES] RFC [URL-GUIDELINES]
9.0 Author's Address 5.0 Author's Address
Rich Petke Rich Petke
CompuServe Network Services Inc. (WorldCom) CNS/WorldCom
5000 Britton Road 5000 Britton Road
P. O. Box 5000 P. O. Box 5000
Hilliard, OH 43026-5000 Hilliard, OH 430
Phone: 614-723-4157 USA
Email: rpetke@compuserve.net
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: Phone: +1 614 723 4157
Fax: +1 614 723 1333
EMail: rpetke@compuserve.net
For Class 4 URL scheme names ONLY, send this form to: Appendix A -- Grandfathered URL Scheme Names
ietf-types@iana.org
For all other URL scheme name classes, including URL scheme names of A number of URL scheme names, in use prior to 1998, would, if
an unknown class, send this form to: iesg@ietf.org. 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.
 End of changes. 64 change blocks. 
153 lines changed or deleted 302 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/