draft-ietf-urlreg-procedures-04.txt   draft-ietf-urlreg-procedures-05.txt 
INTERNET-DRAFT R. Petke INTERNET-DRAFT R. Petke
<draft-ietf-urlreg-procedures-04.txt> MCIWORLDCOM Advanced Networks <draft-ietf-urlreg-procedures-05.txt> MCI WorldCom Advanced Networks
November 1, 1998 I. King
Microsoft Corporation
January 25, 1999
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 28 skipping to change at line 30
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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft expires April 30, 1999. This Internet-Draft expires July 25, 1999.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This document defines the process by which new URL scheme names are This document defines the process by which new URL scheme names 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.
skipping to change at line 67 skipping to change at line 69
[URL-GUIDELINES], Guidelines for URL Schemes [2], provides [URL-GUIDELINES], Guidelines for URL Schemes [2], provides
guidelines for the creation of new URL schemes. The primary focus guidelines for the creation of new URL schemes. The primary focus
of this document is on the <scheme> portion of new URL schemes, of this document is on the <scheme> portion of new URL schemes,
referred to as the "scheme name" throughout this document. referred to as the "scheme name" throughout this document.
2.0 URL Scheme Name Registration Trees 2.0 URL Scheme Name Registration Trees
2.1 General 2.1 General
In order to increase the efficiency and flexibility of the URL In order to increase the efficiency and flexibility of the URL
scheme name registration process, two different registration "trees" scheme name registration process, the need is recognized for
have been created. The registration requirements and specific multiple registration "trees". The registration requirements and
registration procedures for each tree differ, allowing the overall specific registration procedures for each tree differ, allowing the
registration procedure to accommodate the different natural overall registration procedure to accommodate the different natural
requirements for URL schemes. For example, a scheme that will be requirements for URL schemes. For example, a scheme that will be
recommended for wide support and implementation by the Internet recommended for wide support and implementation by the Internet
community requires a more complete review than a scheme intended to community requires a more complete review than a scheme intended to
be used for resources associated with proprietary software. be used for resources associated with proprietary software.
The first step in registering a new URL scheme name is to determine The first step in registering a new URL scheme name is to determine
which registration tree the scheme should be registered in. which registration tree the scheme should be registered in.
Determination of the proper registration tree is based on the Determination of the proper registration tree is based on the
intended use for the new scheme and the desired syntax for the intended use for the new scheme and the desired syntax for the
scheme name. scheme name.
Note that some URL schemes defined prior to this document do not This document will discuss in detail the tree that reflects current
conform to the naming conventions described below. See Appendix A practice, under IETF ownership and control. It will also set forth
for a discussion of those schemes. an outline to assist authors in creating new trees to address
differing needs for wide acceptance and interoperability, ease of
creation and use, and type and "strength" of ownership.
2.2 The IETF Tree 2.2 The IETF Tree
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. The tree exists for URL schemes that require a Internet community. The tree exists for URL schemes that require a
substantive review and approval process. It is expected that substantive review and approval process. It is expected that
applicability statements for particular applications will be applicability statements for particular applications will be
published from time to time that recommend implementation of, and published from time to time that recommend implementation of, and
support for, URL schemes that have proven particularly useful in support for, URL schemes that have proven particularly useful in
those contexts. those contexts.
2.3 The OID Tree 2.3 Additional Registration Trees
The OID tree is intended for URL schemes which will be used in a
proprietary manner. The trees exists to provide a mechanism for
ensuring that scheme names do not collide. The syntax and semantics
of URL schemes created in the OID tree do not have to be reviewed or
publicly disclosed.
Creating a URL scheme name in the OID tree does not imply
endorsement, approval, or recommendation by the IETF or even
certification that the specification is adequate, even if the scheme
was published as an IETF Internet-Draft and/or reviewed by IETF
participants. To become Internet Standards, protocols, data
objects, or whatever must go through the IETF standards process and
registration in the IETF tree.
2.4 Additional Registration Trees
From time to time and as required by the community, the IESG may From time to time and as required by the community, the IESG may
create new top-level registration trees. create new top-level registration trees. These trees may require
significant, little or no registration, and may allow change control
to rest in the hands of individuals or groups other than IETF. A
new tree should only be created if an existing tree can be shown to
fail in providing for a clear and specific need of some sector of
the community.
3.0 Requirements for Scheme Name Registration 3.0 Requirements for Scheme Name Registration
3.1 General Requirements 3.1 General Requirements
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 in RFC 2396 for scheme NAMES. conform to the syntax specified in RFC 2396 for scheme NAMES.
3.2 The IETF Tree 3.2 The IETF Tree
skipping to change at line 148 skipping to change at line 141
from risks. Nevertheless, all known security risks must be from risks. Nevertheless, all known security risks must be
identified. identified.
The "owner" of a URL scheme name registered in the IETF tree is The "owner" of a URL scheme name registered 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. specification requires the same level of processing (e.g.
Informational or Standards Track RFC) as used for the initial Informational or Standards Track RFC) as used for the initial
registration. Schemes originally defined via an Informational RFC registration. Schemes originally defined via an Informational RFC
may, however, be replaced with Standards Track documents. may, however, be replaced with Standards Track documents.
3.3 The OID Tree 3.3 Alternative Trees
While public exposure and review of a URL scheme created in the OID While public exposure and review of a URL scheme created in an
tree is not required, using the IETF Internet-Draft mechanism for alternative tree is not required, using the IETF Internet-Draft
peer review is strongly encouraged to improve the quality of the mechanism for peer review is strongly encouraged to improve the
specification. RFC publication of OID tree URL schemes is quality of the specification. RFC publication of alternative tree
encouraged but not required. Material may be published as an URL schemes is encouraged but not required. Material may be
Informational RFC by sending it to the RFC Editor (please follow the published as an Informational RFC by sending it to the RFC Editor
instructions to RFC authors, RFC 2223 [3]). (please follow the instructions to RFC authors, RFC 2223 [3]).
URL schemes created in the OID tree are encouraged to conform to the The defining document for an alternative tree may require public
generic URL syntax, RFC 2396, but are not required to do so. exposure and/or review for schemes defined in that tree via a
mechanism other than the IETF Internet-Draft mechanism.
URL schemes created in an alternative tree are encouraged to conform
to the generic URL syntax, RFC 2396, but are not required to do so.
However, the tree's defining document must set forth the strength of
this requirement.
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] [2]. set forth in RFC [URL-GUIDELINES] [2].
While not required, an analysis of the security issues inherent in While not required, an analysis of the security issues inherent in
the new URL scheme is encouraged. Regardless of what security the new URL scheme is encouraged. Regardless of what security
analysis is or is not performed, all descriptions of security issues analysis is or is not performed, all descriptions of security issues
must be as accurate as possible. In particular, a statement that must be as accurate as possible. In particular, a statement that
there are "no security issues associated with this scheme" must not there are "no security issues associated with this scheme" must not
be confused with "the security issues associates with this scheme be confused with "the security issues associates with this scheme
have not been assessed". have not been assessed" or "the security issues associated with this
scheme cannot be predicted because of <reason>".
There is absolutely no requirement that URL schemes created in the There is absolutely no requirement that URL schemes created in an
OID tree be secure or completely free from risks. Nevertheless, all alternative tree be secure or completely free from risks.
known security risks SHOULD be identified. Nevertheless, the tree's defining document must set forth the
standard for security considerations, and in any event all known
security risks SHOULD be identified.
The registration of a URL scheme created in the OID tree formally Change control must be defined for a new tree. Change control may
belongs to the entity to which the OID is assigned. Changes to the be vested in the IETF, or in an individual, group or other entity.
specification of an OID tree URL scheme which is documented by an The change control standard for the tree must be approved by the
Informational RFC shall only be accepted from the owner of the OID IESG.
or with the permission of the owner of the OID.
The syntax of URL scheme names for schemes created in the OID tree The syntax for alternative trees shall be as follows: each tree will
is simply the text string "OID-" followed by the numeric OID be identified by a unique prefix, which must be established in the
including any embedded hyphens. URL scheme names are case same fashion as a URL scheme name in the IETF tree, except that the
insensitive so the letters in the text string "OID-" need not be prefix must be defined by a Standards Track document. Scheme names
capitalized. No variations on this formula are permitted. in the new tree are then constructed by prepending the prefix to an
identifier unique to each scheme in that tree, as prescribed by that
tree's identifying document:
Examples of valid URL scheme names in the OID tree: <prefix>'-'<tree-specific identifier>
OID-2-16-840-1-113779-2-1: For instance, the "foo" tree would allow creation of scheme names of
Oid-2-16-840-1-113779-2-1-100: the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes
OiD-2-16-840-1-113779-3: an arbitrary USASCII string following the tree's unique prefix.
oid-2-16-840-1-113779-123:
4.0 Registration Procedures 4.0 Registration Procedures
4.1 The IETF Tree 4.1 The IETF Tree
The first step in registering a new URL scheme in the IETF tree is The first step in registering a new URL scheme in the IETF tree is
to publish an IETF Internet-Draft detailing the syntax and to publish an IETF Internet-Draft detailing the syntax and
semantics of the proposed scheme. The draft must, minimally, semantics of the proposed scheme. The draft must, minimally,
address all of the items covered by the template provided in section address all of the items covered by the template provided in section
6 of this document. 6 of this document.
skipping to change at line 215 skipping to change at line 217
After all issues raised during a review period of no less than 4 After all issues raised during a review period of no less than 4
weeks have been addressed, submit the draft to the IESG for review. weeks have been addressed, submit the draft to the IESG for review.
The IESG will review the proposed new scheme and either refer the The IESG will review the proposed new scheme and either refer the
scheme to a working group (existing or new) or directly present the scheme to a working group (existing or new) or directly present the
scheme to the IESG for a last call. In the former case, the working scheme to the IESG for a last call. In the former case, the working
group is responsible for submitting a final version of the draft to group is responsible for submitting a final version of the draft to
the IESG for approval at such time as it has received adequate the IESG for approval at such time as it has received adequate
review and deliberation. review and deliberation.
4.2 The OID Tree 4.2 Alternative Trees
Registration of URL schemes created in the OID tree is automatic Registration of URL schemes created in an alternative tree may be
because the scheme name is based on a previously registered entity, formal, through IETF documents, IANA registration, or other
an OID. There is no requirement to publish any documentation for acknowledged organization; informal, through a mailing list or
the URL scheme, however, doing so may be advantageous and is other publication mechanism; or nonexistent. The registration
encouraged. mechanism must be documented for each alternative tree, and must be
consistent for all URL scheme names created in that tree.
The recommended form for documenting a URL scheme created in the OID It is the responsibility of the creator of the tree's registration
tree is via an Informational RFC. The RFC should address all of the requirements to establish that the registration mechanism is
items covered by the template provided in section 6 of this workable as described; it is within the discretion of the IESG to
document. reject the document describing a tree if it determines the
registration mechanism is impractical or creates an undue burden on
a party who will not accept it. (For instance, if an IANA
registration mechanism is proposed, IESG might reject the tree if
its mechanism would create undue liability on the part of IANA.)
While the template in section 6 of this document is intended to
apply to URL scheme names in the IETF tree, it is also offered as a
guideline for those documenting alternative trees.
5.0 Change Control 5.0 Change Control
5.1 Schemes in the IETF Tree 5.1 Schemes in the IETF Tree
URL schemes created in the IETF tree are "owned" by the IETF itself URL schemes created in the IETF tree are "owned" by the IETF itself
and may be changed, as needed, by updating the RFC that describes and may be changed, as needed, by updating the RFC that describes
them. Schemes described by Standards Track RFC but be replaced with them. Schemes described by Standards Track RFC but be replaced with
new Standards Track RFCs. Informational RFCs may be replaced by new new Standards Track RFCs. Informational RFCs may be replaced by new
Informational RFCs or Standards Track RFCs. Informational RFCs or Standards Track RFCs.
5.2 Schemes in the OID Tree 5.2 Schemes in Alternative Trees
Undocumented URL schemes created in the OID tree may be changed by Undocumented URL schemes created in an alternative tree may be
their owner at any time without notifying the IETF. changed by their owner at any time without notifying the IETF.
URL schemes created in the OID tree that have been documented by an URL schemes created in an alternative tree that have been documented
Informational RFC, may be changed at any time by the owner, however, by an Informational RFC, may be changed at any time by the owner,
an updated Informational RFC which details the changes made, must be however, an updated Informational RFC which details the changes
submitted to the IESG. made, must be submitted to the IESG.
The owner of a URL scheme registered in the OID tree and documented The owner of a URL scheme registered in an alternative tree and
by an Informational RFC may pass responsibility for the registration documented by an Informational RFC may pass responsibility for the
to another person or agency by informing the IESG. registration to another person or agency by informing the IESG.
The IESG may reassign responsibility for a URL scheme registered in The IESG may reassign responsibility for a URL scheme registered in
the OID tree and documented by an Informational RFC. The most an alternative tree and documented by an Informational RFC. 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 owner of the OID has died, moved out of contact or is schemes where the scheme name is privately owned by the rules of its
otherwise unable to make changes that are important to the tree, and the owner of the scheme name has died, moved out of
community. contact or is otherwise unable to make changes that are important to
the community.
The IESG may reclassify a URL scheme created in the OID tree and The IESG may reclassify a URL scheme created in an alternative tree
documented via an Informational RFC as "historic" if it determines and documented via an Informational RFC as "historic" if it
that the scheme is no longer in use. determines that the scheme is no longer in use.
6.0 Registration Template 6.0 Registration Template
The following issues should be addressed when documenting a new URL The following issues should be addressed when documenting a new URL
scheme: scheme:
URL scheme name. URL scheme name.
URL scheme syntax. This should be expressed in a clear and URL scheme syntax. This should be expressed in a clear and
concise manner. The use of ABNF is encouraged. Please refer to concise manner. The use of ABNF is encouraged. Please refer to
skipping to change at line 319 skipping to change at line 331
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 documentation, vulnerabilities may need to be attached to existing documentation,
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.
If the IESG agrees to delegate the registration and change control
functions of an alternative tree to a group or individual outside of
the IETF, that group or individual should have sufficient security
procedures in place to authenticate registration changes.
8.0 References 8.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 2396, August 1998 Identifiers (URI): Generic Syntax", RFC 2396, 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 "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August
1998 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.
9.0 Author's Address 9.0 Authors' Address
Rich Petke Rich Petke
MCIWORLDCOM Advanced Networks MCI 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 8407 Fax: +1 614 723 8407
EMail: rpetke@wcom.net EMail: rpetke@wcom.net
Appendix A -- Grandfathered URL Scheme Names Ian King
Microsoft Corporation
A number of URL scheme names, in use prior to 1998, would, if One Microsoft Way
registered under the procedures specified in this document, be Redmond, WA 98052-6399
placed into the OID tree. Re-registration of those types to reflect USA
the appropriate tree or documentation of the schemes in an Phone: +1 425-703-2293
Informational RFC is encouraged, but not required. Ownership and FAX: +1 425-936-7329
change control principles outlined in this document apply to those Email: iking@microsoft.com
types as if they had been registered in the OID tree.
ABOUT: (No information available at this time.)
AOL: (No information available at this time.)
 End of changes. 30 change blocks. 
89 lines changed or deleted 105 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/