view Side-By-Side changes

INTERNET-DRAFT                                               Rich Petke
<draft-ietf-urlreg-procedures-00.txt>
<draft-ietf-urlreg-procedures-01.txt>       CompuServe Network Services
                                                         March 13,
                                                         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 view the current status entire list of any Internet-Draft, current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ds.internic.net 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), nic.nordu.net
   (Europe), or ftp.isi.edu
   (US West Coast), or munnari.oz.au (Pacific
   Rim). Coast).

   Distribution of this memo is unlimited.

   This Internet Draft expires September 13, 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.

   RFC [URL-GUIDELINES] provides guidelines for defined, however, new schemes may need to be defined in the definition of
   future in order to accommodate new
   URL schemes, for consideration by those who are defining and
   registering or evaluating those definitions.


2.0 Scope

   The URL scheme Internet protocols and/or
   procedures.

   A registration process is restricted needed to ensure that the
   registration of new URL scheme names.


3.0 Classifications names of Scheme Names

   Not all URL scheme names
   such new schemes are created equal.  This section defines guaranteed not to collide.  Further, the various classifications for
   registration process ensures that URL scheme names.  Section 4 of this 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 to
   register which use the Internet
   Assigned Numbers Authority (IANA) as a central registry for such URL
   scheme name.


3.1 Class 1 - Common Names

   If names and the name proposed 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 common word,
   meaningful fashion appropriate to a large and/or wide population, then the tree
   involved.  The URL 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. then registered if the acronym proposal 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
   acceptable.  The following sections describe the requirements and Registered Trade Names

   Scheme names that echo registered trade names
   procedures used for each of the different registration trees.


2.1.  Registration Trees and vanity names are
   considered URL Schemes

   In order to be Class 3 scheme names.  Examples increase the efficiency and flexibility of such names
   include:

      AOL
      RealAudio
      STTNG


3.4 Class 4 - Private Schemes

   Scheme names based on IANA assigned domain the
   registration process, three different formats of URL scheme names and matching
   may be registered.  The registration requirements for each format
   differ allowing the
   syntax specified below are considered registration procedure to accommodate the
   different natural requirements for URL schemes.  For example, a
   scheme that will be Class 4 recommended for wide support and implementation
   by the Internet Community requires a more complete review than a
   scheme names. that is used with resources associated with proprietary
   software.  The syntax of a class 4 following subsections define registration "trees" and
   the associated URL scheme name is:

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

   where -

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

      <extension> is optional and may contain any legal 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
      characters 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 defined 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].

   Examples  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 valid Class 4 the security issues inherent in the new URL scheme names include:

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


4.0 Registration Procedures (to 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 followed by as accurate as possible regardless of
   registration tree.  In particular, a requestor)

   To register 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 new URL
   scheme name:

   1. Determine which 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 class (as name" mechanism
   described in section 3)
      best describes 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 proposed URL scheme name.  If names registration tree itself.

   Other than in the proposed IETF tree, the registration of a URL scheme name
   does not appear to clearly belong to any one
      classification, request imply endorsement, approval, or recommendation by IANA or
   IETF or even certification that the IESG to classify 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 name.

   2. Complete
   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 name 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 form found in appendix
      A the IETF tree, the normal IETF
   processes should be followed, treating posting of this document.

   3. an internet-draft
   and announcement on the ietf-types list (as described in the next
   subsection) as a first step.  For Class 4 registrations in the vendor or
   personal tree, the initial review step described below may be
   omitted and the URL scheme names ONLY, forward name may be registered directly by
   submitting the completed form template and an explanation directly to IANA directly.

   4. For all other (at
   iana@iana.org).  However, authors of vendor or personal URL scheme name classes, forward
   specifications are encouraged to seek community review and comment
   whenever that is feasible.


2.3.1.  Present the completed form URL Scheme Name to the IESG.

   With 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 exception purpose of Class 4 reviewing
   proposed URL schemes.  URL scheme names, which names proposed to this mailing
   list are easily
   recognizable, not formally registered and should not be used until the IESG has
   registration procedure is complete.

   The intent of the right public posting is to reclassify solicit comments and feedback
   on the choice of scheme name, the syntax and semantics of the
   scheme, and a review of any proposed 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 that have been incorrectly classified.

   The registered in the IETF tree must be submitted to
   the IESG should process applications for approval.


2.3.3.  IANA Registration

   Provided that the registration of new URL scheme name meets the requirements for URL
   scheme names in a timely manner.  It may delay the and has obtained approval of any
   application for just cause, such as lack of consensus within that is necessary, the author
   may submit the
   IETF (when a Class 1 scheme name registration is requested), or
   multiple parties attempting request to the IANA, which will register
   the same or similar scheme
   names.


5.0 Registration Procedures (to be followed by name and make the IESG)

5.1 Class 1 Procedures (Common Names)

   Registering a Class 1 URL scheme name requires registration available
   to the consensus community.


2.4.  Comments on URL Scheme Name Registrations

   Comments on registered URL scheme names may be submitted by members
   of the
   IETF.  The IESG community to IANA.  These comments will seek input be passed on to the
   "owner" of the prospective new URL scheme name and will either approve or reject the registration on behalf if possible.  Submitters of
   the IETF.

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

   If attached to the IESG URL scheme name
   registration itself, and if IANA approves of this the registration, it comment will forward
   be made accessible in conjunction with the scheme name registration form to IANA for recording.


5.2 Class 2 Procedures (Acronyms)

   Registering a Class 2
   itself.


2.5.  Location of Registered URL Scheme Name List

   URL scheme name requires only the consensus of
   the IESG.  The IESG must require registrations will be posted in the proposed anonymous FTP
   directory
   "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/" and
   all registered URL scheme to names will be
   documented listed in an the periodically
   issued "Assigned Numbers" RFC or other permanent [currently STD 2, RFC 1700].  The
   scheme syntax and readily available
   reference, in sufficient detail so that interoperability between
   independent implementations is possible.

   If the IESG approves the registration semantics description and other supporting documentation,
   material may also be published as an Informational RFC by sending it will forward
   to "rfc-editor@isi.edu" (please follow the registration form instructions to RFC
   authors [RFC-1543]).


2.6.  IANA for recording.


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

   Class 3 for Registering URL scheme names are approved on a first come, first served
   basis.

   The IESG IANA will verify that the requested only register URL scheme name is
   indeed names in the IETF tree in
   response to a class 3 name, communication from the IESG stating that a given
   registration has been approved. Vendor and personal types will be
   registered by the party requesting 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
   indeed has reasonable rights been published by IANA, the author may
   request a change to register its definition.  The descriptions of the scheme name, and that
   sufficiently stable "point
   different registration trees above designate the "owners" of contact" information has been supplied
   in each
   type of registration.  The change request follows the same procedure
   as the registration form.  After verification, request:

    (1)   Publish the IESG will forward revised template on the application to IANA ietf-types list.

    (2)   Leave at least two weeks for recording.

   The IESG may require the scheme to comments.

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

   Changes should be documented requested only when there are serious omission or
   errors in an RFC.


6.0 Registration Procedures (to the published specification.  When review is required, a
   change request may be followed by IANA)

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

   IANA will only accept completed denied if it renders entities that were valid
   under the previous definition invalid under the new definition.

   The owner of a URL scheme name registration forms
   which have been approved 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 recording.

6.2 Class 4 Procedures (Private Schemes)

   Upon receipt of a completed URL scheme name name. The most
   common case of this will be to enable changes to be made to schemes
   where the author of the registration form, IANA
   shall:

   1. Verify has died, moved out of contact 
   or is otherwise unable to make changes that are important to the proposed
   community.

   URL scheme name conforms to the syntax
      specified registrations may not be deleted; URL scheme names
   which are no longer believed appropriate for Class 4 use can be declared
   OBSOLETE by a change to their "intended use" field; such URL scheme
   names will be clearly marked 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 lists published by IANA.


2.8.  Registration Template

     To: ietf-types@iana.org
     Subject: Registration of contact" 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 is sufficiently
      stable.
   4. Record that the registration.


7.0 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 schemes. scheme.

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


8.0


4.0 References

   [STD 13]

   [RFC-URI-SYNTAX]

   [RFC-URL-GUIDELINES]


9.0

   RFC [URI-SYNTAX]

   RFC [URL-GUIDELINES]


5.0  Author's Address

   Rich Petke
   CompuServe Network Services Inc.  (WorldCom)
   CNS/WorldCom
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 43026-5000 430
   USA

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


Appendix A -- Grandfathered 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 Names

   A number 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 names, in use prior to 1998, would, if
   registered under the guidelines in this form to:
   ietf-types@iana.org

   For all other URL scheme name classes, including URL scheme names document, be placed into
   either the vendor or personal trees.   Re-registration of
   an unknown class, send those
   types to reflect the appropriate trees is encouraged, but not
   required.  Ownership and change control principles outlined in this form to:  iesg@ietf.org.
   document apply to those types as if they had been registered in the
   trees described above.


----