draft-ietf-urlreg-procedures-06.txt   draft-ietf-urlreg-procedures-07.txt 
Ian King <iking@microsoft.com>
Speech Product Group
MICROSOFT CORPORATION
INTERNET-DRAFT R. Petke INTERNET-DRAFT R. Petke
<draft-ietf-urlreg-procedures-06.txt> UUNET Technologies <draft-ietf-urlreg-procedures-07.txt> UUNET Technologies
I. King I. King
Microsoft Corporation Microsoft Corporation
March 30, 1999 August 12, 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 and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Internet-Drafts distribute working documents as Internet-Drafts. Internet-Drafts
are draft documents valid for a maximum of six months and may be are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as reference material or to is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress." The list of current cite them other than as "work in progress."
Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- The list of current Internet-Drafts can be accessed at
Draft Shadow Directories can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this Internet-Draft is unlimited. Distribution of this Internet-Draft is unlimited.
This Internet-Draft expires September 30, 1999. This Internet-Draft expires March 12, 2000.
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 62 skipping to change at line 67
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 the registration procedures to be followed This document defines the registration procedures to be followed
when new URL schemes are created. A separate document, RFC when new URL schemes are created. A separate document, RFC
[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.
1.1 Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
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, the need is recognized for scheme name registration process, the need is recognized for
multiple registration "trees". The registration requirements and multiple registration "trees". The registration requirements and
specific registration procedures for each tree differ, allowing the specific registration procedures for each tree differ, allowing the
overall 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
skipping to change at line 125 skipping to change at line 136
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.
The NAMES of schemes registered in the IETF tree MUST NOT contain The NAMES of schemes registered in the IETF tree MUST NOT contain
the dash (also known as the hyphen and minus sign) character ('-') the dash (also known as the hyphen and minus sign) character ('-')
USASCII value 2Dh. Use of this character can cause confusion with USASCII value 2Dh. Use of this character can cause confusion with
schemes registered in alternative trees (see section 3.3). 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
REQUIRED. (This is in accordance with the basic requirements for is REQUIRED. (This is in accordance with the basic requirements for
all IETF protocols.) There is absolutely no requirement that all all IETF protocols.) URL schemes registered in the IETF tree should
URL schemes registered in the IETF tree be secure or completely free not introduce additional security risks into the Internet Architec-
from risks. Nevertheless, all known security risks must be ture. For example, URLs should not embed information which should
identified. remain confidential, such as passwords, nor should new schemes
subvert the security of existing schemes or protocols (i.e. by
layering or tunneling).
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 Alternative Trees 3.3 Alternative Trees
 End of changes. 7 change blocks. 
13 lines changed or deleted 26 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/