draft-ietf-urlreg-procedures-02.txt   draft-ietf-urlreg-procedures-03.txt 
INTERNET-DRAFT R. Petke INTERNET-DRAFT R. Petke
<draft-ietf-urlreg-procedures-02.txt> WorldCom Advanced Networks <draft-ietf-urlreg-procedures-03.txt> WorldCom Advanced Networks
July 17, 1998 August 7, 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 January 15, 1999. This Internet Draft expires February 7, 1999.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. 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] [1] defines the general syntax and semantics of RFC [URI-SYNTAX] [1] defines the general syntax and semantics of
URIs, 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
already defined, however, new schemes may need to be defined in the are already defined, however, new schemes may need to be defined in
future in order to accommodate new Internet protocols and/or the 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, and spread, public use are developed in an orderly, well-specified, 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 In order to increase the efficiency and flexibility of the URL
of a registration proposal. Registration may occur in several scheme name registration process, several different registration
different registration trees, which have different requirements as "trees" have been created. The registration requirements and
discussed below. In general, the new registration proposal is specific registration procedures for each tree differ, allowing the
circulated and reviewed in a fashion appropriate to the tree overall registration procedure to accommodate the different natural
involved. The URL scheme name is then registered if the proposal is requirements for URL schemes. For example, a scheme that will be
acceptable. The following sections describe the requirements and recommended for wide support and implementation by the Internet
procedures used for each of the different registration trees. Community requires a more complete review, prior to registration,
than a scheme intended to be used for resources associated with
proprietary software.
2.1. Registration Trees and URL Schemes Each of the URL scheme name registration trees also imparts a
specific syntax to the scheme name being registered.
In order to increase the efficiency and flexibility of the Registration of a new URL scheme name may occur in any ONE of the
registration process, three different formats of URL scheme names established registration trees.
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.
2.1.1. IETF Tree 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 The IETF tree is intended for URL schemes of general interest to the
Internet Community. Registration in the IETF tree requires approval Internet Community. The tree exists for URL schemes that require a
by the IESG and publication of the URL scheme syntax and semantics substantive review and approval process; the vendor and personal
as some form of RFC, usually a standards track RFC. 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.
URL scheme names in the IETF tree are normally denoted by names that 2.2.2 Registration Requirements
are not explicitly faceted, i.e., do not contain period (".")
characters. 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 The "owner" of a URL scheme name registration in the IETF tree is
assumed to be the IETF itself. Modification or alteration of the assumed to be the IETF itself. Modification or alteration of the
specification requires the same level of processing (e.g. standards specification requires the same level of processing (e.g. standards
track) as required for the initial registration. track) as required for the initial registration.
2.1.2. Vendor Tree 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 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 (or mechanism) for which there is not currently a URL protocol (or mechanism) for which there is not currently a URL
scheme registered in the IETF tree. The registration formally scheme registered in the IETF tree.
belongs to the vendor or organization registering the scheme name.
Changes to the specification will be made at their request, as The registration of a URL scheme name in the vendor tree does not
discussed in subsequent sections. 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 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 (e.g. vnd.bigcompany.telepathic). scheme name or product designation (e.g. vnd.bigcompany.telepathic).
IANA will assign unique designations for producer names, IANA will assign unique designations for producer names,
("bigcompany" in the example above). Accordingly, once a producer ("bigcompany" in the example above). Accordingly, once a producer
has successfully registered a scheme name, (e.g. has successfully registered a scheme name,
"vnd.bigcompany.telepathic"), only registrations for new scheme (e.g. "vnd.bigcompany.telepathic"), only registrations for new
names that originate from "bigcompany" will begin with scheme names that originate from "bigcompany" will begin with
"vnd.bigcompany.". "vnd.bigcompany.".
While public exposure and review of URL scheme names to be 2.4 The Personal or Private Tree
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 2.4.1 Purpose
Registrations for URL schemes created experimentally or as part of Registrations for URL schemes created experimentally or as part of
products that are not distributed commercially may be registered in products that are not distributed commercially may be registered in
the personal or vanity tree. The registrations are distinguished by the personal tree. Unlike the IETF and vendor trees which guarantee
the leading facet "prs.". 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 The owner of "personal" registrations and associated specifications
is the person or entity making the registration, or one to whom is the person or entity making the registration, or one to whom
responsibility has been transferred as described below. responsibility has been transferred as described below.
While public exposure and review of URL scheme names to be 2.4.4 Syntax of URL Scheme Names
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 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, 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 registrations in its own tree. Establishment of these new trees
will be announced through RFC publication approved by the IESG. will be announced through RFC publication approved by the IESG.
2.2. Registration Requirements 3.0 Registration Procedures
URL scheme name registration 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 detailed 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]. 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.
All new URL schemes SHOULD follow the Guidelines for URL Schemes,
set forth in RFC [URL-GUIDELINES] [2].
2.2.3. Security Requirements 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.
An analysis of the security issues inherent in the new URL scheme is 3.1 The IETF Tree
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 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".
There is absolutely no requirement that URL schemes registered in Complete the registration template (section 7.0 of this document)
any tree be secure or completely free from risks. Nevertheless, all and submit it to the IESG for review. Generally the details of
known security risks must be identified in the registration of a URL the proposed new URL scheme should already be documented in an
scheme name, again regardless of registration tree. Internet-Draft and the registration template should reference this
draft.
The security considerations section of all registrations is subject The IESG will review the proposed new scheme and either refer the
to continuing evaluation and modification, and in particular may be scheme to a working group (existing or new) or directly present the
extended by use of the "comments on URL scheme name" mechanism registration and associated documentation to the IESG for a last
described in subsequent sections. 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.
2.2.4. Publication Requirements 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.
Proposals for URL schemes registered in the IETF tree must be Authors proposing new URL schemes for the IETF tree are encouraged
published as RFCs. RFC publication of vendor and personal URL to present the proposed schemes to the IETF as a whole, via the
schemes is encouraged but not required. In all cases IANA will Internet-Drafts mechanism, well in advance of submission to the
retain copies of all URL scheme proposals and "publish" them as part IESG.
of the URL scheme names registration tree itself.
Other than in the IETF tree, the registration of a URL scheme name 3.2 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. This is too difficult and
too lengthy a process for the convenient registration of URL scheme
names.
The IETF tree exists for URL schemes that do require a substantive Complete the registration template (section 7.0 of this document) as
review and approval process with the vendor and personal trees exist completely as possible.
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 While not required, it is recommended and encouraged that vendors
standards-track processing and, hence, RFC publication. 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.
2.3. Registration Procedure Forward the completed registration template to IANA (iana@iana.org).
The following procedure has been implemented by the IANA for review IANA will review the registration template to ensure that it meets
and approval of new URL scheme names. This is not a formal the requirements necessary for registration. If it does not meet
standards process, but rather an administrative procedure intended the necessary requirements, the application will be rejected and
to allow community comment and sanity checking without excessive returned to the submitter and the registration process will be
time delay. For registration in the IETF tree, the normal IETF terminated. Authors may choose to amend the information presented
processes should be followed, treating posting of an internet-draft in the registration template and re-submit it to IANA who will treat
and announcement on the ietf-types list (as described in the next the re-submission as a new registration request.
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.
2.3.1. Present the URL scheme name to the Community for Review 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.
Send a proposed URL scheme name registration to the Regardless of whether or not the accepted registration template has
"ietf-types@iana.org" mailing list for a two week review period. previously been posted to the ietf-url-schemes list for review, IANA
This mailing list has been established for the purpose of reviewing will post the template to the list along with an indication that the
proposed URL schemes. URL scheme names proposed to this mailing template has been officially received by IANA for registration.
list are not formally registered and should not be used until the IANA will then wait for two (2) weeks for comments on and community
registration procedure is complete. review of the registration request.
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
scheme, and a review of any interoperability or security scheme, and a review of any interoperability or security
considerations. The submitter may submit a revised registration, or considerations (if such information is disclosed in the application
withdraw the registration completely, at any time. or associated documentation).
2.3.2. IESG Approval IANA will forward all comments received during this review period to
the person designated as the contact person in the registration
template.
URL scheme names registered in the IETF tree must be submitted to The submitter may submit a revised registration, or withdraw the
the IESG for approval. registration completely, at any time.
2.3.3. IANA Registration After the two week review period has expired, IANA shall register
the URL scheme name in the vendor tree.
Provided that the URL scheme name meets the requirements for URL URL scheme names proposed to this mailing list are not formally
scheme names and has obtained approval that is necessary, the author registered and should not be used until the registration procedure
may submit the registration request to the IANA, which will register is completed by IANA.
the scheme name and make the URL scheme name registration available
to the community.
2.4. Comments on URL Scheme Name Registrations 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 Comments on registered URL scheme names may be submitted by members
of the community to IANA. These comments will be passed on to the of the community to IANA. These comments will be passed on to the
"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 5.0 Change Control
URL scheme name registrations will be posted in the anonymous FTP
directory
"ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/".
The scheme syntax and semantics description and other supporting
material may also be published as an Informational RFC by sending it
to the RFC Editor (please follow the instructions to RFC authors,
RFC-2223 [3]).
2.6. IANA Procedures for Registering URL scheme names
The IANA will only register URL scheme names in the IETF tree in
response to a communication from the IESG stating that a given
registration has been approved. Vendor and personal types will be
registered by the IANA automatically and without any formal review
as long as the following minimal conditions are met:
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, 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
Once a URL scheme name has been published by IANA, the author may Once a URL scheme name has been published by IANA, the owner of the
request a change to its definition. The descriptions of the scheme name may request a change to its definition. The descriptions
different registration trees above designate the "owners" of each of the different registration trees above designate the owners of
type of registration. The change request follows the same each type of registration. The change request follows the same
procedure as the registration request: procedure as the registration request:
(1) Publish the revised scheme syntax and semantics on the (1) Complete the registration template.
ietf-types list.
(2) Leave at least two weeks for comments. (2) Publish the revised scheme syntax and semantics on the
ietf-url-schemes list if peer review is requested.
(3) Publish using IANA after formal review if required. (3) Submit the revised registration to IANA.
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-url-schemes list; this can be done without discussion or
review.
The IESG may reassign responsibility for a URL scheme name. The 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 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 schemes where the author of the registration has died, moved out of
contact or is otherwise unable to make changes that are important to contact or is otherwise unable to make changes that are important to
the 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 6.0 IANA Considerations
To: ietf-types@iana.org 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> Subject: Registration of URL Scheme Name <name>
URL Scheme Name: URL Scheme Name:
Character encoding considerations:
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:
Additional information: Additional information:
skipping to change at line 397 skipping to change at line 531
Intended usage: Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE) (One of COMMON, LIMITED USE or OBSOLETE)
Author/Change controller: Author/Change controller:
(Any other information that the author deems interesting may be (Any other information that the author deems interesting may be
added below this line.) added below this line.)
3.0 Security Considerations 8.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 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 9.0 References
[1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998 Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], August 1998
[2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., [2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R.,
"Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998 "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August 1998
[3] Postel, J., Reynolds, J., "Instructions to RFC Authors", [3] Postel, J., Reynolds, J., "Instructions to RFC Authors",
RFC 2223, October 1997. RFC 2223, October 1997.
5.0 Author's Address 10.0 Author's Address
Rich Petke Rich Petke
WorldCom Advanced Networks WorldCom Advanced Networks
5000 Britton Road 5000 Britton Road
P. O. Box 5000 P. O. Box 5000
Hilliard, OH 43026-5000 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 procedures specified in this document, be
either the vendor or personal trees. Re-registration of those types placed into either the vendor or personal trees. Re-registration
to reflect the appropriate trees is encouraged, but not required. of those types to reflect the appropriate trees is encouraged, but
Ownership and change control principles outlined in this document not required. Ownership and change control principles outlined in
apply to those types as if they had been registered in the trees this document apply to those types as if they had been registered in
described above. the trees described above.
ABOUT: ABOUT:
AOL: AOL:
 End of changes. 50 change blocks. 
213 lines changed or deleted 347 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/