Draft of the Registration Procedures

For whatever reasons, all those who volunteered to write the registration
procedures draft have not done so to date.  As chair, the buck stops
with me so here's my cut.  I need to get this submitted to the I-D
editor ASAP so if you have any comments, please get them back to
me by NOON (EST) on Thursday.  Thanks.



INTERNET-DRAFT                                               Rich Petke
<draft-ietf-urlreg-procedures-00.txt>       CompuServe Network Services
                                                         March 13, 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 September 13, 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.

   RFC [URL-GUIDELINES] provides guidelines for the definition of new
   URL schemes, for consideration by those who are defining and
   registering or evaluating those definitions.


2.0 Scope

   The URL scheme registration process is restricted to the
   registration of new URL scheme names.


3.0 Classifications of Scheme Names

   Not all URL scheme names are created equal.  This section defines
   the various classifications for URL scheme names.  Section 4 of this
   document defines the registration procedures to be followed to
   register a scheme name.


3.1 Class 1 - Common Names

   If the name proposed for a new URL scheme is a common word,
   meaningful to a large and/or wide population, then the scheme name
   is considered a Class 1 name.  Examples of such names include:

      Telephone
      Phone
      Fax
      TV
      Weather
      Music


3.2 Class 2 - Acronyms

   Short acronyms for technical terms which do not themselves create
   common words (i.e. the acronym is not a Class 1 name), are
   considered to be Class 2 scheme names.  Examples of such names
   include:

      HTTP
      FTP
      NNTP
      TELNET
      WAIS


3.3 Class 3 - Vanity Names and Registered Trade Names

   Scheme names that echo registered trade names and vanity names are
   considered to be Class 3 scheme names.  Examples of such names
   include:

      AOL
      RealAudio
      STTNG


3.4 Class 4 - Private Schemes

   Scheme names based on IANA assigned domain names and matching the
   syntax specified below are considered to be Class 4 scheme names.

   The syntax of a class 4 URL scheme name is:

      "NOREG+" <domain>  "+" [<extension>] ":"

   where -

      <domain> is defined in  [STD13], section 3.5.

      <extension> is optional and may contain any legal scheme name
      characters as defined in RFC [URI-SYNTAX].

   Examples of valid Class 4 URL scheme names include:

      noreg+compuserve.net+rpa:
      noreg+nt.microsoft.com:


4.0 Registration Procedures (to be followed by a requestor)

   To register a new URL scheme name:

   1. Determine which scheme name class (as described in section 3)
      best describes the proposed URL scheme name.  If the proposed
      scheme name does not appear to clearly belong to any one
      classification, request the IESG to classify the scheme name.

   2. Complete the URL scheme name registration form found in appendix
      A of this document.

   3. For Class 4 URL scheme names ONLY, forward the completed form to
      IANA directly.

   4. For all other URL scheme name classes, forward the completed form
      to the IESG.

   With the exception of Class 4 URL scheme names, which are easily
   recognizable, the IESG has the right to reclassify any proposed URL
   scheme names that have been incorrectly classified.

   The IESG should process applications for the registration of new URL
   scheme names in a timely manner.  It may delay the approval of any
   application for just cause, such as lack of consensus within the
   IETF (when a Class 1 scheme name registration is requested), or
   multiple parties attempting to register the same or similar scheme
   names.


5.0 Registration Procedures (to be followed by the IESG)

5.1 Class 1 Procedures (Common Names)

   Registering a Class 1 URL scheme name requires the consensus of the
   IETF.  The IESG will seek input on the prospective new URL scheme
   name and will either approve or reject the registration on behalf of
   the IETF.

   The IESG may require the proposed scheme to be documented in an RFC
   (standards track, informational, or BCP).

   If the IESG approves the registration, it will forward the
   registration form to IANA for recording.


5.2 Class 2 Procedures (Acronyms)

   Registering a Class 2 URL scheme name requires only the consensus of
   the IESG.  The IESG must require the proposed scheme to be
   documented in an RFC or other permanent and readily available
   reference, in sufficient detail so that interoperability between
   independent implementations is possible.

   If the IESG approves the registration and supporting documentation,
   it will forward the registration form to IANA for recording.


5.3 Class 3 Procedures (Vanity Names and Registered Trade Names)

   Class 3 URL scheme names are approved on a first come, first served
   basis.  The IESG will verify that the requested URL scheme name is
   indeed a class 3 name, that the party requesting the scheme name
   indeed has reasonable rights to register the scheme name, and that
   sufficiently stable "point of contact" information has been supplied
   in the registration form.  After verification, the IESG will forward
   the application to IANA for recording.

   The IESG may require the scheme to be documented in an RFC.


6.0 Registration Procedures (to be followed by IANA)

6.1 Procedures for Class 1, 2, and 3 URL Scheme Names

   IANA will only accept completed URL scheme name registration forms
   which have been approved by the IESG for recording.

6.2 Class 4 Procedures (Private Schemes)

   Upon receipt of a completed URL scheme name registration form, IANA
   shall:

   1. Verify that the proposed URL scheme name conforms to the syntax
      specified for Class 4 URL scheme names in section 3.4 of this
      document.
   2. Verify that the requestor is affiliated with the owner of the DNS
      name specified in the registration form.
   3. Verify that the "point of contact" information is sufficiently
      stable.
   4. Record the registration.


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

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


8.0 References

   [STD 13]

   [RFC-URI-SYNTAX]

   [RFC-URL-GUIDELINES]


9.0 Author's Address

   Rich Petke
   CompuServe Network Services Inc.  (WorldCom)
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 43026-5000
   Phone: 614-723-4157
   Email: [email protected]


Appendix A

   URL Scheme Name Registration Form


   URL Scheme Name to be Registered (case insensitive):

   URL Scheme Name Class (1, 2, 3, 4, or unknown):

   Person Requesting Registration (name, title, affiliation, postal
   address, telephone numbers, email address):

   Point of Contact for this Registration (name, title, affiliation,
   postal address, telephone numbers, email address):

   Published specification(s) for this Scheme Name (I-Ds, RFCs, etc.):

   Other Relevant Information Regarding this Application:






   For Class 4 URL scheme names ONLY, send this form to:
   [email protected]

   For all other URL scheme name classes, including URL scheme names of
   an unknown class, send this form to:  [email protected].