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

Versions: 00 01 02 03

INTERNET-DRAFT                                                  I. King
<draft-king-vnd-urlscheme-01.txt>                 Microsoft Corporation
                                                           June 7, 1999

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

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt.

        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

        This Internet-Draft expires December 7, 1999.

Copyright Notice

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

Abstract

        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 [URL-
        PROCESS][1] requires IESG review and approval of all proposed
        scheme names within the "IETF tree", which encompasses simple,
        short, often descriptive URL 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 implemen-
        tations in the URL scheme namespace.  However, this form of URL
        scheme name is often selected because the name is intended to be
        widely distributed, seen and used, possibly by naive users.  In
        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.

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:

                        'vnd.'<vendor-ID>'.'<scheme-ID>

        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 [URL-GUIDELINES], 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 [URL-GUIDELINES]; 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
        disallowed.

        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 [URL-GUIDELINES].
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
        semantics.

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.

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 [URL-PROCESS].

        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
        [URL-PROCESS].

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 [URL-GUIDELINES].

        Vendors should exercise caution around the security risks posed by a

        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 References

[1]     Petke, R., King, I., "Registration Procedures for URL Scheme
        Names", RFC [URL-PROCESS], November 1998

[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 [URL-GUIDELINES], August 1998

[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.0  Author's Address

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


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