draft-ietf-urlreg-procedures-05.txt   draft-ietf-urlreg-procedures-06.txt 
INTERNET-DRAFT R. Petke INTERNET-DRAFT R. Petke
<draft-ietf-urlreg-procedures-05.txt> MCI WorldCom Advanced Networks <draft-ietf-urlreg-procedures-06.txt> UUNET Technologies
I. King I. King
Microsoft Corporation Microsoft Corporation
January 25, 1999 March 30, 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 and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026. Internet-Drafts are
and its working groups. Note that other groups may also distribute working documents of the Internet Engineering Task Force (IETF), its
working documents as Internet-Drafts. areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Internet-Drafts
Internet-Drafts are draft documents valid for a maximum of six are draft documents valid for a maximum of six months and may be
months and may be updated, replaced, or obsoleted by other documents updated, replaced, or obsoleted by other documents at any time. It
at any time. It is inappropriate to use Internet-Drafts as is inappropriate to use Internet-Drafts as reference material or to
reference material or to cite them other than as "work in progress." cite them other than as "work in progress." The list of current
Internet-Drafts can be accessed at
To learn the current status of any Internet-Draft, please check the http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Draft Shadow Directories can be accessed at
Directories on ftp.ietf.org (US East Coast), nic.nordu.net http://www.ietf.org/shadow.html.
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this memo is unlimited. Distribution of this Internet-Draft is unlimited.
This Internet-Draft expires July 25, 1999. This Internet-Draft expires September 30, 1999.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). 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.
skipping to change at line 106 skipping to change at line 104
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 Additional Registration Trees 2.3 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. These trees may require create new top-level registration trees. These trees may require
significant, little or no registration, and may allow change control significant, little or no registration, and may allow change control
to rest in the hands of individuals or groups other than IETF. A 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 new tree should only be created if no existing tree can be shown to
fail in providing for a clear and specific need of some sector of address the set of needs of some sector of the community.
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 schemes, regardless of registration tree, MUST conform
conform to the syntax specified in RFC 2396 for scheme NAMES. to the generic syntax for URLs as specified in RFC 2396.
3.2 The IETF Tree 3.2 The IETF Tree
Registration in the IETF tree requires publication of the URL scheme Registration in the IETF tree requires publication of the URL scheme
syntax and semantics in either an Informational or Standards Track syntax and semantics in either an Informational or Standards Track
RFC. RFC.
In addition to having a conforming scheme NAME (see section 3.1), The NAMES of schemes registered in the IETF tree MUST NOT contain
all new URL schemes registered in the IETF tree, MUST conform to the the dash (also known as the hyphen and minus sign) character ('-')
generic syntax for URLs as specified in RFC 2396. USASCII value 2Dh. Use of this character can cause confusion with
schemes registered in alternative trees (see section 3.3).
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. (This is in accordance with the basic requirements for REQUIRED. (This is in accordance with the basic requirements for
all IETF protocols.) There is absolutely no requirement that all all IETF protocols.) There is absolutely no requirement that all
URL schemes registered in the IETF tree be secure or completely free URL schemes registered in the IETF tree be secure or completely free
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
skipping to change at line 155 skipping to change at line 153
mechanism for peer review is strongly encouraged to improve the mechanism for peer review is strongly encouraged to improve the
quality of the specification. RFC publication of alternative tree quality of the specification. RFC publication of alternative tree
URL schemes is encouraged but not required. Material may be URL schemes is encouraged but not required. Material may be
published as an Informational RFC by sending it to the RFC Editor published as an Informational RFC by sending it to the RFC Editor
(please follow the instructions to RFC authors, RFC 2223 [3]). (please follow the instructions to RFC authors, RFC 2223 [3]).
The defining document for an alternative tree may require public The defining document for an alternative tree may require public
exposure and/or review for schemes defined in that tree via a exposure and/or review for schemes defined in that tree via a
mechanism other than the IETF Internet-Draft mechanism. mechanism other than the IETF Internet-Draft mechanism.
URL schemes created in an alternative tree are encouraged to conform URL schemes created in an alternative tree must conform to the
to the generic URL syntax, RFC 2396, but are not required to do so. generic URL syntax, RFC 2396. The tree's defining document may set
However, the tree's defining document must set forth the strength of forth additional syntax and semantics requirements above and
this requirement. beyond those specified in RFC 2396.
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 An analysis of the security issues inherent in the new URL scheme is
the new URL scheme is encouraged. Regardless of what security encouraged. Regardless of what security analysis is or is not
analysis is or is not performed, all descriptions of security issues performed, all descriptions of security issues must be as accurate
must be as accurate as possible. In particular, a statement that as possible. In particular, a statement that there are "no security
there are "no security issues associated with this scheme" must not issues associated with this scheme" must not be confused with "the
be confused with "the security issues associates with this scheme security issues associates with this scheme have not been assessed"
have not been assessed" or "the security issues associated with this or "the security issues associated with this scheme cannot be
scheme cannot be predicted because of <reason>". predicted because of <reason>".
There is absolutely no requirement that URL schemes created in an There is absolutely no requirement that URL schemes created in an
alternative tree be secure or completely free from risks. alternative tree be secure or completely free from risks.
Nevertheless, the tree's defining document must set forth the Nevertheless, the tree's defining document must set forth the
standard for security considerations, and in any event all known standard for security considerations, and in any event all known
security risks SHOULD be identified. security risks SHOULD be identified.
Change control must be defined for a new tree. Change control may Change control must be defined for a new tree. Change control may
be vested in the IETF, or in an individual, group or other entity. be vested in the IETF, or in an individual, group or other entity.
The change control standard for the tree must be approved by the The change control standard for the tree must be approved by the
skipping to change at line 251 skipping to change at line 249
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 Alternative Trees 5.2 Schemes in Alternative Trees
Undocumented URL schemes created in an alternative tree may be URL schemes in an alternative tree that are undocumented (as allowed
changed by their owner at any time without notifying the IETF. by that tree's rules) may be changed by their owner at any time
without notifying the IETF.
URL schemes created in an alternative tree that have been documented URL schemes created in an alternative tree that have been documented
by an Informational RFC, may be changed at any time by the owner, by an Informational RFC, may be changed at any time by the owner,
however, an updated Informational RFC which details the changes however, an updated Informational RFC which details the changes
made, must be submitted to the IESG. made, must be submitted to the IESG.
The owner of a URL scheme registered in an alternative tree and The owner of a URL scheme registered in an alternative tree and
documented by an Informational RFC may pass responsibility for the documented by an Informational RFC may pass responsibility for the
registration to another person or agency by informing the IESG. registration to another person or agency by informing the IESG.
skipping to change at line 300 skipping to change at line 299
character sets beyond USASCII, but especially for private character sets beyond USASCII, but especially for private
schemes, this may not be the case. schemes, this may not be the case.
Intended usage. What sort of resource is being identified? If Intended usage. What sort of resource is being identified? If
this is not a 'resource' type of URL (e.g. mailto:), explain the this is not a 'resource' type of URL (e.g. mailto:), explain the
action that should be initiated by the consumer of the URL. If action that should be initiated by the consumer of the URL. If
there is a MIME type associated with this resource, please there is a MIME type associated with this resource, please
identify it. identify it.
Applications and/or protocols which use this URL scheme name. Applications and/or protocols which use this URL scheme name.
Including references to documentation which defines the
applications and/or protocols cited is especially useful.
Interoperability considerations. If you are aware of any details Interoperability considerations. If you are aware of any details
regarding your scheme which might impact interoperability, please regarding your scheme which might impact interoperability, please
identify them here. For example: proprietary or uncommon identify them here. For example: proprietary or uncommon
encoding method; inability to support multibyte character sets; encoding method; inability to support multibyte character sets;
incompatibility with types or versions of underlying protocol incompatibility with types or versions of underlying protocol
(if scheme is tunneled over another protocol). (if scheme is tunneled over another protocol).
Security considerations. Security considerations.
skipping to change at line 351 skipping to change at line 352
[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 Authors' Address 9.0 Authors' Address
Rich Petke Rich Petke
MCI WorldCom Advanced Networks UUNET Technologies
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
Ian King Ian King
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Phone: +1 425-703-2293 Phone: +1 425-703-2293
FAX: +1 425-936-7329 FAX: +1 425-936-7329
Email: iking@microsoft.com Email: iking@microsoft.com
 End of changes. 14 change blocks. 
43 lines changed or deleted 44 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/