view Side-By-Side changes

Date: Tue, 09 Apr 2002 08:57:28 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 14 Aug 1998 13:04:00 GMT
ETag: "323d8c-5f98-35d435c0"
Accept-Ranges: bytes
Content-Length: 24472
Connection: close
Content-Type: text/plain
INTERNET-DRAFT                                                 R. Petke
<draft-ietf-urlreg-procedures-03.txt>        WorldCom
<draft-ietf-urlreg-procedures-04.txt>     MCIWORLDCOM Advanced Networks
                                                         August 7,
                                                       November 1, 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 learn the entire list of current Internet-Drafts, status of any Internet-Draft, 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 nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast). Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

   This Internet Draft Internet-Draft expires February 7, April 30, 1999.

   Copyright Notice

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

   Abstract

   This document defines the process by which new URL schemes scheme names 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] 2396 [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 the registration procedures which use the Internet
   Assigned Numbers Authority (IANA) as a central registry for such to be followed
   when new URL
   scheme names and the IETF schemes are created.  A separate document, RFC mechanism
   [URL-GUIDELINES], Guidelines for scheme review, where 
   appropriate. URL Schemes [2], provides
   guidelines for the creation of new URL schemes.  The primary focus
   of this document is on the <scheme> portion of new URL schemes,
   referred to as the "scheme name" throughout this document.


2.0 URL Scheme Name Registration Trees

2.1 General

   In order to increase the efficiency and flexibility of the URL
   scheme name registration process, several two different registration "trees"
   have been created.  The registration requirements and specific
   registration procedures for each 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
   community requires a more complete review, prior to registration, review than a scheme intended to
   be used for resources associated with proprietary software.

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

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

   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.

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


2.3 The OID Tree

   The OID tree requires approval by the IESG and
   publication of the is intended for URL schemes which will be used in a
   proprietary manner.  The trees exists to provide a mechanism for
   ensuring that scheme names do not collide.  The syntax and semantics as some form
   of
   RFC, usually a standards track RFC.

   All new URL schemes registered created in the IETF tree, MUST conform OID tree do not have to be reviewed or
   publicly disclosed.

   Creating a URL scheme name in the
   generic OID tree does not imply
   endorsement, approval, or recommendation by the IETF or even
   certification that the specification is adequate, even if the scheme
   was published as an IETF Internet-Draft and/or reviewed by IETF
   participants.  To become Internet Standards, protocols, data
   objects, or whatever must go through the IETF standards process and
   registration in the IETF tree.


2.4 Additional Registration Trees

   From time to time and as required by the community, the IESG may
   create new top-level registration trees.  


3.0 Requirements for Scheme Name Registration

3.1 General Requirements

   All new URL scheme NAMES, regardless of registration tree, MUST
   conform to the syntax specified in RFC 2396 for scheme NAMES.


3.2 The IETF Tree

   Registration in the IETF tree requires publication of the URL scheme
   syntax and semantics in either an Informational or Standards Track
   RFC.

   In addition to having a conforming scheme NAME (see section 3.1),
   all new URL schemes registered in the IETF tree, MUST conform to the
   generic syntax for URLs as specified in RFC [URI-SYNTAX]. 2396.

   An analysis of the security issues inherent in the new URL scheme 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 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 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 registered 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)
   Informational or Standards Track RFC) as required used for the initial
   registration.

2.2.4  Syntax  Schemes originally defined via an Informational RFC
   may, however, be replaced with Standards Track documents.


3.3 The OID Tree

   While public exposure and review of URL Scheme Names a URL scheme names created 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 OID
   tree is used not required, using the IETF Internet-Draft mechanism for
   peer review is strongly encouraged to improve the quality of the
   specification.  RFC publication of OID tree 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 of a URL scheme name in the vendor 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 and the registration in the IETF
   tree.

2.3.2  Registration Requirements

   RFC publication of vendor URL schemes is encouraged but not
   required.  Material may be published is
   encouraged but not required.  Material may be published as an
   Informational RFC by sending it to the RFC Editor (please follow the
   instructions to RFC authors, RFC-2223 RFC 2223 [3]).

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

   URL schemes registered created in the vendor OID tree are encouraged to conform to the
   generic URL syntax syntax, RFC 2396, but are not required to do so in order to
   be registered. so.

   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 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
   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 created in the vendor
   OID tree be secure or completely free from risks.  Nevertheless, all
   known security risks SHOULD be identified in the
   registration. identified.

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

2.3.3  Ownership of Registration

   The registration the OID tree formally
   belongs to the vendor or organization
   registering entity to which the scheme name. OID is assigned.  Changes to the
   specification will of an OID tree URL scheme which is documented by an
   Informational RFC shall only be
   made at their request, as discussed in subsequent sections.

2.3.4  Syntax accepted from the owner of the OID
   or with the permission of the owner of the OID.

   The syntax of URL Scheme Names

   Registrations scheme names for schemes created in the vendor OID tree will be distinguished by
   is simply the
   leading facet "vnd.".  That must be text string "OID-" followed by an IANA-approved
   designation of the producer's name, which is then followed by a numeric OID
   including any embedded hyphens.  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.".


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 personal tree.  Unlike the IETF and vendor trees which guarantee
   the uniqueness of registered scheme names, registrations in the
   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 and the registration in the IETF
   tree.

2.4.2  Registration Requirements

   RFC publication of personal URL schemes is encouraged but not
   required.  Materials may be published as an Informational RFC by
   sending it to the 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 tree is not required, using the
   ietf-url-schemes list for review is strongly encouraged to improve
   the quality of those specifications.

   URL schemes registered in the personal tree are encouraged to
   conform to the generic URL 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].

   While not required, an analysis of the security issues inherent in
   the new URL scheme is 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
   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
   the personal tree be secure or completely free from risks.
   Nevertheless, all known security risks SHOULD be identified in the
   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.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 names are case
   insensitive so the proposal letters 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 text string "OID-" need 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
   capitalized.  No variations on this formula are permitted.

   Examples of valid URL scheme names in the registration template and re-submit it to IANA who will treat
   the re-submission as OID tree:

      OID-2-16-840-1-113779-2-1:
      Oid-2-16-840-1-113779-2-1-100:
      OiD-2-16-840-1-113779-3:
      oid-2-16-840-1-113779-123:


4.0 Registration Procedures

4.1 The IETF Tree

   The first step in registering 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 template has
   previously been posted to the ietf-url-schemes list for review, IANA
   will post URL scheme in the template IETF tree is
   to the list along with publish an indication that IETF Internet-Draft detailing the
   template has been officially received by IANA for registration.
   IANA will then wait for two (2) weeks for comments on syntax and community
   review
   semantics of the registration request. proposed scheme.  The intent of the public posting is to solicit comments and feedback
   on the choice draft must, minimally,
   address all of scheme name, the syntax and semantics of items covered by the
   scheme, and a review of any interoperability or security
   considerations (if such information is disclosed template provided in the application
   or associated documentation).

   IANA will forward section
   6 of this document.

   After all comments received issues raised during this a review period to
   the person designated as the contact person in the registration
   template.

   The submitter may of no less than 4
   weeks have been addressed, submit a revised registration, or withdraw the
   registration completely, at any time.

   After draft to the two week IESG for review.

   The IESG will review period has expired, IANA shall register the URL proposed new scheme name in and either refer the
   scheme to a working group (existing or new) or directly present the vendor 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 IESG for URL scheme names in a last call.  In the personal tree former case, the working
   group is identical as that specified responsible for the vendor tree with the
   exception of IANA assigning the vendor submitting a unique name.


4.0  Comments on URL Scheme Name Registrations

   Comments on registered URL scheme names may be submitted by members final version of the community to IANA.  These comments will be passed on draft to
   the
   "owner" IESG for approval at such time as it has received adequate
   review and deliberation.


4.2 The OID Tree

   Registration of the URL schemes created in the OID tree is automatic
   because the scheme name if possible.  Submitters of comments
   may request that their comment be attached is based on a previously registered entity,
   an OID.  There is no requirement to publish any documentation for
   the URL scheme name
   registration itself, and if IANA approves of this the comment will scheme, however, doing so may be made accessible in conjunction with the scheme name registration
   itself.


5.0  Change Control

   Once advantageous and is
   encouraged.

   The recommended form for documenting a URL scheme name has been published by IANA, the owner of created in the
   scheme name may request a change to its definition. OID
   tree is via an Informational RFC.  The descriptions RFC should address all of the different registration trees above designate
   items covered by the owners of 
   each type template provided in section 6 of registration. The change request follows the same
   procedure as this
   document.


5.0 Change Control

5.1 Schemes in the registration request:

    (1) Complete IETF Tree

   URL schemes created in the registration template.

    (2) Publish IETF tree are "owned" by the revised scheme syntax IETF itself
   and semantics on the
        ietf-url-schemes list if peer review is requested.

    (3) Submit may be changed, as needed, by updating the revised registration to IANA.

   Changes should RFC that describes
   them.  Schemes described by Standards Track RFC but be requested only when there are serious omission replaced with
   new Standards Track RFCs.  Informational RFCs may be replaced by new
   Informational RFCs or
   errors Standards Track RFCs.


5.2 Schemes in the OID Tree

   Undocumented URL schemes created in the OID tree may be changed by
   their owner at any time without notifying the IETF.

   URL schemes created in the published specification.  When review is required, a
   change request OID tree that have been documented by an
   Informational RFC, may be denied if it renders entities that were valid
   under changed at any time by the previous definition invalid under owner, however,
   an updated Informational RFC which details the new definition. changes made, must be
   submitted to the IESG.

   The owner of a URL scheme registration registered in the OID tree and documented
   by an Informational RFC may pass responsibility for the registration
   to another person or agency by informing IANA and the ietf-url-schemes list; this can be done without discussion or
   review. IESG.

   The IESG may reassign responsibility for a URL scheme name. registered in
   the OID tree and documented by an Informational RFC.  The most
   common case of this will be to enable changes to be made to schemes
   where the author owner of the registration OID has died, moved out of contact or is
   otherwise unable to make changes that are important to the
   community.

   URL scheme name registrations

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


6.0  IANA 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 submitter to be subscribed to the list in order to
   process a post.

6.2  Location of Registered URL Scheme Name List

   URL scheme name registrations need to be posted in the anonymous
   FTP directory
   "ftp://ftp.isi.edu/in-notes/iana/assignments/URL-scheme-names/".

6.3  Procedures for Registering URL 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.

   Scheme names in the vendor OID tree will be registered automatically
   provided and
   documented via an Informational RFC as "historic" if it determines
   that the registration template contains at least the
   information specified below.  Assignment of unique scheme names
   shall be on a first come, first served basis.

   Scheme names is no longer in the personal tree will be registered automatically
   provided that the registration template contains at least the
   information specified below.  No attempt shall be made to prevent
   multiple applications from registering the same scheme name even if
   the use of the schemes are different and incompatible. use.


6.0  Registration Template

   The following minimal information must issues should be specified for addressed when documenting a
   registration in the vendor or personal tree:

   Scheme Name Syntax:  The syntax of the requested new URL
   scheme:

      URL scheme name
   (including the assigned producer designation name.

      URL scheme syntax.  This should be expressed in the case a clear and
      concise manner.  The use of vendor
   tree registrations), MUST conform ABNF is encouraged.  Please refer to the syntax
      RFC [URL-GUIDELINES] for such as
   specified guidance on designing and explaining
      your scheme's syntax.

      Character encoding considerations.  It is important to identify
      what your scheme supports in RFC [URI-SYNTAX].  While encouraged this regard.  It is obvious that for
      interoperability, it is best if there is a means to do so, the
   syntax support
      character sets beyond USASCII, but especially for the actual scheme does private
      schemes, this may not have to conform to be the
   general syntax specified in RFC [URI-SYNTAX].

   Security Considerations:  The application for registration case.

      Intended usage.  What sort of resource is being identified?  If
      this is not a
   scheme name MUST include a discussion 'resource' type of URL (e.g. mailto:), explain 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
      action that should be initiated by the author
   and/or entity responsible for change control consumer of the proposed scheme.


7.0  Registration Template

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

     URL Scheme Name:

     Character encoding considerations:

     Security considerations:

     Interoperability considerations:

     Published specification: URL.  If
      there is a MIME type associated with this resource, please
      identify it.

      Applications and/or protocols which use this URL scheme name:

     Additional information: name.

      Interoperability considerations.  If you are aware of any details
      regarding your scheme which might impact interoperability, please
      identify them here.  For example: proprietary or uncommon
      encoding method; inability to support multibyte character sets;
      incompatibility with types or versions of underlying protocol
      (if scheme is tunneled over another protocol).

      Security considerations.

      Relevant publications.

      Person & email address to contact for further information:

     Intended usage:

     (One of COMMON, LIMITED USE or OBSOLETE) information.

      Author/Change controller:

     (Any other information that the author deems interesting may be
     added below controller.


Applications and/or protocols which use this line.)


8.0 URL scheme name.



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, documentation,
   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.


9.0


8.0 References

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


10.0


9.0  Author's Address

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

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


Appendix A -- Grandfathered URL Scheme Names

   A number of URL scheme names, in use prior to 1998, would, if
   registered under the procedures specified in this document, be
   placed into either the vendor or personal trees. OID tree.  Re-registration of those types to reflect
   the appropriate trees tree or documentation of the schemes in an
   Informational RFC 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. OID tree.


      ABOUT:  (No information available at this time.)

      AOL:  (No information available at this time.)

----