INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-procedures-02.txt>
<draft-ietf-urlreg-procedures-03.txt>        WorldCom Advanced Networks
                                                          July 17,
                                                         August 7, 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, February 7, 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"
   "<scheme>:" and then a "scheme-specific part". "<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 URL
   scheme name registration process, three several different formats of URL scheme names
   may be registered. registration
   "trees" have been created.  The registration requirements and
   specific registration procedures for each format
   differ 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 review, prior to registration,
   than a scheme that is intended to be used with for resources associated with
   proprietary software.  The following subsections define

   Each of the URL scheme name registration "trees" and trees also imparts a
   specific syntax to the associated scheme name being registered.

   Registration of a new URL scheme name formats available at this time. may occur in any ONE of the
   established registration trees.

   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, the desired syntax for the scheme
   name, and the ability to meet the registration requirements for the
   desired tree.

   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.

   The following subsections define the registration trees available at
   this time, the purpose of each tree, the requirements for
   registration in each tree, and the associated URL scheme name
   formats that are applied to names registered in each tree.

2.1  General Requirements

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

2.2  The IETF Tree

2.2.1  Purpose

   The IETF tree is intended for URL schemes of general interest to the
   Internet Community.  Registration in the IETF  The tree requires exists for URL schemes that require a
   substantive review and approval process; 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.

2.2.2  Registration Requirements

   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.

   All new URL schemes registered in the IETF tree, MUST conform to the
   generic syntax for URLs as specified in RFC [URI-SYNTAX].

   An analysis of the security issues inherent in the new URL scheme names 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 are normally denoted be secure or completely free
   from risks.  Nevertheless, all known security risks must be
   identified.

   The security considerations section of all registrations is subject
   to continuing evaluation and modification, and in particular may be
   extended by names that
   are not explicitly faceted, i.e., do not contain period (".")
   characters. use of the "comments on URL scheme names" mechanism
   described in section 4.0.

2.2.3  Ownership

   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.

2.2.4  Syntax of URL Scheme Names

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

2.3  The Vendor Tree

2.3.1  Purpose

   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 of a URL scheme name.
   Changes to the specification will be made at their request, as
   discussed in subsequent sections.

   Registrations name in the vendor tree will be distinguished does not
   imply endorsement, approval, or recommendation 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 or IETF or
   even certification 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 specification is not required, using adequate.  To become
   Internet Standards, protocol, data objects, or whatever must go
   through the ietf-types
   list for review is strongly encouraged to improve IETF standards process and the quality of
   those specifications.  Registrations registration in the IETF
   tree.

2.3.2  Registration Requirements

   RFC publication of 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 is encouraged but not distributed commercially
   required.  Material may be registered in
   the personal or vanity tree.  The registrations are distinguished published as an Informational RFC by
   sending it to the leading facet "prs.".

   The owner of "personal" registrations and associated specifications
   is the person or entity making RFC Editor (please follow the registration, or one instructions to whom
   responsibility has been transferred as described below. RFC
   authors, RFC-2223 [3]).

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

   URL schemes registered in the personal vendor tree
   may be submitted directly are encouraged to the IANA.

2.1.4.  Additional Registration Trees

   From time conform
   to time and as the generic URL syntax but are not 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 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

   While not required, 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 encouraged.  Regardless of what security
   analysis for schemes registered in the vendor is or personal
   trees is encouraged but not required.  However, regardless of what
   security analysis has or has not been done, all descriptions performed, all descriptions of security issues
   must be as accurate as possible regardless of
   registration tree. 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 registered in
   any
   the vendor tree be secure or completely free from risks.
   Nevertheless, all known security risks must SHOULD be identified in the registration of a URL
   scheme name, again regardless of registration tree.
   registration.

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

2.3.3  Ownership of Registration

   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.

2.2.4.  Publication Requirements

   Proposals for

2.3.4  Syntax of URL schemes registered Scheme Names

   Registrations in the IETF vendor tree will be distinguished by the
   leading facet "vnd.".  That must be
   published as RFCs.  RFC publication followed by an IANA-approved
   designation of vendor and personal URL
   schemes the producer's name, which is encouraged but not required.  In all cases then followed by a URL
   scheme name or product designation (e.g. vnd.bigcompany.telepathic).

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

2.4  The Personal or Private Tree

2.4.1  Purpose

   Registrations for URL schemes created experimentally or as part of
   products that are not distributed commercially may be registered in
   the URL personal tree.  Unlike the IETF and vendor trees which guarantee
   the uniqueness of registered scheme names registration tree itself.

   Other than names, registrations in the IETF tree,
   personal tree are NOT guaranteed to be unique.  Multiple sites may
   register the same scheme name but use it in different (and
   incompatible) ways.

   The registration of a URL scheme name in the personal tree 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 and the convenient registration of URL scheme
   names.

   The in the IETF tree exists for
   tree.

2.4.2  Registration Requirements

   RFC publication of personal URL schemes that do require a substantive
   review and approval process with is encouraged but not
   required.  Materials may be published as an Informational RFC by
   sending it to the vendor RFC Editor (please follow the instructions to RFC
   authors, RFC-2223 [3]).

   While public exposure and review of URL scheme names to be
   registered in the personal trees exist tree is not required, using the
   ietf-url-schemes list for review is strongly encouraged to improve
   the quality of those that specifications.

   URL schemes registered in the personal tree are encouraged to
   conform to the generic URL syntax but are not required to do not. It so in
   order to be registered.

   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 expected 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 applicability statements
   for particular applications will
   there are "no security issues associated with this scheme" must not
   be published confused with "the security issues associates with this scheme
   have not been assessed".

   There is absolutely no requirement that URL schemes registered in
   the personal tree be secure or completely free from time risks.
   Nevertheless, all known security risks SHOULD be identified in the
   registration.

   The security considerations section of all registrations is subject
   to time that
   recommend implementation of, continuing evaluation and support for, modification, and in particular may be
   extended by use of the "comments on URL schemes that have
   proven particularly useful scheme name" mechanism
   described in those contexts.

   As discussed above, section 4.0.

2.4.3  Ownership of Registration

   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.

2.4.4  Syntax of URL Scheme Names

   Registrations in the personal tree are distinguished by the leading
   facet "prs.".  For example, "prs.fiberreflection".

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

3.0  Registration Procedures

   The following sections detail the procedures to follow to register a
   new URL scheme name in a specific registration tree.  With the
   exception of registration in the IETF tree, these procedures are not
   a formal standards process, but rather an administrative procedure
   intended to allow community comment and sanity checking without
   excessive time delay.

3.1  The IETF Tree

   Complete the registration template (section 7.0 of this document)
   and submit it to the IESG for review.  Generally the details of
   the proposed new URL scheme should already be documented in an
   Internet-Draft and the registration template should reference this
   draft.

   The IESG will review the proposed new scheme and either refer the
   scheme to a working group (existing or new) or directly present the
   registration and associated documentation to the IESG for a last
   call.  In the former case, the working group is responsible for
   re-submitting it to the IESG for approval at such time as it has
   received adequate review and deliberation.

   After the IESG has approved the registration, it will forward the
   registration paperwork and documentation to IANA for publication on
   the ietf-url-schemes list and official registration in the IETF
   tree.

   Authors proposing new URL schemes for the IETF tree are encouraged
   to present the proposed schemes to the IETF as a whole, via the
   Internet-Drafts mechanism, well in advance of submission to the
   IESG.

3.2  The Vendor Tree

   Complete the registration template (section 7.0 of this document) as
   completely as possible.

   While not required, it is recommended and encouraged that vendors
   submit a copy of the completed registration template (which includes
   references to any additional documentation), to the ietf-url-schemes
   list for peer review and comment.  The quality of URL schemes can
   usually be improved through such a process.  The amount of feedback
   received regarding the proposed scheme should serve as an indication
   of how long to keep the proposal in peer review before proceeding
   with the registration.

   Forward the completed registration template to IANA (iana@iana.org).

   IANA will review the registration template to ensure that it meets
   the requirements necessary for registration.  If it does not meet
   the necessary requirements, the application will be rejected and
   returned to the submitter and the registration process will be
   terminated.  Authors may choose to amend the information presented
   in the registration template and re-submit it to IANA who will treat
   the re-submission as a new registration request.

   IANA will assign the unique designation for the producer's name at
   this time if one has not already been assigned to the producer
   making the registration request.

   Regardless of whether or not the accepted registration of a top-level type requires
   standards-track processing and, hence, RFC publication.

2.3.  Registration Procedure

   The following procedure template has
   previously been implemented by posted to the ietf-url-schemes list for review, IANA
   will post the template to the list along with an indication that the
   template has been officially received by IANA for review registration.
   IANA will then wait for two (2) weeks for comments on and approval community
   review of new URL scheme names.  This the registration request.

   The intent of the public posting is not a formal
   standards process, but rather an administrative procedure intended to allow community comment solicit comments and sanity checking without excessive
   time delay.  For registration in the IETF tree, feedback
   on the normal IETF
   processes should be followed, treating posting choice of an internet-draft scheme name, the syntax and announcement on semantics of the ietf-types list (as described
   scheme, and a review of any interoperability or security
   considerations (if such information is disclosed in the next
   subsection) application
   or associated documentation).

   IANA will forward all comments received during this review period to
   the person designated as the contact person in the registration
   template.

   The submitter may submit a first step.  For registrations revised registration, or withdraw the
   registration completely, at any time.

   After the two week review period has expired, IANA shall register
   the URL scheme name in the vendor or tree.

   URL scheme names proposed to this mailing list are not formally
   registered and should not be used until the registration procedure
   is completed by IANA.

3.3  The Personal Tree

   The registration procedure for URL scheme names in the personal tree, tree
   is identical as that specified for the initial review step described below vendor tree with the
   exception of IANA assigning the vendor a unique name.

4.0  Comments on URL Scheme Name Registrations

   Comments on registered URL scheme names may be
   omitted and 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 registered directly by
   submitting the template and an explanation directly attached to IANA
   (at iana@iana.org).  However, authors of vendor or personal the URL scheme specifications are encouraged to seek community review name
   registration itself, and if IANA approves of this the comment whenever that is feasible.

2.3.1.  Present will
   be made accessible in conjunction with the URL scheme name to the Community for Review

   Send registration
   itself.

5.0  Change Control

   Once 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 published by IANA, the purpose owner of reviewing
   proposed URL schemes.  URL the
   scheme names proposed name may request a change to this mailing
   list are not formally registered and should not be used until the
   registration procedure is complete. its definition. The intent descriptions
   of the public posting is to solicit comments and feedback
   on different registration trees above designate the choice owners of scheme name,
   each type of registration. The change request follows the same
   procedure as the registration request:

    (1) Complete the registration template.

    (2) Publish the revised scheme syntax and semantics of on the
   scheme, and a
        ietf-url-schemes list if peer review of any interoperability or security
   considerations.  The submitter may submit a revised registration, or
   withdraw is requested.

    (3) Submit the revised registration completely, at any time.

2.3.2.  IESG Approval

   URL scheme names registered to IANA.

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

   The owner of a URL scheme registration may pass responsibility for approval.

2.3.3.
   the registration to another person or agency by informing IANA Registration

   Provided that the URL scheme name meets and
   the requirements ietf-url-schemes list; this can be done without discussion or
   review.

   The IESG may reassign responsibility for a URL scheme names and has obtained approval that is necessary, name.  The
   most common case of this will be to enable changes to be made to
   schemes where the author
   may submit of the registration request has died, moved out of
   contact or is otherwise unable to the IANA, which will register
   the scheme name and make the URL scheme name registration available changes that are important to
   the community.

2.4.  Comments on

   URL Scheme Name Registrations

   Comments on registered scheme name registrations may not be deleted; URL scheme names may
   which are no longer believed appropriate for use can be submitted declared
   OBSOLETE by members
   of the community to IANA.  These comments will be passed on a change to the
   "owner" of the their "intended use" field; such URL scheme name if possible.  Submitters of comments
   may request that their comment
   names will be attached to clearly marked in the URL scheme name
   registration itself, and if lists published by IANA.

6.0  IANA approves of this Considerations

6.1  Discussion List

   A discussion list named "ietf-url-schemes" needs to be created and
   maintained at "iana.org".  The list MUST be open and MUST NOT
   require the comment will submitter to be made accessible in conjunction with subscribed to the scheme name registration
   itself.

2.5. list in order to
   process a post.

6.2  Location of Registered URL Scheme Name List

   URL scheme name registrations will need to 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

6.3  Procedures for Registering URL scheme names

   The IANA will only register URL scheme Scheme Names

   Scheme names in the IETF tree will only be registered 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 names 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 will be registered automatically
   provided that the
   actual scheme does not have to conform to registration template contains at least the general syntax
   information specified in RFC [URI-SYNTAX].

   Security Considerations:  The application for registration below.  Assignment of a unique scheme name MUST include names
   shall be on a discussion of the security
   considerations inherent first come, first served basis.

   Scheme names 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 personal 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 registered automatically
   provided that the published specification.  When review is required, a
   change request may registration template contains at least the
   information specified below.  No attempt shall be denied made to prevent
   multiple applications from registering the same scheme name even if it renders entities that were valid
   under
   the previous definition invalid under use of the new definition. schemes are different and incompatible.

   The owner of a URL scheme registration may pass responsibility following minimal information must be specified for
   the a
   registration to another person or agency by informing IANA and in the ietf-types list; this can be done without discussion vendor or review. personal tree:

   Scheme Name Syntax:  The IESG may reassign responsibility for a URL syntax of the requested scheme name.  The
   most common name
   (including the assigned producer designation in the case of this will be to enable changes vendor
   tree registrations), MUST conform to be made the syntax for such as
   specified in RFC [URI-SYNTAX].  While encouraged to
   schemes where do so, the author of
   syntax for the registration has died, moved out of
   contact or is otherwise unable actual scheme does not have to make changes that are important conform to the community.

   URL scheme name registrations may not be deleted; URL scheme names
   which are no longer believed appropriate
   general syntax specified in RFC [URI-SYNTAX].

   Security Considerations:  The application for use can be declared
   OBSOLETE by registration of a change to their "intended use" field; such URL
   scheme
   names will be clearly marked name MUST include a discussion of the security considerations
   inherent in the lists published by IANA.

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

7.0  Registration Template

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

     URL Scheme Name:

     Character encoding considerations:

     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

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

9.0 References

   [1]  Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC [URI-SYNTAX], 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.

5.0

10.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 procedures specified 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: