New URL Registrations Procedures draft

Well folks, in LA I promised that I would have a new procedures
draft out by the end of April and here it is.  I'm sending it on to the
I-D editor later today.

Rich


INTERNET-DRAFT                                               Rich Petke
<draft-ietf-urlreg-procedures-01.txt>       CompuServe Network Services
                                                         April 30, 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 ds.internic.net (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 October 31, 1998.


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] 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 for which there is not currently a URL scheme registered.
   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.funnypictures).

   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.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
   [email protected]).  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
   "[email protected]" 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/" and
   all registered URL scheme names will be listed in the periodically
   issued "Assigned Numbers" RFC [currently STD 2, RFC 1700].  The
   scheme syntax and semantics description and other supporting
   material may also be published as an Informational RFC by sending it
   to "[email protected]" (please follow the instructions to RFC
   authors [RFC-1543]).


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:

     o Security considerations
     o TBD


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 template 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: [email protected]
     Subject: Registration of URL Scheme Name XXX

     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

   RFC [URI-SYNTAX]

   RFC [URL-GUIDELINES]


5.0  Author's Address

   Rich Petke
   CNS/WorldCom
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 430
   USA

   Phone: +1 614 723 4157
   Fax:   +1 614 723 1333
   EMail: [email protected]


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.