draft-ietf-urlreg-procedures-01.txt   draft-ietf-urlreg-procedures-02.txt 
INTERNET-DRAFT Rich Petke INTERNET-DRAFT R. Petke
<draft-ietf-urlreg-procedures-01.txt> CompuServe Network Services <draft-ietf-urlreg-procedures-02.txt> WorldCom Advanced Networks
April 30, 1998 July 17, 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.
skipping to change at line 29 skipping to change at line 29
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast). (US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet Draft expires October 31, 1998. This Internet Draft expires January 15, 1999.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
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] [1] defines the general syntax and semantics of
and, by inclusion, URLs. URLs are designated by including a URIs, 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, however, new schemes may need to be defined in the already defined, however, new schemes may need to be defined in the
future in order to accommodate new Internet protocols and/or future in order to accommodate new Internet protocols and/or
procedures. procedures.
A registration process is needed to ensure that the names of all A registration process is needed to ensure that the names of all
such new schemes are guaranteed not to collide. Further, the such new schemes are guaranteed not to collide. Further, the
registration process ensures that URL schemes intended for wide registration process ensures that URL schemes intended for wide
spread, public use are developed in an orderly, well-specified, spread, public use are developed in an orderly, well-specified, and
and public manner. public manner.
This document defines registration procedures which use the Internet This document defines registration procedures which use the Internet
Assigned Numbers Authority (IANA) as a central registry for such URL Assigned Numbers Authority (IANA) as a central registry for such URL
scheme names and the IETF RFC mechanism for scheme review, where scheme names and the IETF RFC mechanism for scheme review, where
appropriate. appropriate.
2.0 URL Scheme Name Registration 2.0 URL Scheme Name Registration
Registration of a new URL scheme name starts with the construction Registration of a new URL scheme name starts with the construction
of a registration proposal. Registration may occur in several of a registration proposal. Registration may occur in several
skipping to change at line 110 skipping to change at line 114
2.1.2. Vendor Tree 2.1.2. Vendor Tree
The vendor tree is used for URL schemes associated with commercially The vendor tree is used for URL schemes associated with commercially
available products. "Vendor" or "producer" are construed as available products. "Vendor" or "producer" are construed as
equivalent and very broadly in this context. equivalent and very broadly in this context.
A registration may be placed in the vendor tree by anyone who needs 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 to identify a scheme for (1) specifying the location of a resource
available via the Internet (2) which may be accessed using a available via the Internet (2) which may be accessed using a
protocol for which there is not currently a URL scheme registered. protocol (or mechanism) for which there is not currently a URL
The registration formally belongs to the vendor or organization scheme registered in the IETF tree. The registration formally
registering the scheme name. Changes to the specification will be belongs to the vendor or organization registering the scheme name.
made at their request, as discussed in subsequent sections. 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 Registrations in the vendor tree will be distinguished by the
leading facet "vnd.". That must be followed by an IANA-approved leading facet "vnd.". That must be followed by an IANA-approved
designation of the producer's name, which is then followed by a URL designation of the producer's name, which is then followed by a URL
scheme name or product designation scheme name or product designation (e.g. vnd.bigcompany.telepathic).
(e.g., vnd.bigcompany.funnypictures).
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.".
While public exposure and review of URL scheme names to be While public exposure and review of URL scheme names to be
registered in the vendor tree is not required, using the ietf-types registered in the vendor tree is not required, using the ietf-types
list for review is strongly encouraged to improve the quality of list for review is strongly encouraged to improve the quality of
those specifications. Registrations in the vendor tree may be those specifications. Registrations in the vendor tree may be
submitted directly to the IANA. submitted directly to the IANA.
2.1.3. Personal or Vanity Tree 2.1.3. Personal or Vanity Tree
Registrations for URL schemes created experimentally or as part of Registrations for URL schemes created experimentally or as part of
skipping to change at line 154 skipping to change at line 165
2.1.4. Additional Registration Trees 2.1.4. Additional Registration Trees
From time to time and as required by the community, the IANA may, 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 with the advice and consent of the IESG, create new top-level
registration trees. It is explicitly assumed that these trees may registration trees. It is explicitly assumed that these trees may
be created for external registration and management by well-known be created for external registration and management by well-known
permanent bodies, such as scientific societies, for URL schemes permanent bodies, such as scientific societies, for URL schemes
specific to the sciences they cover. In general, the quality of specific to the sciences they cover. In general, the quality of
review of specifications for one of these additional registration review of specifications for one of these additional registration
trees is expected to be equivalent to that which IETF would give to trees is expected to be equivalent to that which IETF would give to
registrations in its own tree. Establishment of these new trees will registrations in its own tree. Establishment of these new trees
be announced through RFC publication approved by the IESG. will be announced through RFC publication approved by the IESG.
2.2. Registration Requirements 2.2. Registration Requirements
URL scheme name registration proposals are all expected to conform URL scheme name registration proposals are all expected to conform
to various requirements laid out in the following sections. Note to various requirements laid out in the following sections. Note
that requirement specifics sometimes vary depending on the that requirement specifics sometimes vary depending on the
registration tree, again as detailed in the following sections. registration tree, again as detailed in the following sections.
2.2.1. Scheme Names 2.2.1. Scheme Names
All new URL scheme names, regardless of registration tree, MUST All new URL scheme names, regardless of registration tree, MUST
conform to the syntax specified for scheme names in RFC conform to the syntax specified for scheme names in RFC [URI-SYNTAX].
[URI-SYNTAX].
2.2.2. URL Syntax 2.2.2. URL Syntax
All new URL schemes registered in the IETF tree, MUST conform to the All new URL schemes registered in the IETF tree, MUST conform to the
generic syntax for URLs as specified in RFC [URI-SYNTAX]. URL generic syntax for URLs as specified in RFC [URI-SYNTAX]. URL
schemes registered in the vendor and personal trees are encouraged schemes registered in the vendor and personal trees are encouraged
to conform to the generic syntax but are not required to do so in to conform to the generic syntax but are not required to do so in
order to be registered. order to be registered.
All new URL schemes should follow the Guidelines for URL Schemes, All new URL schemes SHOULD follow the Guidelines for URL Schemes,
set forth in RFC [URL-GUIDELINES]. set forth in RFC [URL-GUIDELINES] [2].
2.2.3. Security Requirements 2.2.3. Security Requirements
An analysis of the security issues inherent in the new URL scheme is An analysis of the security issues inherent in the new URL scheme is
required for all registrations in the IETF tree. (This is in required for all registrations in the IETF tree. (This is in
accordance with the basic requirements for all IETF protocols.) A accordance with the basic requirements for all IETF protocols.) A
similar analysis for schemes registered in the vendor or personal similar analysis for schemes registered in the vendor or personal
trees is encouraged but not required. However, regardless of what trees is encouraged but not required. However, regardless of what
security analysis has or has not been done, all descriptions of security analysis has or has not been done, all descriptions of
security issues must be as accurate as possible regardless of security issues must be as accurate as possible regardless of
skipping to change at line 243 skipping to change at line 253
The following procedure has been implemented by the IANA for review The following procedure has been implemented by the IANA for review
and approval of new URL scheme names. This is not a formal and approval of new URL scheme names. This is not a formal
standards process, but rather an administrative procedure intended standards process, but rather an administrative procedure intended
to allow community comment and sanity checking without excessive to allow community comment and sanity checking without excessive
time delay. For registration in the IETF tree, the normal IETF time delay. For registration in the IETF tree, the normal IETF
processes should be followed, treating posting of an internet-draft processes should be followed, treating posting of an internet-draft
and announcement on the ietf-types list (as described in the next and announcement on the ietf-types list (as described in the next
subsection) as a first step. For registrations in the vendor or subsection) as a first step. For registrations in the vendor or
personal tree, the initial review step described below may be personal tree, the initial review step described below may be
omitted and the URL scheme name may be registered directly by omitted and the URL scheme name may be registered directly by
submitting the template and an explanation directly to IANA (at submitting the template and an explanation directly to IANA
iana@iana.org). However, authors of vendor or personal URL scheme (at iana@iana.org). However, authors of vendor or personal URL
specifications are encouraged to seek community review and comment scheme specifications are encouraged to seek community review and
whenever that is feasible. comment whenever that is feasible.
2.3.1. Present the URL Scheme Name to the Community for Review 2.3.1. Present the URL scheme name to the Community for Review
Send a proposed URL scheme name registration to the Send a proposed URL scheme name registration to the
"ietf-types@iana.org" mailing list for a two week review period. "ietf-types@iana.org" mailing list for a two week review period.
This mailing list has been established for the purpose of reviewing This mailing list has been established for the purpose of reviewing
proposed URL schemes. URL scheme names proposed to this mailing proposed URL schemes. URL scheme names proposed to this mailing
list are not formally registered and should not be used until the list are not formally registered and should not be used until the
registration procedure is complete. registration procedure is complete.
The intent of the public posting is to solicit comments and feedback The intent of the public posting is to solicit comments and feedback
on the choice of scheme name, the syntax and semantics of the on the choice of scheme name, the syntax and semantics of the
skipping to change at line 290 skipping to change at line 300
"owner" of the URL scheme name if possible. Submitters of comments "owner" of the URL scheme name if possible. Submitters of comments
may request that their comment be attached to the URL scheme name may request that their comment be attached to the URL scheme name
registration itself, and if IANA approves of this the comment will registration itself, and if IANA approves of this the comment will
be made accessible in conjunction with the scheme name registration be made accessible in conjunction with the scheme name registration
itself. itself.
2.5. Location of Registered URL Scheme Name List 2.5. Location of Registered URL Scheme Name List
URL scheme name registrations will be posted in the anonymous FTP URL scheme name registrations will be posted in the anonymous FTP
directory directory
"ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/" and "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/".
all registered URL scheme names will be listed in the periodically The scheme syntax and semantics description and other supporting
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 material may also be published as an Informational RFC by sending it
to "rfc-editor@isi.edu" (please follow the instructions to RFC to the RFC Editor (please follow the instructions to RFC authors,
authors [RFC-1543]). RFC-2223 [3]).
2.6. IANA Procedures for Registering URL scheme names 2.6. IANA Procedures for Registering URL scheme names
The IANA will only register URL scheme names in the IETF tree in The IANA will only register URL scheme names in the IETF tree in
response to a communication from the IESG stating that a given response to a communication from the IESG stating that a given
registration has been approved. Vendor and personal types will be registration has been approved. Vendor and personal types will be
registered by the IANA automatically and without any formal review registered by the IANA automatically and without any formal review
as long as the following minimal conditions are met: as long as the following minimal conditions are met:
o Security considerations Scheme Name Syntax: The syntax of the requested scheme name
o TBD (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, 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.
For vendor tree registrations, IANA will assign unique designations
to each producer registering one or more scheme names.
2.7. Change Control 2.7. Change Control
Once a URL scheme name has been published by IANA, the author may Once a URL scheme name has been published by IANA, the author may
request a change to its definition. The descriptions of the request a change to its definition. The descriptions of the
different registration trees above designate the "owners" of each different registration trees above designate the "owners" of each
type of registration. The change request follows the same procedure type of registration. The change request follows the same
as the registration request: procedure as the registration request:
(1) Publish the revised template on the ietf-types list. (1) Publish the revised scheme syntax and semantics on the
ietf-types list.
(2) Leave at least two weeks for comments. (2) Leave at least two weeks for comments.
(3) Publish using IANA after formal review if required. (3) Publish using IANA after formal review if required.
Changes should be requested only when there are serious omission or Changes should be requested only when there are serious omission or
errors in the published specification. When review is required, a errors in the published specification. When review is required, a
change request may be denied if it renders entities that were valid change request may be denied if it renders entities that were valid
under the previous definition invalid under the new definition. under the previous definition invalid under the new definition.
The owner of a URL scheme registration may pass responsibility for The owner of a URL scheme registration may pass responsibility for
the registration to another person or agency by informing IANA and the registration to another person or agency by informing IANA and
the ietf-types list; this can be done without discussion or review. the ietf-types list; this can be done without discussion or review.
The IESG may reassign responsibility for a URL scheme name. The most The IESG may reassign responsibility for a URL scheme name. The
common case of this will be to enable changes to be made to schemes most common case of this will be to enable changes to be made to
where the author of the registration has died, moved out of contact schemes where the author of the registration has died, moved out of
or is otherwise unable to make changes that are important to the contact or is otherwise unable to make changes that are important to
community. the community.
URL scheme name registrations may not be deleted; URL scheme names URL scheme name registrations may not be deleted; URL scheme names
which are no longer believed appropriate for use can be declared which are no longer believed appropriate for use can be declared
OBSOLETE by a change to their "intended use" field; such URL scheme OBSOLETE by a change to their "intended use" field; such URL scheme
names will be clearly marked in the lists published by IANA. names will be clearly marked in the lists published by IANA.
2.8. Registration Template 2.8. Registration Template
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of URL Scheme Name XXX Subject: Registration of URL Scheme Name <name>
URL Scheme Name: URL Scheme Name:
Security considerations: Security considerations:
Interoperability considerations: Interoperability considerations:
Published specification: Published specification:
Applications which use this URL scheme name: Applications which use this URL scheme name:
skipping to change at line 389 skipping to change at line 415
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 a so that users are not misled as to the true security properties of a
registered URL scheme. 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.
4.0 References 4.0 References
RFC [URI-SYNTAX] [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998
RFC [URL-GUIDELINES] [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.
5.0 Author's Address 5.0 Author's Address
Rich Petke Rich Petke
CNS/WorldCom WorldCom Advanced Networks
5000 Britton Road 5000 Britton Road
P. O. Box 5000 P. O. Box 5000
Hilliard, OH 430 Hilliard, OH 43026-5000
USA USA
Phone: +1 614 723 4157 Phone: +1 614 723 4157
Fax: +1 614 723 1333 Fax: +1 614 723 1333
EMail: rpetke@compuserve.net EMail: rpetke@compuserve.net
Appendix A -- Grandfathered URL Scheme Names Appendix A -- Grandfathered URL Scheme Names
A number of URL scheme names, in use prior to 1998, would, if A number of URL scheme names, in use prior to 1998, would, if
registered under the guidelines in this document, be placed into registered under the guidelines in this document, be placed into
either the vendor or personal trees. Re-registration of those either the vendor or personal trees. Re-registration of those types
types to reflect the appropriate trees is encouraged, but not to reflect the appropriate trees is encouraged, but not required.
required. Ownership and change control principles outlined in this Ownership and change control principles outlined in this document
document apply to those types as if they had been registered in the apply to those types as if they had been registered in the trees
trees described above. described above.
ABOUT:
AOL:
 End of changes. 23 change blocks. 
46 lines changed or deleted 77 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/