INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-procedures-04.txt>     MCIWORLDCOM Advanced Networks
                                                       November 1, 1998



             Registration Procedures for URL Scheme Names



Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.ietf.org (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

   This Internet-Draft expires April 30, 1999.

   Copyright Notice

   Copyright (C) The Internet Society (1998).  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
   [URL-GUIDELINES], 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.


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, two different registration "trees"
   have been created.  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.

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


2.3 The OID Tree

   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
   create new top-level registration trees.


3.0 Requirements for Scheme Name Registration

3.1 General Requirements

   All new URL scheme NAMES, regardless of registration tree, MUST
   conform to the syntax specified in RFC 2396 for scheme NAMES.


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 addition to having a conforming scheme NAME (see section 3.1),
   all new URL schemes registered in the IETF tree, MUST conform to the
   generic syntax for URLs as specified in RFC 2396.

   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 "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 The OID Tree

   While public exposure and review of a URL scheme created in the OID
   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 OID 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]).

   URL schemes created in the OID tree are encouraged to conform to the
   generic URL syntax, RFC 2396, but are not required to do so.

   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 created in the
   OID tree be secure or completely free from risks.  Nevertheless, all
   known security risks SHOULD be identified.

   The registration of a URL scheme created in the OID tree formally
   belongs to the entity to which the OID is assigned.  Changes to the
   specification of an OID tree URL scheme which is documented by an
   Informational RFC shall only be accepted from the owner of the OID
   or with the permission of the owner of the OID.

   The syntax of URL scheme names for schemes created in the OID tree
   is simply the text string "OID-" followed by the numeric OID
   including any embedded hyphens.  URL scheme names are case
   insensitive so the letters in the text string "OID-" need not be
   capitalized.  No variations on this formula are permitted.

   Examples of valid URL scheme names in the OID tree:

      OID-2-16-840-1-113779-2-1:
      Oid-2-16-840-1-113779-2-1-100:
      OiD-2-16-840-1-113779-3:
      oid-2-16-840-1-113779-123:


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 The OID Tree

   Registration of URL schemes created in the OID tree is automatic
   because the scheme name is based on a previously registered entity,
   an OID.  There is no requirement to publish any documentation for
   the URL scheme, however, doing so may be advantageous and is
   encouraged.

   The recommended form for documenting a URL scheme created in the OID
   tree is via an Informational RFC.  The RFC should address all of the
   items covered by the template provided in section 6 of this
   document.


5.0 Change Control

5.1 Schemes in the IETF Tree

   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
   them.  Schemes described by Standards Track RFC but be replaced with
   new Standards Track RFCs.  Informational RFCs may be replaced by new
   Informational RFCs or Standards Track RFCs.


5.2 Schemes in the OID Tree

   Undocumented URL schemes created in the OID tree may be changed by
   their owner at any time without notifying the IETF.

   URL schemes created in the OID tree that have been documented by an
   Informational RFC, may be changed at any time by the owner, however,
   an updated Informational RFC which details the changes made, must be
   submitted to the IESG.

   The owner of a URL scheme registered in the OID tree and documented
   by an Informational RFC may pass responsibility for the registration
   to another person or agency by informing the IESG.

   The IESG may reassign responsibility for a URL scheme registered in
   the OID tree and documented by an Informational RFC.  The most
   common case of this will be to enable changes to be made to schemes
   where the owner of the OID has died, moved out of 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
   documented via an Informational RFC as "historic" if it determines
   that the scheme is no longer in use.


6.0  Registration Template

   The following issues should be addressed when documenting a new URL
   scheme:

      URL scheme name.

      URL scheme syntax.  This should be expressed in a clear and
      concise manner.  The use of ABNF is encouraged.  Please refer to
      RFC [URL-GUIDELINES] for guidance on designing and explaining
      your scheme's syntax.

      Character encoding considerations.  It is important to identify
      what your scheme supports in this regard.  It is obvious that for
      interoperability, it is best if there is a means to support
      character sets beyond USASCII, but especially for private
      schemes, this may not be the case.

      Intended usage.  What sort of resource is being identified?  If
      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
      there is a MIME type associated with this resource, please
      identify it.

      Applications and/or protocols which use this URL scheme name.

      Interoperability considerations.  If you are aware of any details
      regarding your scheme which might impact interoperability, please
      identify them here.  For example: proprietary or uncommon
      encoding method; inability to support multibyte character sets;
      incompatibility with types or versions of underlying protocol
      (if scheme is tunneled over another protocol).

      Security considerations.

      Relevant publications.

      Person & email address to contact for further information.

      Author/Change controller.


Applications and/or protocols which use this URL scheme name.



7.0 Security Considerations

   Information that creates or updates a registration needs to be
   authenticated.

   Information concerning possible security vulnerabilities of a
   protocol may change over time.  Consequently, claims as to the
   security properties of a registered URL scheme may change as well.
   As new vulnerabilities are discovered, information about such
   vulnerabilities may need to be attached to existing documentation,
   so that users are not misled as to the true security properties of a
   registered URL scheme.


8.0 References

   [1]  Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998

   [2]  Masinter, L., Alvestrand, H., Zigmond, D., Petke, R.,
        "Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August
        1998

   [3]  Postel, J., Reynolds, J., "Instructions to RFC Authors",
        RFC 2223, October 1997.


9.0  Author's Address

   Rich Petke
   MCIWORLDCOM Advanced Networks
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 43026-5000
   USA

   Phone: +1 614 723 4157
   Fax:   +1 614 723 8407
   EMail: rpetke@wcom.net


Appendix A -- Grandfathered URL Scheme Names

   A number of URL scheme names, in use prior to 1998, would, if
   registered under the procedures specified in this document, be
   placed into the OID tree.  Re-registration of those types to reflect
   the appropriate tree or documentation of the schemes in an
   Informational RFC is encouraged, but not required.  Ownership and
   change control principles outlined in this document apply to those
   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.)