INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-procedures-02.txt>        WorldCom Advanced Networks
                                                          July 17, 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 view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

   Distribution of this memo is unlimited.

   This Internet Draft expires January 15, 1999.

Copyright Notice

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

Abstract

   This document defines the process by which new URL schemes 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 [URI-SYNTAX] [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 registration procedures which use the Internet
   Assigned Numbers Authority (IANA) as a central registry for such URL
   scheme names and the IETF RFC mechanism for scheme review, where
   appropriate.


2.0  URL Scheme Name Registration

   Registration of a new URL scheme name starts with the construction
   of a registration proposal.  Registration may occur in several
   different registration trees, which have different requirements as
   discussed below.  In general, the new registration proposal is
   circulated and reviewed in a fashion appropriate to the tree
   involved.  The URL scheme name is then registered if the proposal is
   acceptable.  The following sections describe the requirements and
   procedures used for each of the different registration trees.


2.1.  Registration Trees and URL Schemes

   In order to increase the efficiency and flexibility of the
   registration process, three different formats of URL scheme names
   may be registered.  The registration requirements for each format
   differ allowing the 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 that is used with resources associated with proprietary
   software.  The following subsections define registration "trees" and
   the associated URL scheme name formats available at this time.  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.1.1.  IETF Tree

   The IETF tree is intended for URL schemes of general interest to the
   Internet Community.  Registration in the IETF tree requires approval
   by the IESG and publication of the URL scheme syntax and semantics
   as some form of RFC, usually a standards track RFC.

   URL scheme names in the IETF tree are normally denoted by names that
   are not explicitly faceted, i.e., do not contain period (".")
   characters.

   The "owner" of a URL scheme name registration 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. standards
   track) as required for the initial registration.


2.1.2.  Vendor Tree

   The vendor tree is used for URL schemes associated with commercially
   available products.  "Vendor" or "producer" are construed as
   equivalent and very broadly in this context.

   A registration may be placed in the vendor tree by anyone who needs
   to identify a scheme for (1) specifying the location of a resource
   available via the Internet (2) which may be accessed using a
   protocol (or mechanism) for which there is not currently a URL
   scheme registered in the IETF tree.  The registration formally
   belongs to the vendor or organization registering the scheme name.
   Changes to the specification will be made at their request, as
   discussed in subsequent sections.

   Registrations in the vendor tree will be distinguished by the
   leading facet "vnd.".  That must be followed by an IANA-approved
   designation of the producer's name, which is then followed by a URL
   scheme name or product designation (e.g. vnd.bigcompany.telepathic).

   IANA will assign unique designations for producer names,
   ("bigcompany" in the example above).  Accordingly, once a producer
   has successfully registered a scheme name, (e.g.
   "vnd.bigcompany.telepathic"), only registrations for new scheme
   names that originate from "bigcompany" will begin with
   "vnd.bigcompany.".

   While public exposure and review of URL scheme names to be
   registered in the vendor tree is not required, using the ietf-types
   list for review is strongly encouraged to improve the quality of
   those specifications.  Registrations in the vendor tree may be
   submitted directly to the IANA.


2.1.3.  Personal or Vanity Tree

   Registrations for URL schemes created experimentally or as part of
   products that are not distributed commercially may be registered in
   the personal or vanity tree.  The registrations are distinguished by
   the leading facet "prs.".

   The owner of "personal" registrations and associated specifications
   is the person or entity making the registration, or one to whom
   responsibility has been transferred as described below.

   While public exposure and review of URL scheme names to be
   registered in the personal tree is not required, using the
   ietf-types list for review is strongly encouraged to improve the
   quality of those specifications.  Registrations in the personal tree
   may be submitted directly to the IANA.


2.1.4.  Additional Registration Trees

   From time to time and as required by the community, the IANA may,
   with the advice and consent of the IESG, create new top-level
   registration trees.  It is explicitly assumed that these trees may
   be created for external registration and management by well-known
   permanent bodies, such as scientific societies, for URL schemes
   specific to the sciences they cover.  In general, the quality of
   review of specifications for one of these additional registration
   trees is expected to be equivalent to that which IETF would give to
   registrations in its own tree.  Establishment of these new trees
   will be announced through RFC publication approved by the IESG.


2.2.  Registration Requirements

   URL scheme name registration proposals are all expected to conform
   to various requirements laid out in the following sections.  Note
   that requirement specifics sometimes vary depending on the
   registration tree, again as detailed in the following sections.


2.2.1. Scheme Names

   All new URL scheme names, regardless of registration tree, MUST
   conform to the syntax specified for scheme names in RFC [URI-SYNTAX].


2.2.2. URL Syntax

   All new URL schemes registered in the IETF tree, MUST conform to the
   generic syntax for URLs as specified in RFC [URI-SYNTAX].  URL
   schemes registered in the vendor and personal trees are encouraged
   to conform to the generic syntax but are not required to do so in
   order to be registered.

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


2.2.3.  Security Requirements

   An analysis of the security issues inherent in the new URL scheme is
   required for all registrations in the IETF tree.  (This is in
   accordance with the basic requirements for all IETF protocols.)  A
   similar analysis for schemes registered in the vendor or personal
   trees is encouraged but not required.  However, regardless of what
   security analysis has or has not been done, all descriptions of
   security issues must be as accurate as possible regardless of
   registration tree.  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 registered in
   any tree be secure or completely free from risks.  Nevertheless, all
   known security risks must be identified in the registration of a URL
   scheme name, again regardless of registration tree.

   The security considerations section of all registrations is subject
   to continuing evaluation and modification, and in particular may be
   extended by use of the "comments on URL scheme name" mechanism
   described in subsequent sections.


2.2.4.  Publication Requirements

   Proposals for URL schemes registered in the IETF tree must be
   published as RFCs.  RFC publication of vendor and personal URL
   schemes is encouraged but not required.  In all cases IANA will
   retain copies of all URL scheme proposals and "publish" them as part
   of the URL scheme names registration tree itself.

   Other than in the IETF tree, the registration of a URL scheme name
   does not imply endorsement, approval, or recommendation by IANA or
   IETF or even certification that the specification is adequate.  To
   become Internet Standards, protocol, data objects, or whatever must
   go through the IETF standards process.  This is too difficult and
   too lengthy a process for the convenient registration of URL scheme
   names.

   The IETF tree exists for URL schemes that do require a substantive
   review and approval process with the vendor and personal trees exist
   for those that do not. 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.

   As discussed above, registration of a top-level type requires
   standards-track processing and, hence, RFC publication.


2.3.  Registration Procedure

   The following procedure has been implemented by the IANA for review
   and approval of new URL scheme names.  This is not a formal
   standards process, but rather an administrative procedure intended
   to allow community comment and sanity checking without excessive
   time delay.  For registration in the IETF tree, the normal IETF
   processes should be followed, treating posting of an internet-draft
   and announcement on the ietf-types list (as described in the next
   subsection) as a first step.  For registrations in the vendor or
   personal tree, the initial review step described below may be
   omitted and the URL scheme name may be registered directly by
   submitting the template and an explanation directly to IANA
   (at iana@iana.org).  However, authors of vendor or personal URL
   scheme specifications are encouraged to seek community review and
   comment whenever that is feasible.


2.3.1.  Present the URL scheme name to the Community for Review

   Send a proposed URL scheme name registration to the
   "ietf-types@iana.org" mailing list for a two week review period.
   This mailing list has been established for the purpose of reviewing
   proposed URL schemes.  URL scheme names proposed to this mailing
   list are not formally registered and should not be used until the
   registration procedure is complete.

   The intent of the public posting is to solicit comments and feedback
   on the choice of scheme name, the syntax and semantics of the
   scheme, and a review of any interoperability or security
   considerations.  The submitter may submit a revised registration, or
   withdraw the registration completely, at any time.


2.3.2.  IESG Approval

   URL scheme names registered in the IETF tree must be submitted to
   the IESG for approval.


2.3.3.  IANA Registration

   Provided that the URL scheme name meets the requirements for URL
   scheme names and has obtained approval that is necessary, the author
   may submit the registration request to the IANA, which will register
   the scheme name and make the URL scheme name registration available
   to the community.


2.4.  Comments on URL Scheme Name Registrations

   Comments on registered URL scheme names may be submitted by members
   of the community to IANA.  These comments will be passed on to the
   "owner" of the URL scheme name if possible.  Submitters of comments
   may request that their comment be attached to the URL scheme name
   registration itself, and if IANA approves of this the comment will
   be made accessible in conjunction with the scheme name registration
   itself.


2.5.  Location of Registered URL Scheme Name List

   URL scheme name registrations will be posted in the anonymous FTP
   directory
   "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/".
   The scheme syntax and semantics description and other supporting
   material may also be published as an Informational RFC by sending it
   to the RFC Editor (please follow the instructions to RFC authors,
   RFC-2223 [3]).


2.6.  IANA Procedures for Registering URL scheme names

   The IANA will only register URL scheme names in the IETF tree in
   response to a communication from the IESG stating that a given
   registration has been approved. Vendor and personal types will be
   registered by the IANA automatically and without any formal review
   as long as the following minimal conditions are met:

   Scheme Name Syntax:  The syntax of the requested scheme name
   (including the assigned producer designation in the case of vendor
   tree registrations), MUST conform to the syntax for such as
   specified in RFC [URI-SYNTAX].  While encouraged, the syntax for the
   actual scheme does not have to conform to the general syntax
   specified in RFC [URI-SYNTAX].

   Security Considerations:  The application for registration of a
   scheme name MUST include a discussion of the security
   considerations inherent in the scheme.

   Contact Person:  The application MUST include accurate information
   regarding a person to contact about the registration.

   Author/Change Controller:  The application must specify the author
   and/or entity responsible for change control of the proposed scheme.

   For vendor tree registrations, IANA will assign unique designations
   to each producer registering one or more scheme names.


2.7.  Change Control

   Once a URL scheme name has been published by IANA, the author may
   request a change to its definition. The descriptions of the
   different registration trees above designate the "owners" of each
   type of registration.  The change request follows the same
   procedure as the registration request:

    (1)   Publish the revised scheme syntax and semantics on the
          ietf-types list.

    (2)   Leave at least two weeks for comments.

    (3)   Publish using IANA after formal review if required.

   Changes should be requested only when there are serious omission or
   errors in the published specification.  When review is required, a
   change request may be denied if it renders entities that were valid
   under the previous definition invalid under the new definition.

   The owner of a URL scheme registration may pass responsibility for
   the registration to another person or agency by informing IANA and
   the ietf-types list; this can be done without discussion or review.

   The IESG may reassign responsibility for a URL scheme name.  The
   most common case of this will be to enable changes to be made to
   schemes where the author of the registration has died, moved out of
   contact or is otherwise unable to make changes that are important to
   the community.

   URL scheme name registrations may not be deleted; URL scheme names
   which are no longer believed appropriate for use can be declared
   OBSOLETE by a change to their "intended use" field; such URL scheme
   names will be clearly marked in the lists published by IANA.


2.8.  Registration Template

     To: ietf-types@iana.org
     Subject: Registration of URL Scheme Name <name>

     URL Scheme Name:

     Security considerations:

     Interoperability considerations:

     Published specification:

     Applications which use this URL scheme name:

     Additional information:

     Person & email address to contact for further information:

     Intended usage:

     (One of COMMON, LIMITED USE or OBSOLETE)

     Author/Change controller:

     (Any other information that the author deems interesting may be
     added below this line.)


3.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 registrations,
   so that users are not misled as to the true security properties of a
   registered URL scheme.

   Delegations of a name space should only be assigned to someone with
   adequate security.


4.0 References

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

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

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


5.0  Author's Address

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

   Phone: +1 614 723 4157
   Fax:   +1 614 723 1333
   EMail: rpetke@compuserve.net


Appendix A -- Grandfathered URL Scheme Names

   A number of URL scheme names, in use prior to 1998, would, if
   registered under the guidelines in this document, be placed into
   either the vendor or personal trees.  Re-registration of those types
   to reflect the appropriate trees 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 trees
   described above.

   ABOUT:

   AOL: