INTERNET-DRAFT I. King 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- 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 January 14, 2001. Copyright Notice Copyright (C) The Internet Society (2000). 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 2717 [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 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: 'vnd.''.' 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 . 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 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 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 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. 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 be 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 misrepresentation, poor taste, or likely confusion (too similar to another vendor-ID), and MAY reject the registration upon its discretion. A party whose vendor-ID registration has been rejected for reason other than duplication may ask for review of the registration by the IESG, in 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 2026, October 1996. 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 ---------- APPENDIX A: Form for submission of vendor and scheme information for VND tree NOTES: 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-ID: 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: