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

Versions: 00 01 02 03

INTERNET-DRAFT                                                  I. King
<draft-king-vnd-urlscheme-00.txt>                 Microsoft Corporation
                                                          March 5, 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 September 5, 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 implementations 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 particular
        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.

        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 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 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 alphabetic.  In particular, the character `.' is
        specifically disallowed.  The vendor-ID must be registered with
        IANA, and IANA may disapprove a registration for failure to meet
        syntax rules, for conflict or confusion with another vendor-ID, for
        being an inappropriate identifier for the vendor (for instance, if
        Microsoft sought to use the vendor-ID `sun'), or for being
        objectionable in some other way (for instance, a word generally
        considered profane or offensive).  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 should comply with RFC
        [URL-GUIDELINES].

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
        the new scheme.  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 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 used,
        vendor B might ignorantly redefine a URL scheme in a way that breaks
        vendor A's products.

        IANA will maintain a public registry of the vendor-IDs that have
        been assigned, together with contact information.

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

        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 tree and 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 section 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.129d, available from https://tools.ietf.org/tools/rfcmarkup/