Network Working Group T. Hansen Internet-Draft AT&T Laboratories Expires: April 15, 2005 T. Hardie Qualcomm, Inc. L. Masinter Adobe Systems October 15, 2004 Guidelines and Registration Procedures for new URI Schemes draft-hansen-2717bis-2718bis-uri-guidelines-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 April 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document provides guidelines and recommendations for the definition of new URI schemes, and a mechanism to register those URI schemes. Hansen, et al. Expires April 15, 2005 [Page 1] Internet-Draft New URI Schemes October 2004 This is a first draft attempt to capture the sense of direction for updates to RFC 2717 and RFC 2718. These changes were discussed at the August 26, 2004 URIREV4 BOF: see http://lists.w3.org/Archives/Public/uri/2004Aug/0007.html for the minutes. Please send comments to uri@w3.org. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Guidelines for new URI schemes . . . . . . . . . . . . . . . . 5 2.1 Important Considerations . . . . . . . . . . . . . . . . . 5 2.1.1 non-Locator schemes . . . . . . . . . . . . . . . . . 5 2.1.2 Demonstratable, new, long-lived utility . . . . . . . 5 2.1.3 Syntactic compatibility . . . . . . . . . . . . . . . 5 2.1.4 Avoid improper use of "//" following ":" . . . 6 2.1.5 Compatibility with relative URIs . . . . . . . . . . . 6 2.2 Is the scheme well defined? . . . . . . . . . . . . . . . 6 2.2.1 Clear mapping from other name spaces . . . . . . . . . 6 2.2.2 URI schemes associated with network protocols . . . . 7 2.2.3 Definition of non-protocol URI schemes . . . . . . . . 7 2.2.4 Definition of URI schemes not associated with data resources . . . . . . . . . . . . . . . . . . . . . . 7 2.2.5 Character encoding . . . . . . . . . . . . . . . . . . 7 2.2.6 Definition of operations . . . . . . . . . . . . . . . 8 2.3 Demonstrated utility . . . . . . . . . . . . . . . . . . . 8 2.3.1 Proxy into HTTP/HTML . . . . . . . . . . . . . . . . . 8 2.4 Are there security considerations? . . . . . . . . . . . . 9 2.5 Does it start with UR? . . . . . . . . . . . . . . . . . . 9 2.6 Non-considerations . . . . . . . . . . . . . . . . . . . . 9 2.6.1 Are all objects accessible? . . . . . . . . . . . . . 9 3. URI Scheme Name Registration . . . . . . . . . . . . . . . . . 10 3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 The Permanent URI Scheme Name Status . . . . . . . . . 10 3.1.2 The Provisional URI Scheme Name Status . . . . . . . . 10 3.2 Requirements for Scheme Name Registration . . . . . . . . 10 3.2.1 General Requirements . . . . . . . . . . . . . . . . . 10 3.2.2 Permanent URI Scheme Names . . . . . . . . . . . . . . 11 3.2.3 Provisional URI Scheme Names . . . . . . . . . . . . . 11 3.3 Registration Procedures . . . . . . . . . . . . . . . . . 12 3.3.1 Permanent URI Scheme Names . . . . . . . . . . . . . . 12 3.3.2 Provisional URI Scheme Names . . . . . . . . . . . . . 13 3.3.3 Objections to Registration . . . . . . . . . . . . . . 13 3.4 Change Control . . . . . . . . . . . . . . . . . . . . . . 14 3.4.1 Permanent URI Scheme Names . . . . . . . . . . . . . . 14 3.4.2 Provisional URI Scheme Names . . . . . . . . . . . . . 14 3.5 New URI Scheme Registration Template . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Hansen, et al. Expires April 15, 2005 [Page 2] Internet-Draft New URI Schemes October 2004 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 7.2 Informative References . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 19 Hansen, et al. Expires April 15, 2005 [Page 3] Internet-Draft New URI Schemes October 2004 1. Introduction A Uniform Resource Identifier (URI) is a compact string representation for identifying resources. RFC XXXX [6] defines the general syntax of URIs. This document provides guidelines for the definition of new URI schemes (for consideration by those who are defining and registering or evaluating those definitions), and a process and mechanism for registering URI schemes. This document replaces RFCs 2717 [2] and 2718 [3]. The original terminology for the URI protocol element attempted to draw a distinction between 'locators': identifiers used for accessing resources available on the Internet, and 'names': identifiers used for naming possibly abstract resources, independent of any mechanism for accessing them. The intent was to use the designation "URL" (Uniform Resource Locator) for those identifiers that were locators, and "URN" (Uniform Resource Name) for those identifiers that were names. In practice, the line between 'locator' and 'name' cannot be drawn precisely: locators can be used as names, and names can be used as locators. As a result, recent documents have used the term "URI" for all resource identifiers following the definition of RFC XXXX [6], avoiding the term "URL", and reserving the term "URN" explicitly for those URIs using the "urn" scheme name (RFC 2141 [1]). URNs remain a distinct class of URIs because of the requirements set out in RFC 3406 [8]; this document's procedures do not update or supersede the procedures set out in RFC 3406. RFC 2717 defined a set of registration trees in which URI schemes could be registered, one of which was called the IETF Tree, to be managed by IANA. The registration process is needed to ensure that the names of all such new schemes are guaranteed not to collide. Further, the registration process ensures that URI schemes intended for wide spread, public use are developed in an orderly, well-specified, and public manner. RFC 2717 also allowed additional registration trees to be approved by the IESG, although no such registration trees have been approved. This document eliminates the distinction between different 'trees' for URI schemes, and instead establishes a single namespace for registered values. Within that namespace, there are values that are approved as meeting a set of criteria for URI schemes; other scheme names may also be registered provisionally or without necessarily passing the review process or criteria. Its intent is to: o provide a central point of discovery for established URI scheme names, and easy location of their defining documents; Hansen, et al. Expires April 15, 2005 [Page 4] Internet-Draft New URI Schemes October 2004 o discourage multiple definitions of URI scheme names for different purposes; o and to help those proposing new URI scheme names to discern established trends and conventions, and to avoid names that might be confused with existing ones. 2. Guidelines for new URI schemes 2.1 Important Considerations This section lists important considerations for URI scheme definitions. It is useful for all URI definitions, whether standards track or not, to follow these guidelines. The review process for IETF standards track URI schemes may require review against these criteria. 2.1.1 non-Locator schemes While it is acknowledged that URIs may or may not be useful as locators, it is important that the URI scheme definition itself be clear as to how it is expected to function. Schemes that are not intended to be used as locators must describe how the resource identified should be interpreted by software that obtains a URI of that scheme. 2.1.2 Demonstratable, new, long-lived utility Because URI schemes are a single, global namespace, the unbounded registration of new schemes is harmful to the Internet community. For this reason, new URI schemes should have clear utility to the broad Internet community, beyond that available with already registered URI schemes. 2.1.3 Syntactic compatibility RFC XXXX [6] defines a generic syntax for URI schemes with hierarchical components and a naming authority. New URI schemes should follow this syntax if appropriate. The generic handling of relative URIs depends on this. URI schemes that are not intended for use with relative URIs should avoid use of the forward slash "/" character, which is used for hierarchical delimiters. In some circumstances, when a URI scheme does not fit into the existing RFC XXXX syntax, the new scheme definition should follow the syntax of other previously registered schemes, if possible. Hansen, et al. Expires April 15, 2005 [Page 5] Internet-Draft New URI Schemes October 2004 2.1.4 Avoid improper use of "//" following ":" The use of double slashes as the first component of the of a URI is not simply an artistic indicator that what follows is a URI: Double slashes are used ONLY when the syntax of the URI's contains a hierarchical structure as described in RFC XXXX. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section ???? of RFC XXXX for more details.) URI schemes which do not contain a conformant hierarchical structure in their should not use double slashes following the ":" string. 2.1.5 Compatibility with relative URIs URI schemes should use the generic URI syntax if they are intended to be used with relative URIs. A description of the allowed relative forms should be included in the scheme's definition. Many applications use relative URIs extensively. Specifically, o Can the scheme be parsed according to RFC XXXX - for example, if the tokens "//", "/", ";", or "?" are used, do they have the meaning given in RFC XXXX? o Does the scheme make sense to use it in relative URIs like those RFC XXXX specifies? o If the scheme syntax is designed to be broken into pieces, does the documentation for the scheme's syntax specify what those pieces are, why it should be broken in this way, and why the breaks aren't where RFC XXXX says that they usually should be? o If the scheme has a hierarchy, does it go left-to-right and with slash separators like RFC XXXX? 2.2 Is the scheme well defined? It is important that the semantics of the "resource" that a URI "locates" be well defined. This might mean different things depending on the nature of the URI scheme. 2.2.1 Clear mapping from other name spaces In many cases, new URI schemes are defined as ways to translate other protocols and name spaces into the general framework of URIs. The "ftp" URI scheme translates from the FTP protocol, while the "mid" URI scheme translates from the Message-ID field of messages. In either case, the description of the mapping must be complete, must describe how characters get encoded or not in URIs, must describe exactly how all legal values of the base standard can be represented using the URI scheme, and exactly which modifiers, alternate forms Hansen, et al. Expires April 15, 2005 [Page 6] Internet-Draft New URI Schemes October 2004 and other artifacts from the base standards are included or not included. These requirements are elaborated below. 2.2.2 URI schemes associated with network protocols Most new URI schemes are associated with network resources that have one or several network protocols that can access them. The 'ftp', 'news', and 'http' schemes are of this nature. For such schemes, the specification should completely describe how URIs are translated into protocol actions in sufficient detail to make the access of the network resource unambiguous. If an implementation of the URI scheme requires some configuration, the configuration elements must be clearly identified. (For example, the 'news' scheme, if implemented using NTTP, requires configuration of the NTTP server.) 2.2.3 Definition of non-protocol URI schemes In some cases, URI schemes do not have particular network protocols associated with them, because their use is limited to contexts where the access method is understood. This is the case, for example, with the "cid" and "mid" URI schemes. For these URI schemes, the specification should describe the notation of the scheme and a complete mapping of the locator from its source. 2.2.4 Definition of URI schemes not associated with data resources Most URI schemes locate Internet resources that correspond to data objects that can be retrieved or modified. This is the case with "ftp" and "http", for example. However, some URI schemes do not; for example, the "mailto" URI scheme corresponds to an Internet mail address. If a new URI scheme does not locate resources that are data objects, the properties of names in the new space must be clearly defined. 2.2.5 Character encoding When describing URI schemes in which (some of) the elements of the URI are actually representations of sequences of characters, care should be taken not to introduce unnecessary variety in the ways in which characters are encoded into octets and then into URI characters. Unless there is some compelling reason for a particular scheme to do otherwise, translating character sequences into UTF-8 (RFC 2279 [4]) and then subsequently using the %HH encoding for unsafe octets is recommended. Hansen, et al. Expires April 15, 2005 [Page 7] Internet-Draft New URI Schemes October 2004 2.2.6 Definition of operations In some contexts (for example, HTML forms) it is possible to specify any one of a list of operations to be performed on a specific URI. (Outside forms, it is generally assumed to be something you GET.) The URI scheme definition should describe all well-defined operations on the URI identifier, and what they are supposed to do. Some URI schemes (for example, "telnet") provide location information for hooking onto bi-directional data streams, and don't fit the "infoaccess" paradigm of most URIs very well; this should be documented. NOTE: It is perfectly valid to say that "no operation apart from GET is defined for this URI". It is also valid to say that "there's only one operation defined for this URI, and it's not very GET-like". The important point is that what is defined on this type is described. 2.3 Demonstrated utility URI schemes should have demonstrated utility. New URI schemes are expensive things to support. Often they require special code in browsers, proxies, and/or servers. Having a lot of ways to say the same thing needless complicates these programs without adding value to the Internet. The kinds of things that are useful include: o Things that cannot be referred to in any other way. o Things where it is much easier to get at them using this scheme than (for instance) a proxy gateway. 2.3.1 Proxy into HTTP/HTML One way to provide a demonstration of utility is via a gateway which provides objects in the new scheme for clients using an existing protocol. It is much easier to deploy gateways to a new service than it is to deploy browsers that understand the new URI object. Things to look for when thinking about a proxy are: o Is there a single global resolution mechanism whereby any proxy can find the referenced object? o If not, is there a way in which the user can find any object of this type, and "run his own proxy"? o Are the operations mappable one-to-one (or possibly using modifiers) to HTTP operations? o Is the type of returned objects well defined? Hansen, et al. Expires April 15, 2005 [Page 8] Internet-Draft New URI Schemes October 2004 * as MIME content-types? * as something that can be translated to HTML? o Is there running code for a proxy? 2.4 Are there security considerations? Above and beyond the security considerations of the base mechanism a scheme builds upon, one must think of things that can happen in the normal course of URI usage. In particular: o Does the user need to be warned that such a thing is happening without an explicit request (GET for the source of an IMG tag, for instance)? This has implications for the design of a proxy gateway, of course. o Is it possible to fake URIs of this type that point to different things in a dangerous way? o Are there mechanisms for identifying the requester that can be used or need to be used with this mechanism (the From: field in a mailto: URI, or the Kerberos login required for AFS access in the AFS: URI, for instance)? o Does the mechanism contain passwords or other security information that are passed inside the referring document in the clear (as in the "ftp" URI, for instance)? 2.5 Does it start with UR? Any scheme starting with the letters "U" and "R", in particular if it attaches any of the meanings "uniform", "universal" or "unifying" to the first letter, is going to cause intense debate, and generate much heat (but maybe little light). Any such proposal should either make sure that there is a large consensus behind it that it will be the only scheme of its type, or pick another name. 2.6 Non-considerations Some issues that are often raised but are not relevant to new URI schemes include the following. 2.6.1 Are all objects accessible? Can all objects in the world that are validly identified by a scheme be accessed by any UA implementing it? Sometimes the answer will be yes and sometimes no; often it will depend on factors (like firewalls or client configuration) not Hansen, et al. Expires April 15, 2005 [Page 9] Internet-Draft New URI Schemes October 2004 directly related to the scheme itself. 3. URI Scheme Name Registration 3.1 General In order to increase the efficiency and flexibility of the URI scheme name registration process, the need is recognized for multiple registration statuses. The registration requirements and specific registration procedures for each status differ, allowing the overall registration procedure to accommodate the different natural requirements for URI schemes. For example, a scheme that will be recommended for wide support and implementation by the Internet community requires a more complete review than a scheme intended to be used for resources associated with proprietary software. The first step in registering a new URI scheme name is to determine which status the scheme should be registered with. Determination of the proper category is based on the intended use for the new scheme and the desired syntax for the scheme name. There are two statuses of URI scheme name registration defined in this document: permanent and provisional. 3.1.1 The Permanent URI Scheme Name Status The permanent URI scheme name status is intended for URI schemes of general interest to the Internet community. The status exists for URI schemes that require a substantive review and approval process. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, URI schemes that have proven particularly useful in those contexts. 3.1.2 The Provisional URI Scheme Name Status The Provisional URI scheme name category is intended for any URI scheme proposed by any developer, without making any claim about its usefulness or the quality of its definition. These URI scheme names are intended for private or experimental use. 3.2 Requirements for Scheme Name Registration 3.2.1 General Requirements All new URI schemes, regardless of registration status, MUST conform to the generic syntax for URIs as specified in RFC XXXX. Hansen, et al. Expires April 15, 2005 [Page 10] Internet-Draft New URI Schemes October 2004 3.2.2 Permanent URI Scheme Names Permanent registration of a URI scheme requires publication of the URI scheme syntax and semantics in either an Informational or Standards Track RFC. In general, the creation of a new permanent URI scheme requires a Standards Track RFC. An Informational RFC may be employed for registration only in the case of a URI scheme which is already in wide usage and meets other standards set forth in Section 2, such as "demonstrated utility" within the Internet Architecture; the IESG shall have broad discretion in determining whether an Informational RFC is suitable in any given case, and may either recommend changes to such document prior to publication, or reject it for publication. An Informational RFC purporting to describe a URI scheme shall not be published without IESG approval. This is a departure from practice for Informational RFCs as set forth in RFC 2026 [7], for the purpose of ensuring that the registration of URI schemes shall serve the best interests of the Internet community. The NAMES of permanent URI name schemes MUST NOT contain the dash (also known as the hyphen and minus sign) character ('-') USASCII value 2Dh. Use of this character can cause confusion with private URI name schemes. An analysis of the security issues inherent in the new URI scheme is REQUIRED. (This is in accordance with the basic requirements for all IETF protocols.) Permanent URI name schemes should not introduce additional security risks into the Internet Architecture. For example, URIs should not embed information which should remain confidential, such as passwords, nor should new schemes subvert the security of existing schemes or protocols (i.e. by layering or tunneling). The "owner" of a permanet URI scheme name is assumed to be the IETF itself. Modification or alteration of the specification requires the same level of processing (e.g. Informational or Standards Track RFC) as used for the initial registration. Schemes originally defined via an Informational RFC may, however, be replaced with Standards Track documents. 3.2.3 Provisional URI Scheme Names Registration of a provisional URI scheme does not imply any kind of endorsement by the IETF, IANA or any other body. The main requirements for a provisional URI scheme are that it SHOULD have a citable specification, and there MUST NOT be a corresponding entry (with the same URI scheme name) with a permanent status. Hansen, et al. Expires April 15, 2005 [Page 11] Internet-Draft New URI Schemes October 2004 The specification SHOULD indicate an email address for sending technical comments and discussion of the proposed URI scheme. Provisional URI name schemes MUST conform to the generic URI syntax, RFC XXXX. The provisional URI name scheme's defining document MAY set forth additional syntax and semantics requirements above and beyond those specified in RFC XXXX. All new provisional URI schemes SHOULD follow the Guidelines for URI Schemes, set forth in Section 2. An analysis of the security issues inherent in the new URI scheme is encouraged. Regardless of what security analysis is or is not performed, all descriptions of security issues must be as accurate as possible. In particular, a statement that there are "no security issues associated with this scheme" must not be confused with "the security issues associates with this scheme have not been assessed" or "the security issues associated with this scheme cannot be predicted because of ". There is absolutely no requirement that provisional URI name schemes be secure or completely free from risks. Nevertheless, the URI name scheme's defining document must set forth the standard for security considerations, and in any event all known security risks SHOULD be identified. 3.3 Registration Procedures 3.3.1 Permanent URI Scheme Names The first step in registering a new permanent URI scheme is to publish an IETF Internet-Draft detailing the syntax and semantics of the proposed scheme. The draft must, minimally, address all of the items covered by the template provided in Section 3.5 of this document. There must be an IANA considerations section in the Internet-Draft calling for registration of the URI scheme and referencing information as required by the registration template within the same document. After all issues raised during a review period of no less than 4 weeks have been addressed, submit the draft to the IESG for review. The IESG will review the proposed new scheme and either refer the scheme to a working group (existing or new) or directly present the scheme to the IESG for a last call. In the former case, the working group is responsible for submitting a final version of the draft to the IESG for approval at such time as it has received adequate review and deliberation. Hansen, et al. Expires April 15, 2005 [Page 12] Internet-Draft New URI Schemes October 2004 Registration of the URI scheme is then processed as part of the RFC publication process. 3.3.2 Provisional URI Scheme Names Registration of provisional URI scheme names may be submitted by one of the following methods: o An IANA considerations section in a defining RFC, calling for registration of the URI scheme and referencing information as required by the registration template within the same document. Registration of the URI scheme is then processed as part of the RFC publication process. o Send a copy of the template to the designated email discussion list [????]. Allow a reasonable period - at least 2 weeks - for discussion and comments, then send the template to IANA at the designated email address [????]. IANA will publish the template information if the requested name and the specification document meet the criteria noted in Section 3.2.3, unless the IESG or their designated expert have requested that it not be published (see Section 3.3.3). IESG's designated expert should confirm to IANA that the registration criteria have been satisfied. When a new permanent URI scheme name is recorded, IANA will remove any corresponding entries (with the same URI scheme name and protocol) from the provisional registry. Companies and other bodies that desire a private name space for URI scheme names are encouraged to use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com-example-info might be registered by the vendor that owns the example.com domain name. 3.3.3 Objections to Registration Listing of an entry in the provisional repository should not be lightly refused. An entry MAY be refused if there is some credible reason to believe that such registration will be harmful. In the absence of such objection, IANA SHOULD allow any registration that meets the criteria set out in Section 3.2.2 and Section Section 3.2.3. Some reasonable grounds for refusal might be: o There is IETF consensus that publication is considered likely to harm the Internet technical infrastructure in some way. o Disreputable or frivolous use of the registration facilities. o The proposal is sufficiently lacking in purpose, or misleading about its purpose, that it can be held to be a waste of time and effort. o Conflict with some current IETF activity. Hansen, et al. Expires April 15, 2005 [Page 13] Internet-Draft New URI Schemes October 2004 Note that objections or disagreements about technical detail are not, of themselves, considered grounds to refuse listing in the provisional repository. After all, one of its purposes is to allow developers to communicate with a view to combining their ideas, expertise and energy to the maximum benefit of the Internet community. Publication in an RFC or other form of Open Standard document (per RFC 2026 [7], section 7) is sufficient grounds for publication in the permanent registry. To assist IANA in determining whether or not there is a sustainable objection to any registration, IESG nominates a designated expert to liaise with IANA about new registrations. For the most part, the designated expert's role is to confirm to IANA that the registration criteria have been satisfied. The IESG or their designated expert MAY require any change or commentary to be attached to any registry entry. Note: It is not an error for two different entities to register the same provisional URI scheme name for two different purposes. One of the purposes for this registry is to help make people aware of what URI scheme names are being used by other entities. The IESG is the final arbiter of any objection. 3.4 Change Control 3.4.1 Permanent URI Scheme Names Permanent URI name schemes are "owned" by the IETF itself and may be changed, as needed, by updating the RFC that describes them. Schemes described by Standards Track RFC may be replaced with new Standards Track RFCs. Informational RFCs may be replaced by new Informational RFCs or Standards Track RFCs. 3.4.2 Provisional URI Scheme Names Provisional URL schemes that are undocumented may be changed by their owner at any time without notifying the IETF. Provisional URL schemes that have been documented by an Informational RFC, may be changed at any time by the owner. However, an updated Informational RFC which details the changes made, must be submitted to the IESG. The owner of a provisional URL scheme and documented by an Hansen, et al. Expires April 15, 2005 [Page 14] Internet-Draft New URI Schemes October 2004 Informational RFC may pass responsibility for the registration to another person or agency by informing the IESG. The IESG may reassign responsibility for a provisional URL scheme registered in an alternative tree and documented by an Informational RFC. The most common case of this will be to enable changes to be made to schemes where the scheme name is privately owned, and the owner of the scheme name has died, moved out of contact or is otherwise unable to make changes that are important to the community. The IESG may reclassify a provisional URL scheme and documented via an Informational RFC as "historic", if it determines that the scheme is no longer in use. IANA MAY remove any provisional URI scheme entry whose corresponding specification document is no longer available (e.g., expired Internet-draft, or URI not resolvable). Anyone may notify IANA of any such cases by sending an email to the designated email address [????]. Before removing an entry for this reason, IANA SHOULD contact the registered Author/Change controller to determine whether a replacement for the specification document (consistent with the requirements of section Section 3.2) is available. 3.5 New URI Scheme Registration Template The following issues should be addressed when documenting a new URI scheme: URI scheme name. Status. This will be one of 'permanent', 'provisional' or 'historic'. URI scheme syntax. This should be expressed in a clear and concise manner. The use of ABNF is encouraged. Please refer to Section 2.1 for guidance on designing and explaining your scheme's syntax. Character encoding considerations. It is important to identify what your scheme supports in this regard. It is obvious that for interoperability, it is best if there is a means to support character sets beyond USASCII, but especially for private schemes, this may not be the case. Intended usage. What sort of resource is being identified? If this is not a 'resource' type of URI (e.g. mailto:), explain the action that should be initiated by the consumer of the URI. If there is a MIME type associated with this resource, please identify it. Applications and/or protocols which use this URI scheme name. Including references to documentation which defines the applications and/or protocols cited is especially useful. Hansen, et al. Expires April 15, 2005 [Page 15] Internet-Draft New URI Schemes October 2004 Interoperability considerations. If you are aware of any details regarding your scheme which might impact interoperability, please identify them here. For example: proprietary or uncommon encoding method; inability to support multibyte character sets; incompatibility with types or versions of underlying protocol (if scheme is tunneled over another protocol). Security considerations. Relevant publications. Contact. Person & email address to contact for further information. Author/Change controller. Application/protocol. Applications and/or protocols which use this URI scheme name. 4. IANA Considerations This document updates the Uniform Resource Identifier (URI) Schemes registration table. The template has an additional field for the status of the URI name scheme, and the procedures for entering new name schemes have been augmented. All existing URI name schemes in the existing table should be given the status of 'permanent'. 5. Security Considerations New URI schemes are required to address all security considerations in their definitions. Information that creates or updates a registration needs to be authenticated. Information concerning possible security vulnerabilities of a protocol may change over time. Consequently, claims as to the security properties of a registered URI scheme may change as well. As new vulnerabilities are discovered, information about such vulnerabilities may need to be attached to existing documentation, so that users are not misled as to the true security properties of a registered URI scheme. 6. Acknowledgements Some of the text for the provisional registration status is based on [9]. 7. References 7.1 Normative References [1] Moats, R., "URN Syntax", RFC 2141, May 1997. Hansen, et al. Expires April 15, 2005 [Page 16] Internet-Draft New URI Schemes October 2004 [2] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999. [3] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999. [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] "Uniform Resource Identifiers (URI): Generic Syntax", ????. 7.2 Informative References [7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [8] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [9] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. Authors' Addresses Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA EMail: tony+urireg@maillennium.att.com Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA USA EMail: hardie@qualcomm.com Hansen, et al. Expires April 15, 2005 [Page 17] Internet-Draft New URI Schemes October 2004 Larry Masinter Adobe Systems 345 Park Ave San Jose, CA 95110 US Phone: +1 408 536 3024 EMail: LMM@acm.org URI: http://larry.masinter.net Hansen, et al. Expires April 15, 2005 [Page 18] Internet-Draft New URI Schemes October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hansen, et al. Expires April 15, 2005 [Page 19]