rfc2717.txt

RFC 的详细文档！

Network Working Group                                          R. Petke
Request for Comments: 2717                           UUNET Technologies
BCP: 35                                                         I. King
Category: Best Current Practice                   Microsoft Corporation
                                                          November 1999


              Registration Procedures for URL Scheme Names

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document defines the process by which new URL scheme names are
   registered.

1.0 Introduction

   A Uniform Resource Locator (URL) is a compact string representation
   of the location for a resource that is available via the Internet.
   RFC 2396 [1] defines the general syntax and semantics of URIs, and,
   by inclusion, URLs.  URLs are designated by including a "<scheme>:"
   and then a "<scheme-specific-part>".  Many URL schemes are already
   defined, however, new schemes may need to be defined in the future in
   order to accommodate new Internet protocols and/or procedures.

   A registration process is needed to ensure that the names of all such
   new schemes are guaranteed not to collide.  Further, the registration
   process ensures that URL schemes intended for wide spread, public use
   are developed in an orderly, well-specified, and public manner.

   This document defines the registration procedures to be followed when
   new URL schemes are created.  A separate document, RFC 2718,
   Guidelines for URL Schemes [2], provides guidelines for the creation
   of new URL schemes.  The primary focus of this document is on the
   <scheme> portion of new URL schemes, referred to as the "scheme name"
   throughout this document.






Petke & King             Best Current Practice                  [Page 1]

RFC 2717      Registration Procedures for URL Scheme Names November 1999


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.1 General

   In order to increase the efficiency and flexibility of the URL scheme
   name registration process, the need is recognized for multiple
   registration "trees".  The registration requirements and specific
   registration procedures for each tree differ, allowing the overall
   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 intended to
   be used for resources associated with proprietary software.

   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 and the desired syntax for the scheme
   name.

   This document will discuss in detail the tree that reflects current
   practice, under IETF ownership and control.  It will also set forth
   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

   The IETF tree is intended for URL schemes of general interest to the
   Internet community.  The tree exists for URL schemes that require a
   substantive review and approval process.  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.










Petke & King             Best Current Practice                  [Page 2]

RFC 2717      Registration Procedures for URL Scheme Names November 1999


2.3 Additional Registration Trees

   From time to time and as required by the community, the IESG may
   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 no existing tree can be shown to
   address the set of needs of some sector of the community.

3.0 Requirements for Scheme Name Registration

3.1 General Requirements

   All new URL schemes, regardless of registration tree, MUST conform to
   the generic syntax for URLs as specified in RFC 2396.

3.2 The IETF Tree

   Registration in the IETF tree requires publication of the URL scheme
   syntax and semantics in either an Informational or Standards Track
   RFC. In general, the creation of a new URL scheme requires a
   Standards Track RFC.  An Informational RFC may be employed for
   registration only in the case of a URL scheme which is already in
   wide usage and meets other standards set forth in RFC 2718, such as
   "demonstrated utility" within the Internet Architecture; the IESG
   shall have broad discretion in determining whether an Informational
   RFC is suitable in any given case, and may either recommend changes
   to such document prior to publication, or reject it for publication.
   An Informational RFC purporting to describe a URL scheme shall not be
   published without IESG approval.  This is a departure from practice
   for Informational RFCs as set forth in RFC 2026, for the purpose of
   ensuring that the registration of URL schemes shall serve the best
   interests of the Internet community.

   The NAMES of schemes registered in the IETF tree MUST NOT contain the
   dash (also known as the hyphen and minus sign) character ('-')
   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
   REQUIRED. (This is in accordance with the basic requirements for all
   IETF protocols.) URL schemes registered in the IETF tree should not
   introduce additional security risks into the Internet Architecture.
   For example, URLs should not embed information which should remain
   confidential, such as passwords, nor should new schemes subvert the
   security of existing schemes or protocols (i.e. by layering or
   tunneling).




Petke & King             Best Current Practice                  [Page 3]

RFC 2717      Registration Procedures for URL Scheme Names November 1999


   The "owner" of a URL scheme name registered in the IETF tree is
   assumed to be the IETF itself.  Modification or alteration of the
   specification requires the same level of processing (e.g.
   Informational or Standards Track RFC) as used for the initial
   registration.  Schemes originally defined via an Informational RFC
   may, however, be replaced with Standards Track documents.

3.3  Alternative Trees

   While public exposure and review of a URL scheme created in an
   alternative tree is not required, using the IETF Internet-Draft
   mechanism for peer review is strongly encouraged to improve the
   quality of the specification.  RFC publication of alternative tree
   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]).

   The defining document for an alternative tree may require public
   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 must conform to the
   generic URL syntax, RFC 2396.  The tree's defining document may set
   forth additional syntax and semantics requirements above and beyond
   those specified in RFC 2396.

   All new URL schemes SHOULD follow the Guidelines for URL Schemes, set
   forth in RFC 2718 [2].

   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"
   or "the security issues associated with this scheme cannot be
   predicted because of <reason>".

   There is absolutely no requirement that URL schemes created in an
   alternative tree be secure or completely free from risks.
   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.

   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.  The
   change control standard for the tree must be approved by the IESG.




Petke & King             Best Current Practice                  [Page 4]

RFC 2717      Registration Procedures for URL Scheme Names November 1999


   The syntax for alternative trees shall be as follows: each tree will
   be identified by a unique prefix, which must be established in the
   same fashion as a URL scheme name in the IETF tree, except that the
   prefix must be defined by a Standards Track document.  Scheme names
   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:

      <prefix>'-'<tree-specific identifier>

   For instance, the "foo" tree would allow creation of scheme names of
   the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes
   an arbitrary USASCII string following the tree's unique prefix.

4.0 Registration Procedures

4.1 The IETF Tree

   The first step in registering a new URL scheme in the IETF tree is to
   publish an IETF Internet-Draft detailing the syntax and semantics of
   the proposed scheme.  The draft must, minimally, address all of the
   items covered by the template provided in section 6 of this document.

   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.

   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 the IESG for a last call.  In the former case, the working
   group is responsible for submitting a final version of the draft to
   the IESG for approval at such time as it has received adequate review
   and deliberation.

4.2 Alternative Trees

   Registration of URL schemes created in an alternative tree may be
   formal, through IETF documents, IANA registration, or other
   acknowledged organization; informal, through a mailing list or other
   publication mechanism; or nonexistent.  The registration mechanism
   must be documented for each alternative tree, and must be consistent
   for all URL scheme names created in that tree.

   It is the responsibility of the creator of the tree's registration
   requirements to establish that the registration mechanism is workable
   as described; it is within the discretion of the IESG to reject the
   document describing a tree if it determines the registration
   mechanism is impractical or creates an undue burden on a party who




Petke & King             Best Current Practice                  [Page 5]