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 will expire on March 6, 2004.

Copyright Notice

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

Abstract

This document describes a way in which individuals and vendors can define URI schemes in a way that avoids name collisions, but with relaxed registration requirements. This is done by allowing URI schemes that start with "vnd-" or "prs-", analogous to a similar mechanism for MIME media types.

Note

Discuss this document on uri@w3.org. A HTML version of this document can be found at http://larry.masinter.net/vnduri.html.

1. Introduction

The registration process for URI schemes, described in RFC 2717[2], requires IESG review and approval of all proposed scheme names within the "IETF tree", which encompasses simple, short, often descriptive URI scheme names (such as http:, fax:, or mailto:).

However, there are circumstances where it is desirable to allocate a URI scheme name outside of this process. This document establishes alternative trees, "vnd-" and "prs-", corresponding to the similar concept for MIME type registrations[4]. The rules for use and registration of URI schemes with in these trees are intended to be analogous those for the corresponding MIME type trees.

The "vnd-" tree is used for URI schemes associated with available products or services; "vendor" or "producer" are construed as equivalent and broadly. The registration belongs to the vendor or organization producing software or offering a service that utilizes the URI scheme. Registration in the vendor tree is distinguished by the leading "vnd-", followed, at the discretion of the registration, either by the scheme name or (preferably) by an IANA-approved designation of the producer's name, followed by the specific scheme name. Designations of producers should match those used for media types, and follows the same criteria.

Similarly, the "prs-" tree is intended for URI schemes used experimentally or as individual contributions. The owner of "personal" registrations and associated specifications is the person or entity making the registration, or one to whom responsibility has been transferred as described below.

Note that earlier drafts of this document suggested using "." as the delimiter between "vnd" and the URI scheme. However, RC 2717[2] reserved the "-" character for non-IETF registrations (and not "."), so the delimiter was changed for compatibility. Because these earlier drafts were available for several years, however, there may be some URI schemes with "vnd." still in use.

2. Syntax

The general syntax for these new trees follows the syntax recommended in RFC 2717[2]:

     scheme     = ("vnd-" / "prs-") [ vendor-id "-" ] scheme-id
     vendor-id  = ALPHA *(ALPHA / DIGIT / "+" )
     scheme-id  = ALPHA *(ALPHA / DIGIT / "+" / "-" / "." )
 

2.1 Syntax notes

Note that RFC 2396[1] limits the characters in URI scheme names to include only letters, digits, plus ("+"), period ("."), or hyphen ("-"); further, that although scheme names are case insensitive, the canonical form is lowercase and documents that specify schemes must do so using lowercase letters. These restrictions apply to <vendor-id> and <scheme-id>.

To avoid confusion, a <vendor-id> may not contain a hyphen "-" or a period ".".

2.2 Choosing a vendor-id

The vendor-id is an IANA-approved designation, consisting of a short string of characters that is sufficient to uniquely identify the organization.

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. Organizations should use the same vendor-id for MIME types and URI schemes.

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

IANA may choose to reject a request for a particular vendor-id or propose a different vendor-id based on IANA's best judgment as to whether the string proposed is appropriate for the organization requesting it.

2.3 Syntax for scheme-id

There are no formal restrictions on the scheme-id except that the characters be chosen from those allowed in a URI scheme name (letters, digits, plus, period, hyphen), and be registered using the lowercase form. The registrar is encouraged to select a scheme-id that is short and descriptive of its purpose.

3. Requirements for Scheme Name Registration

3.1 General Requirements

The purpose of registration is to give notice to the Internet community of the existence the scheme. Registration of the vendor-id is required, and serves to partition the namespace (and avoid collision).

Similarly, to avoid collision and misuse, registration of "prs-" and "vnd-" schemes without vendor-id parts is required.

If the vendor-id is registered, registration of a specific scheme-id is optional; if supplied, the registrar may supply whatever information is appropriate. Registration may only consist of the scheme name, or might include a pointer to appropriate documentation of the scheme's syntax and semantics.

3.2 Registering the vendor-id

The request for vendor-id registration may be sent separately, or may be included in a scheme name registration. The initial request for vendor-id names 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 of changes in this information, and may explicitly transfer ownership of its vendor-id and associated subtree.

A given vendor-id can be issued only once, and it does not expire. This is to avoid possible name collisions, since using a registered vendor-id means there may be URI schemes that are not otherwise registered.

IANA should maintain a public registry of the vendor-id's, together with contact information for each vendor so registered. A form for submission of this information (together with scheme information as appropriate) is provided in this document.

3.3 Publishing Scheme-Specific Information

While public exposure and review of a URI scheme created in the "vnd-" or "prs-" tree is not required, it is encouraged. The 'uri-review@ietf.org' mailing list may be used for review of new URI schemes, even if they are not in the IETF tree.

Publication of the scheme description as an Informational RFC may be appropriate for those schemes of sufficient interest to the IETF community; however, this mechanism is usually appropriate only for URI schemes in the IETF tree.

Note that a separate, explicit request should be made to IANA (at IANA@iana.org) to register schemes; discussion on uri-review@ietf.org is insufficient. The request should follow the form is provided in Appendix A of this document.

Internet Drafts intended for publication as Informational RFCs describing new URI schemes should also contain an 'IANA Considerations' section with the request for registration included. The registration would occur at the time of publication of the document as an RFC.

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 URI schemes deployed therein. If a vendor publishes information about a vnd URI scheme by either of the methods described above, changes to the syntax or semantics of that URI scheme must be subsequently published by the same medium as originally employed.

4. Security Considerations

The vendor identified by the vendor-id part of the URI scheme name should be consulted for any information regarding the URI 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.)

The registration process encourages vendors to analyze and disclose the security implications of using particular URI schemes. Unregistered schemes or those without appropriate security considerations may be unsafe to use.

5. IANA Considerations

IANA currently maintains a registry of URI scheme names, per the requirements of RFC 2717. Scheme names established under this process should also be entered in that registry, when requested.

IANA should maintain a separate registry of vendor-id strings, relating the vendor-id to the vendor information (business contact information, etc.) provided in the registration. The vendor-id string list should be used also for vendor strings used in media types, as per RFC 2048. IANA should reject a vendor-id registration if it duplicates an existing registration, seems inappropriate, confusing, misleading, or too similar to another registered vendor-id, at IANA's discretion. IANA may offer an alternative vendor-id string that IANA considers more appropriate.

A party whose vendor-id registration has been rejected or modified may ask for review of the registration by the IESG, in the manner described in RFC 2026, section 6.5.

6. Registration forms

Form for vendor information:

   Vendor-ID:        proposed identifier
   Name:      formal name of organization
   Address:   full name of organization
   Telephone: full telephone number
   Type:      type of organization (corporation, educational
                institution, etc.)
   Contact Information:  name of contact person and location information
 

The form for scheme names follows RFC 2717, section 6.0.

    Scheme name: 
    Scheme syntax:
    Character encoding considerations:
    Intended usage:
    Applications and/or protocols which use this URL scheme name:
    Interoperability considerations:
    Security considerations: 
    Relevant publications: 
  

Normative References

Informative References

Authors' Addresses

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.