[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

INTERNET-DRAFT                                                  I. King
<draft-king-vnd-urlscheme-02.txt>                 Microsoft Corporation
                                                          July 14, 2000

                        The VND Tree for URL Scheme Names

Status of this Memo

        This document is an Internet-Draft and is in full conformance with
        all provisions of Section 10 of RFC2026.

        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-

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

        The list of current Internet-Drafts can be accessed at

        The list of Internet-Draft Shadow Directories can be accessed at

        This Internet-Draft expires January 14, 2001.

Copyright Notice

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


      This document describes the vnd scheme namespace, or "tree," which
      provides for vendor-specific URL scheme namespaces with relaxed
      registration requirements, which can be used with no concern for
      name collision.  The namespace also implicitly provides
      identification of the originator of the URL scheme, in the event
      others become interested in the scheme.

1.0 Introduction

      The URL scheme name registration process, described in RFC 2717 [1]
        requires IESG review and approval of all proposed scheme names
        the "IETF tree", which encompasses simple, short, often descriptive
        scheme names (such as http:, fax:, or mailto:).  This is intended to

        allow for considered public review of proposals which would
associate a
        commonly-used label with a URL scheme, and to avoid collision and
        multiple implementations in the URL scheme namespace.  However, this

        form of URL scheme name is often selected because the name is
        to be widely distributed, seen and used, possibly by naive users.
      the development of new products, vendors often have the need to
      use URLs to identify and locate resources in a manner that is NOT
      seen by end users, is not widely distributed, or for some other
      reason does not justify the effort to register a scheme name from
      the IETF tree.

      One approach which has been used informally for some time is what
      we may call the vnd scheme name tree.  URL scheme names in this
      tree are characterized by the initial string 'vnd', followed by a
      separator '.' and thence by an abbreviation identifying a parti-
      cular vendor.  For example, Microsoft has made use of 'vnd.ms'
      as a URL scheme namespace, creating new scheme names by appending
      another separator '.' and a unique string (for example,
      vnd.ms.foo:).  This parallels syntax documented for MIME type
      naming in RFC 2048 [2].

      This document shall formalize the use of the vnd scheme name
      syntax, defining the vnd scheme name tree as one parallel to the
      IETF tree, with unique requirements for registration and management.
1.1 Notation

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in RFC 2119.

2.0 VND Scheme Name Syntax

2.1 General Syntax

      The general syntax of a URL scheme name in conformance with the vnd
      tree is:


      where 'vnd' is a reserved prefix that uniquely identifies a URL scheme
      name belonging to this tree, the vendor-ID is a string registered
      with IANA to uniquely identify an organization, and the scheme-ID is
      a string of US-ASCII characters, in conformance with RFC 2396[3] and
      RFC 2718, that identifies the particular scheme within the subtree
        owned by the organization identified by <vendor-ID>.  All parts are
        case-insensitive.  NOTE that the separator character is not in
        compliance with RFC 2718; this is an exception which is codified
        here as existing usage.

      This syntax specifically disallows the form `vnd.foo', where `foo'
      is the scheme-ID and there is no vendor-ID.  If a scheme is to be
      widely shared, it should either be owned by one vendor and shared
      with others by some external agreement, or should be registered
      within the IETF tree.  The sole purpose for the vnd tree is to
      support vendor-specific URL scheme namespaces.

2.2 Choosing a vendor-ID

      The vendor-ID is an IANA-approved designation, consisting of a
      short string of US-ASCII characters that is sufficient to uniquely
      identify the organization.  The vendor-ID string may consist only
      of alphanumeric characters, and the first character must be alpha-
      betic.  In particular, the characters '.' and '-' are specifically

      To avoid exhaustion of the namespace, vendors are encouraged to
      establish only one vendor-ID, although it is recognized that large
      organizations may actually consist of multiple sub-units.

      The organization may be a business (whether for-profit or not),
      governmental unit, educational institution, or any other entity
      which is regularly engaged in producing software.  The term "vendor"
      is used in this document for simplicity.

2.3 Syntax for the scheme-ID

      The scheme-ID must comply with RFC 2396 and RFC 2718.  As
      advice rather than direction, the vendor is encouraged to select a
      scheme-ID that is short and descriptive of its purpose.

3.0 Requirements for Scheme Name Registration

3.1 General Requirements

      These requirements are modeled upon those for MIME types, as set
      forth in RFC 2048.  The purpose of registration is to give notice to
      the Internet community of the existence of the vnd subtree and of
      schemes therein.  Registration of the vendor-ID is required, and
      serves to partition the namespace (and avoid collision).
      Registration of the specific scheme is optional, and may be anything
      in the range from notice that the name is in use, to a full
      specification (e.g. Informational RFC) of the scheme's syntax and

3.2 Registering the vendor-ID

      The request for vendor-ID registration may be included in a vnd URL
      scheme name registration, or may be separately submitted, to IANA at
      iana@iana.org.  The request must contain the proposed vendor-ID, the
      vendor's legal business name, principal business address, telephone
      number, and contact information for a person or position that will
      be responsible for the use of the vendor's subtree.  The vendor
      should inform IANA if changes in business (acquisition, closure,
      etc.) lead to changes in this information, and may expressly
      transfer ownership of its vendor-ID and associated subtree upon such
      changes or for any other reason.

      A given vendor-ID can be issued only once, and it does not expire;
      however, if IANA becomes aware that the entity so identified is no
      longer in existence, and no express transfer of the vendor-ID
      registration was performed, IANA may declare a given registration
      `archived'.  This is to avoid possible name collision; if vendor B
      were allowed to re-register vendor A's vendor-ID (with no contact
      between the vendors), and vendor A's products were still in use,
      vendor B might unknowingly redefine a URL scheme in a way that
      breaks vendor A's products.

      IANA shall maintain a public registry of the vendor-IDs, together
      with contact information for each vendor so registered.  A form
        for submission of this information (together with scheme information
        as appropriate) is provided as Appendix A to this document.

3.3 Publishing Scheme-Specific Information

      While public exposure and review of a URL scheme created in the vnd
      tree is not required, using the IETF Internet-Draft mechanism for
      peer review is strongly encouraged to improve the quality of the
      specification.  RFC publication of vnd tree URL schemes 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 [5]).

      Another useful mechanism for disseminating information about a new
      vnd URL scheme is publication on the ietf-announce mailing list.
      This is encouraged for URL schemes which a vendor believes might be
      of general interest to the Internet community at some point in the
      future, but is discouraged as an insufficient solution if the URL
      scheme name is expected to be visible to end users.  In the case of
      a URL scheme name that is intended to be transcribed and otherwise
      used by end users, a name should be registered in the IETF tree
      pursuant to RFC 2717.

      IANA will maintain a public registry of vnd tree scheme names that
      have been published by either of the above methods, as well as
      those registered directly with IANA per section 3.2 above.

      In publishing information about a new vnd URL scheme, vendors are
      encouraged to follow the guidelines set forth in section 6 of RFC
      2717.  A form for submission of this information (together with
        vendor information, as appropriate) is provided as Appendix A to
        this document.

3.4 Change Control

      The vendor is the owner of all schemes within its registered tree,
      has sole responsibility for management of the sub-tree created by
      its vendor-ID, and owns change control for any URL schemes
      deployed therein.  No one may implement or deploy a URL scheme in
      a vnd scheme namespace to which one is not entitled by virtue of
      association with the vendor.  If a vendor publishes information
      about a vnd URL scheme by either of the methods described in sec-
      tion 3.3 above, changes to the syntax or semantics of that URL
      scheme must be subsequently published by the same medium as
      originally employed.

4.0 Security Considerations

      The vendor identified by the vendor-ID part of the URL scheme name
      should be consulted for any information regarding the URL scheme and
      its implementation.  To that end, vendors must provide a point of
      contact that can be reasonably authenticated, for instance, common
      business contact information (business address, telephone number,
      etc.).  (This is addressed in the registration section above.)

      No vendor is required by reason of registration in the vnd tree, by
      either means, to disclose syntactical or other information about
      schemes it has developed.  Security considerations for individual
      schemes may vary, and the vendor is not required to publish same.
      Notwithstanding, the vendor is highly encouraged to publish any
      known security issues, and to comply with the security
      considerations set forth in RFC 2718.

      Vendors should exercise caution around the security risks posed by
      given URL scheme, and take steps to protect themselves against
      damage caused by ignorant use of the URL scheme by others.  In other
      words, if the URL scheme has not been published, together with its
      security considerations, the vendor is probably best served by
      avoiding use which would expose the scheme to others (i.e. on the
      open Internet).  Likewise, caution should be exercised in using a
      vnd URL scheme if one cannot obtain information on its syntax and
      semantics; uninformed use may have unexpected impact.

5.0 IANA Considerations

      IANA maintains a registry of URL scheme names, per the requirements of

        RFC 2717, and scheme names established under this process SHALL also
        entered in that registry if so requested by the originator of the
        scheme name (this is optional, per section 3.3. above).  IANA SHALL
        maintain a separate registry of vendor-ID strings, relating the
        vendor-ID to the vendor information (business contact information,
        etc.) provided in the registration.  IANA SHALL reject a vendor-ID
        registration if it duplicates an existing registration.  IANA SHALL
        consult with the IESG if IANA believes there is some other reason to

        reject the registration, including but not limited to
        poor taste, or likely confusion (too similar to another vendor-ID),
        MAY reject the registration upon its discretion.

        A party whose vendor-ID registration has been rejected for reason
        than duplication may ask for review of the registration by the IESG,
        the manner described in RFC 2026, section 6.5.

6.0 References

[1]   Petke, R., King, I., "Registration Procedures for URL Scheme
      Names", RFC 2717, November 1999

[2]   Freed, N., Klensin, J., Postel, J., "Multipurpose Internet Mail
      Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
      November 1996

[3]   Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., "Guidelines
      for New URL Schemes", RFC 2718, November 1999

[4]   Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
      Identifiers (URI): Generic Syntax", RFC 2396, August 1998

[5]   Postel, J., Reynolds, J., "Instructions to RFC Authors", RFC
      2223, October 1997.

[6]     Bradner, S., "The Internet Standards Process -- Revision 3", RFC
        October 1996.

6.0  Author's Address

        Ian King
        Microsoft Corporation
        One Microsoft Way
        Redmond, WA  98052-6399
        Phone: +1 425-703-2293
        FAX: +1 425-936-7329
        Email: iking@microsoft.com

APPENDIX A: Form for submission of vendor and scheme information for VND


1)      This form is modeled in large part on the suggested submission
        format set forth in RFC 2717.

2)      If this is a first submission for a given vendor-ID, it is necessary
        to complete Section A, "Vendor Information".  If the vendor-ID is
        already registered to you, you can provide only the vendor-ID.  This
        form should also be used for any changes to vendor information.

SECTION A - Vendor Information

NOTE:   "Vendor entity type" should describe the nature of the vendor, i.e.
        corporation, educational institution, sole proprietorship, etc.


        Vendor Name:

        Vendor Address:

        Vendor Telephone:

        Vendor Entity Type:

        Vendor Contact Information:

SECTION B - Scheme Information

NOTE:   only the scheme name is required for registration, but you are
        encouraged to provide as much information as possible.  For a
        detailed description of each item, please refer to RFC 2717,
        Section 6.0.

        URL scheme name:

        URL scheme syntax:

        Character encoding considerations:

        Intended usage:

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

        Interoperability considerations:

        Security considerations:

        Relevant publications:

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/