Internet Engineering Task Force (IETF) D. Thaler, Ed. Request for Comments: 7595 Microsoft Obsoletes: 4395 T. Hansen BCP: 35 AT&T Laboratories Category: Best Current Practice T. Hardie ISSN: 2070-1721 Google June 2015 Guidelines and Registration Procedures for URI Schemes
AbstractThis document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7595. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements for Permanent Scheme Definitions . . . . . . . . 4 3.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . . 4 3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 4 3.3. Well Defined . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Definition of Operations . . . . . . . . . . . . . . . . 6 3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . 6 3.6. Internationalization and Character Encoding . . . . . . . 7 3.7. Clear Security and Privacy Considerations . . . . . . . . 7 3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 8 3.9. Interoperability Considerations . . . . . . . . . . . . . 9 4. Guidelines for Provisional URI Scheme Registration . . . . . 9 5. Guidelines for Historical URI Scheme Registration . . . . . . 10 6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 10 7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 10 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Registration Procedures . . . . . . . . . . . . . . . . . 11 7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 13 7.4. URI Scheme Registration Template . . . . . . . . . . . . 13 8. The "example" URI Scheme . . . . . . . . . . . . . . . . . . 14 8.1. "example" URI Scheme Registration Request . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 Contributor . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 RFC3986]. Each URI begins with a scheme name, as defined by Section 3.1 of RFC 3986, that refers to a specification for identifiers within that scheme. The URI syntax provides a federated and extensible naming system, where each scheme's specification can further restrict the syntax and define the semantics of identifiers using that scheme. This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] and [RFC2718]. Recent documents have used the term "URI" for all resource identifiers, avoiding the term "URL" and reserving the term "URN" explicitly for those URIs using the "urn" scheme name
[RFC2141]. URN "namespaces" [RFC3406] are specific to the "urn" scheme and are not covered explicitly by this specification. This document provides updated guidelines for the definition of new schemes, for consideration by those who are defining, registering, or evaluating those definitions. In addition, this document provides an updated process and mechanism for registering schemes within the IANA URI Schemes registry. There is a single namespace for registered schemes. The intent of the registry is to: o provide a central point of discovery for established URI scheme names and easy location of defining documents for schemes; o discourage multiple separate uses of the same scheme name; o help those proposing new scheme names to discern established trends and conventions and to avoid names that might be confused with existing ones; and o encourage registration by setting a low barrier for registration. RFC3987], extends the URI syntax to allow characters from a much greater repertoire to accommodate resource identifiers from the world's languages. RFC 3987 [RFC3987] also defined a mapping between URIs and IRIs. IRIs use the same scheme names as URIs. Thus, there is no separate independent registry or registration process for IRI schemes: the URI Schemes registry is used for both URIs and IRIs. Those who wish to describe resource identifiers that are useful as IRIs should define the corresponding URI syntax and note that the IRI usage follows the rules and transformations defined in [RFC3987]. RFC2119]. This document distinguishes between a "scheme specification", which is a document defining the syntax and semantics of a scheme, and a "scheme registration request", which is the completed template submitted to IANA. The term "scheme definition" refers generically to the syntax and semantics of a scheme and is typically documented in a scheme specification.
RFC3986] defines the overall syntax for URIs as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] A scheme definition cannot override the overall syntax for URIs. For example, this means that fragment identifiers cannot be reused outside the generic syntax restrictions and that fragment identifiers are not scheme specific. A scheme definition must specify the scheme name and the syntax of the scheme-specific part, which is clarified as follows: URI = scheme ":" scheme-specific-part [ "#" fragment ] scheme-specific-part = hier-part [ "?" query ] W3CWebArch]. Since scheme names share a single, global namespace, it is desirable to avoid contention over use of short, mnemonic scheme names. New schemes ought to have utility to the Internet community beyond that available with already registered schemes. The scheme specification SHOULD discuss the utility of the scheme being registered. RFC3986] defines the generic syntax for all URI schemes, along with the syntax of common URI components that are used by many URI schemes to define hierarchical identifiers. [RFC3987] extended this generic syntax to cover IRIs. All scheme specifications MUST define their own URI <scheme-specific-part> syntax. Care must be taken to ensure
that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar described in [RFC3986]. New schemes SHOULD reuse the common URI components of [RFC3986] for the definition of hierarchical naming schemes. If there is a strong reason for a scheme not to use the hierarchical syntax, then the new scheme definition SHOULD follow the syntax of similar previously registered schemes. Schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character in order to avoid unintended processing, such as resolution of "." and ".." (dot segments). Schemes SHOULD avoid improper use of "//". The use of double slashes in the first part of a URI is not a stylistic indicator that what follows is a URI: double slashes are intended for use ONLY when the syntax of the <scheme-specific-part> contains a hierarchical structure. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority (Section 3.2 of RFC 3986 has more details). Schemes that do not contain a conformant hierarchical structure in their <scheme-specific-part> SHOULD NOT use double slashes following the "<scheme>:" string. New schemes SHOULD clearly define the role of reserved characters (see Section 2.2 of [RFC3986]) in URIs of the scheme being defined. The syntax of the new scheme should be clear about which of the "reserved" set of characters are used as delimiters within the URIs of the new scheme, and when those characters must be escaped, versus when they can be used without escaping.
complete and in sufficient detail so that the mapping in both directions is clear: how to map from a URI into an identifier or set of protocol actions or name in the target namespace, and how legal values in the base namespace, or legal protocol interactions, are represented in a valid URI. See Section 3.6 for guidelines for encoding strings or sequences of bytes within valid character sequences in a URI. If not all legal values or protocol interactions of the base standard can be represented using the scheme, the definition SHOULD be clear about which subset is allowed and why. Section 3.4 of [W3CWebArch]; i.e., performing such an invocation should not incur any additional obligations by doing so.
intended use and include references to documentation that define the applications and/or protocols cited. This does not obviate the need for documentation on applications and/or protocols to discuss URI schemes relevant to them. RFC3987] and Section 2.5 (especially the last paragraph) of [RFC3986] for guidelines. If URIs of a scheme contain any text fields, the scheme definition MUST describe the ways in which characters are encoded and any compatibility issues with IRIs of the scheme. The scheme specification SHOULD be as restrictive as possible regarding what characters are allowed in the URI because some characters can create several different security issues (see, for example, [RFC4690]). Percent-encoded character sequences are automatically included by definition for characters given in IRI productions. This means that if you want to restrict the URI percent-encoded forms in some way, you must restrict the Unicode forms that would lead to them. In most cases, it is advisable to define the actual characters allowed in an IRI production in order to allow the 'pct-encoded' definition from Section 2.1 of [RFC3986] at the same places and to add prose that limits percent escapes to those that can be created by converting valid UTF-8 character sequences to percent-encoding. RFC5226]. In particular, Section 7 of RFC 3986 [RFC3986] describes general security considerations for URIs while [RFC3987] gives those for IRIs. The definition of an individual scheme should note which of these apply to the specified scheme, in addition to any more scheme- specific concerns. For example, if the scheme-specific part is privacy sensitive, then that should be documented.
Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this syntax remains the same for IRIs. New scheme registrations MUST follow this syntax, which only allows a limited repertoire of characters (taken from US-ASCII). Although the syntax for the scheme name in URIs is case insensitive, the scheme name itself MUST be registered using lowercase letters. Scheme names SHOULD be short but also sufficiently descriptive and distinguished to avoid problems. Schemes SHOULD NOT use names or other symbols that might cause problems with rights to use the name in IETF specifications and Internet protocols. For example, be careful with trademark and service mark names. (See Section 3.4 of [RFC5378]). Schemes SHOULD NOT use names that are either very general purpose or associated in the community with some other application or protocol. Schemes also SHOULD NOT use names that are overly general or grandiose in scope (e.g., that allude to their "universal" or "standard" nature). A scheme name is not a "protocol." However, like a service name as defined in Section 5 of [RFC6335], it often identifies a particular protocol or application. If a scheme name has a one-to-one correspondence with a service name, then the names SHOULD be the same. Some organizations desire their own namespace for URI scheme names for private use (see Section 6). In doing so, it is important to prevent collisions and to make it possible to identify the owner of a private-use scheme. To accomplish these two goals, such organizations SHOULD use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com.example.mything might be used by the organization that owns the example.com domain name. Care must be taken, however, if the organization later loses the domain name embedded in their scheme names since domain name registrations are not permanent. To associate the private-use scheme name with the original organization, the private-use scheme can be registered using the registration procedure in Section 7. Furthermore, to prevent collisions with private-use scheme names, new scheme names registered MUST NOT contain a "." unless actually constructed from a reversed domain name.
Section 3.8. o There must not already be an entry with the same scheme name. In the unfortunate case that there are multiple, different uses of the same scheme name, the Designated Expert can approve a request to modify an existing entry to note the separate use. o Contact information identifying the person supplying the registration must be included. Previously unregistered schemes discovered in use can be registered by third parties (even if not on behalf of those who created the scheme). In this case, both the registering party and the scheme creator SHOULD be identified. o If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it SHOULD be given. o The scheme definition SHOULD include clear security considerations (Section 3.7) or explain why a full security analysis is not available (e.g., in a third-party scheme registration). o If the scheme definition does not meet the guidelines laid out in Section 3, the differences and reasons SHOULD be noted.
Section 3.8. RFC5226]) for 'provisional' registration was formerly Expert Review; this document changes the policy to First Come First Served. The policy for 'permanent' and 'historical' registration continues to be Expert Review. The registration procedure is intended to be very lightweight for noncontentious registrations. For the most part, we expect the good sense of submitters and reviewers, guided by these procedures, to achieve an acceptable and useful consensus for the community. In exceptional cases, where the negotiating parties cannot form a consensus, the final arbiter of any contested registration shall be the IESG. If standardization is anticipated, the working group or individuals concerned are advised to submit an early 'permanent' registration request rather than waiting until the standardization process has run its course. IANA will pass this to the Designated Expert who may recommend 'provisional' registration until the specification is approved as a standard. This will provide an opportunity for feedback while specification development and review is still active, and while the submitter(s) are still in a position to respond to any
issues that might be raised. If and when the specification is approved as a standard, the submitters should submit a request to change the registration status to 'permanent'. The role of the Designated Expert in the procedure for 'permanent' registrations described here is to ensure that the normal open review process has been properly followed and to raise possible concerns about wider implications of proposals for the use and deployment of URIs. Nothing in the procedure empowers the Designated Expert to override properly arrived-at IETF or working group consensus. Section 7.4. The scheme registration request can be contained in an Internet-Draft, submitted alone, or as part of some other permanently available, stable, protocol specification. The scheme registration request can also be submitted in some other form (as part of another document or as a stand-alone document), but the scheme registration request will be treated as an "IETF Contribution" under the guidelines of [RFC5378]. 3. If the registration request is for a 'permanent' registration (or, optionally, for any other registration if desired): 1. Review the requirements in Section 3. 2. Send a copy of the scheme registration request or a pointer to the document containing the request (with specific reference to the section that requests the scheme registration) to the mailing list firstname.lastname@example.org, requesting review. In addition, request review on other relevant mailing lists as appropriate. For example, general discussion of URI syntactical issues can be discussed on email@example.com; schemes for a network protocol can be discussed on a mailing list for that protocol. Allow a reasonable time for discussion and comments. Four weeks is reasonable for a 'permanent' registration request.
3. Respond to review comments and make revisions to the proposed registration as needed to bring it into line with the guidelines given in this document. 4. Submit the (possibly updated) scheme registration request (or pointer to document containing it) to IANA at firstname.lastname@example.org. Upon receipt of a scheme registration request, the following steps MUST be followed: 1. IANA checks the submission for completeness; if required sections of the scheme registration request are missing or any citations are not correct, IANA will reject the registration request. A registrant can resubmit a corrected request if desired. 2. If the request is for 'provisional' registration and no entry already exists in the current registry for the same name, IANA adds the registration to the registry under the First Come First Served policy. 3. Otherwise, IANA enters the registration request in the IANA registry with the status marked as "Pending Review", and the remainder of this section applies. 4. IANA requests Expert Review of the registration request against the corresponding guidelines from this document. 5. The Designated Expert will evaluate the request against the criteria of the requested status. 6. In the case of a 'permanent' registration request, the Designated Expert may: * Accept the specification of the scheme for 'permanent' registration. * Suggest 'provisional' registration instead. * Request IETF review and IESG approval; in the meanwhile, suggest 'provisional' registration. * Request additional review or discussion as necessary. 7. If an entry already exists for the same name, the Designated Expert will determine whether the request should be rejected or whether the existing entry should be modified to note the separate use. This conflict process applies regardless of the requested status or the status of the existing entry.
8. Once the Designated Expert approves registration for a given status, IANA updates the registration to indicate the approved status. If the Designated Expert instead rejects the registration, the "Pending Review" request is removed from the registry. Either based on an explicit request or independently initiated, the Designated Expert or the IESG can request the upgrade of a 'provisional' registration to a 'permanent' one. In such cases, IANA will update the status of the corresponding entry. Typically, this would only occur if the use is considered a standard (not necessarily an IETF standard). Section 3.8 for guidelines. Status: This reflects the status requested and must be one of 'Permanent', 'Provisional', or 'Historical'. Applications/protocols that use this scheme name: See Section 3.5.
Contact: Person (including contact information) to contact for further information. Change controller: Organization or person (often the author), including contact information, authorized to change this. References: Include full citations for all referenced documents. Scheme registration requests for 'provisional' registration can be included in an Internet-Draft; when the documents expire or are approved for publication as an RFC, the registration will be updated. A scheme specification is only required for 'permanent' registration. The previous version of this specification required the following additional fields in a scheme registration request. These fields are no longer part of the template. The answers instead belong in the scheme specification. Scheme syntax: See Section 3.2 for guidelines. Scheme semantics: See Section 3.3 and Section 3.4 for guidelines. Encoding considerations: See Section 3.3 and Section 3.6 for guidelines. Interoperability considerations: See Section 3.9 for guidelines. Security considerations: See Section 3.7 for guidelines.
The "example" scheme is specified as follows: Scheme syntax: The entire range of allowable syntax specified in [RFC3986] is allowed for "example" URIs. Similarly, the entire range of allowable syntax specified in [RFC3987] is allowed for "example" IRIs. For example, <example:foo>, <example:/foo>, and <example://foo> are all valid. Scheme semantics: URIs in the "example" scheme are to be used for documentation purposes only. The use of "example" URIs must not be used as locators, identify any resources, or specify any particular set of operations. Encoding considerations: See Section 2.5 of [RFC3986] for guidelines. Interoperability considerations: None. Security considerations: None. Section 8 of this document (RFC 7595). RFC5226] with an initial (optional) mailing list review. The updated template has an additional field for the status of the scheme, and the procedures for entering new name schemes have been augmented. Section 7 establishes the process for new scheme registration.
IANA has done the following: o Updated the URI Schemes registry to point to this document. o Combined the "Permanent URI Schemes", "Provisional URI Schemes", and "Historical URI Schemes" subregistries into a single common registry with an additional "Status" column containing the status ('Permanent', 'Provisional', 'Historical', or 'Pending Review'), and an additional "Notes" column that is normally empty but may contain notes approved by the Designated Expert. o Added the "example" URI scheme to the registry (see the template in Section 8.1 for registration). Section 3.7. However, information concerning possible security vulnerabilities of a protocol might change over time. Consequently, claims as to the security properties of a registered scheme might change as well. As new vulnerabilities are discovered, information about such vulnerabilities might need to be attached to existing documentation, so that users are not misled as to the true security properties of a registered scheme. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <http://www.rfc-editor.org/info/rfc5378>. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>. [RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, DOI 10.17487/RFC2717, November 1999, <http://www.rfc-editor.org/info/rfc2717>. [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, DOI 10.17487/RFC2718, November 1999, <http://www.rfc-editor.org/info/rfc2718>. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, October 2002, <http://www.rfc-editor.org/info/rfc3406>. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, DOI 10.17487/RFC4395, February 2006, <http://www.rfc-editor.org/info/rfc4395>. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, <http://www.rfc-editor.org/info/rfc4690>.
[W3CWebArch] W3C Technical Architecture Group, "Architecture of the World Wide Web, Volume One", W3C Recommendation, December 2004, <http://www.w3.org/TR/webarch/>. RFC2717], [RFC2718] and [RFC3864]. Some of the ideas about use of URIs were taken from the "Architecture of the World Wide Web" [W3CWebArch].