INTERNET-DRAFT I. King 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.''.' 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 . 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