diff options
Diffstat (limited to 'doc/rfc/rfc7595.txt')
| -rw-r--r-- | doc/rfc/rfc7595.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7595.txt b/doc/rfc/rfc7595.txt new file mode 100644 index 0000000..f6f4a94 --- /dev/null +++ b/doc/rfc/rfc7595.txt @@ -0,0 +1,1067 @@ + + + + + + +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 + +Abstract + + This 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. + + + + + + +Thaler, et al. Best Current Practice [Page 1] + +RFC 7595 URI Scheme Guidelines June 2015 + + +Table of Contents + + 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 + +1. Introduction + + The Uniform Resource Identifier (URI) protocol element and generic + syntax is defined by [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 + + + +Thaler, et al. Best Current Practice [Page 2] + +RFC 7595 URI Scheme Guidelines June 2015 + + + [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. + +1.1. URIs and IRIs + + As originally defined, URIs only allowed a limited repertoire of + characters chosen from US-ASCII. An Internationalized Resource + Identifier (IRI), as defined by [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]. + +2. Terminology + + 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 [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. + + + +Thaler, et al. Best Current Practice [Page 3] + +RFC 7595 URI Scheme Guidelines June 2015 + + +3. Requirements for Permanent Scheme Definitions + + This section gives considerations for new schemes. Meeting these + guidelines is REQUIRED for 'permanent' scheme registration. + 'Permanent' status is appropriate for, but not limited to, use in + standards. For URI schemes defined or normatively referenced by IETF + Standards Track documents, 'permanent' registration status is + REQUIRED. + + [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 ] + +3.1. Demonstrable, New, Long-Lived Utility + + In general, the use and deployment of new schemes in the Internet + infrastructure can be costly; some parts of URI processing are often + scheme dependent. Introducing a new scheme might require additional + software not only for client software and user agents but also in + additional parts of the network infrastructure (gateways, proxies, + caches) [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. + +3.2. Syntactic Compatibility + + [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 + + + + + + +Thaler, et al. Best Current Practice [Page 4] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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. + +3.3. Well Defined + + While URIs might or might not be defined as locators in practice, a + scheme definition itself MUST be clear as to how it is expected to + function. Schemes that are not intended to be used as locators + SHOULD describe how the resource identified can be determined or + accessed by software that obtains a URI of that scheme. + + For schemes that function as locators, it is important that the + mechanism of resource location be clearly defined. This might mean + different things depending on the nature of the scheme. + + In many cases, new schemes are defined as ways to translate between + other namespaces or protocols and the general framework of URIs. For + example, the "ftp" scheme translates into the FTP protocol while the + "mid" scheme translates into a Message-ID identifier of an email + message. For such schemes, the description of the mapping SHOULD be + + + +Thaler, et al. Best Current Practice [Page 5] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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. + +3.4. Definition of Operations + + As part of the definition of how a URI identifies a resource, a + scheme definition SHOULD define the applicable set of operations that + can be performed on a resource using the URI as its identifier. A + model for this is HTTP methods; an HTTP resource can be operated on + by GET, POST, PUT, and a number of other methods available through + the HTTP protocol. The scheme definition SHOULD describe all well- + defined operations on the resource identifier and what they are + supposed to do. + + Some schemes don't fit into the "information access" paradigm of + URIs. For example, "telnet" provides location information for + initiating a bidirectional data stream to a remote host; the only + operation defined is to initiate the connection. In any case, the + operations appropriate for a scheme 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 scheme is described. + + Scheme definitions SHOULD define a "default" operation for when a URI + is invoked (or "dereferenced") by an application. For example, a + common "default" operation today is to launch an application + associated with the scheme name and let it use the other URI + components as inputs to do something. The default invocation, or + dereferencing, of a URI SHOULD be "safe" in the sense described by + Section 3.4 of [W3CWebArch]; i.e., performing such an invocation + should not incur any additional obligations by doing so. + +3.5. Context of Use + + In general, URIs are used within a broad range of protocols and + applications. For example, URIs are commonly used within hypertext + documents as references to other resources. In some cases, a scheme + is intended for use within a different, specific set of protocols or + applications. If so, the scheme definition SHOULD describe the + + + +Thaler, et al. Best Current Practice [Page 6] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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. + +3.6. Internationalization and Character Encoding + + When describing schemes in which (some of) the elements of the URI + are actually representations of human-readable text, care should be + taken not to introduce unnecessary variety in the ways in which + characters are encoded into octets and then into URI characters; see + [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. + +3.7. Clear Security and Privacy Considerations + + Definitions of schemes MUST be accompanied by a clear analysis of the + security and privacy implications for systems that use the scheme; + this follows the practice of Security Consideration sections within + IANA registrations [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. + + + + + + +Thaler, et al. Best Current Practice [Page 7] + +RFC 7595 URI Scheme Guidelines June 2015 + + +3.8. Scheme Name Considerations + + 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. + + + + + +Thaler, et al. Best Current Practice [Page 8] + +RFC 7595 URI Scheme Guidelines June 2015 + + +3.9. Interoperability Considerations + + If the person or group registering the scheme is aware of any details + regarding the scheme that might impact interoperability, identify + them, for example, proprietary or uncommon encoding methods, or + incompatibility with types or versions of any underlying protocol. + +4. Guidelines for Provisional URI Scheme Registration + + 'Provisional' registration can be used for schemes that are not part + of any standard but that are intended for use (or observed to be in + use) that is not limited to a private environment within a single + organization. 'Provisional' registration can also be used as an + intermediate step on the way to 'permanent' registration, e.g., + before the scheme specification is finalized as a standard. + + For a 'provisional' registration, the following apply: + + o The scheme name must meet the syntactic requirements of + 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. + + + + + + + + + +Thaler, et al. Best Current Practice [Page 9] + +RFC 7595 URI Scheme Guidelines June 2015 + + +5. Guidelines for Historical URI Scheme Registration + + In some circumstances, it is appropriate to note a scheme that was + once in use or registered but for whatever reason is no longer in + common use or whose use is not recommended. In this case, it is + possible for an individual to request that the URI scheme be + registered (newly, or as an update to an existing registration) as + 'historical'. Any scheme that is no longer in common use MAY be + designated as 'historical'; the registration SHOULD contain some + indication as to where the scheme was previously defined or + documented. + +6. Guidelines for Private URI Scheme Use + + Unregistered schemes can cause problems if use is not limited to a + private environment within a single organization since the use could + leak out beyond the closed environment. Even within a closed + environment, other colliding uses of the same scheme name could + occur. As such, a unique namespace MUST be used and 'provisional' + registration is strongly encouraged (unless the scheme name is + constructed from a domain name), as discussed in Section 3.8. + +7. URI Scheme Registration Procedure + +7.1. General + + The IANA policy (using terms defined in [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 + + + +Thaler, et al. Best Current Practice [Page 10] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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. + +7.2. Registration Procedures + + Someone wishing to register a new scheme MUST: + + 1. Check the IANA "Uniform Resource Identifier (URI) Schemes" + registry to see whether there is already an entry for the desired + name. If there is already an entry under the name, choose a + different scheme name or update the existing scheme + specification. + + 2. Prepare a scheme registration request using the template + specified in 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 uri-review@ietf.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 + uri@w3.org; 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. + + + + + +Thaler, et al. Best Current Practice [Page 11] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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 iana@iana.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. + + + +Thaler, et al. Best Current Practice [Page 12] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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). + +7.3. Change Control + + Registrations can be updated in the registry by the same mechanism as + required for an initial registration. In cases where the original + definition of the scheme is contained in an IESG-approved document, + update of the specification also requires IESG approval. + + 'Provisional' registrations can be updated by the original registrant + or anyone designated by the original registrant. In addition, the + IESG can reassign responsibility for a 'provisional' registration + scheme or can request specific changes to a scheme registration. + This will enable changes to be made to schemes where the original + registrant is out of contact or unwilling or unable to make changes. + + Transition from 'provisional' to 'permanent' status can be requested + and approved in the same manner as a new 'permanent' registration. + Transition from 'permanent' to 'historical' status requires IESG + approval. Transition from 'provisional' to 'historical' can be + requested by anyone authorized to update the 'provisional' + registration. + +7.4. URI Scheme Registration Template + + This template describes the fields that MUST be supplied in a scheme + registration request suitable for adding to the registry: + + Scheme name: + See 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. + + + +Thaler, et al. Best Current Practice [Page 13] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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. + +8. The "example" URI Scheme + + There is a need for a scheme name that can be used for examples in + documentation without fear of conflicts with current or future actual + schemes. The scheme "example" is hereby registered as a 'permanent' + scheme for that purpose. + + + + + + + + + +Thaler, et al. Best Current Practice [Page 14] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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. + +8.1. "example" URI Scheme Registration Request + + Scheme name: example + + Status: permanent + + Applications/protocols that use this scheme name: An "example" URI + is to be used for documentation purposes only. It MUST NOT be used + for any protocol. + + Contact: N/A + + Change controller: IETF + + References: Section 8 of this document (RFC 7595). + +9. IANA Considerations + + Previously, the former "URL Scheme" registry was replaced by the + "Uniform Resource Identifier (URI) Schemes" registry. The process + was based on "Expert Review" [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. + + + + +Thaler, et al. Best Current Practice [Page 15] + +RFC 7595 URI Scheme Guidelines June 2015 + + + 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). + +10. Security Considerations + + All registered values are expected to contain clear security + considerations as discussed in 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. + +11. References + +11.1. Normative References + + [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>. + + + + + +Thaler, et al. Best Current Practice [Page 16] + +RFC 7595 URI Scheme Guidelines June 2015 + + + [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>. + +11.2. Informative References + + [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>. + + + + + +Thaler, et al. Best Current Practice [Page 17] + +RFC 7595 URI Scheme Guidelines June 2015 + + + [W3CWebArch] + W3C Technical Architecture Group, "Architecture of the + World Wide Web, Volume One", W3C Recommendation, December + 2004, <http://www.w3.org/TR/webarch/>. + +Acknowledgements + + Thanks to Mark Nottingham and Graham Klyne and other members of the + apps-discuss@ietf.org mailing list for their comments on this + document. + + Many thanks to Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy + Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, and + other members of the uri@w3.org mailing list for their comments on + earlier draft versions of this document. + + Parts of this document are based on [RFC2717], [RFC2718] and + [RFC3864]. Some of the ideas about use of URIs were taken from the + "Architecture of the World Wide Web" [W3CWebArch]. + +Contributor + + Larry Masinter was an author of the document from which this work is + derived, and he continued as author of this version through the + working group and IESG evaluation period. His many contributions are + gratefully acknowledged. + + + + + + + + + + + + + + + + + + + + + + + + + +Thaler, et al. Best Current Practice [Page 18] + +RFC 7595 URI Scheme Guidelines June 2015 + + +Authors' Addresses + + Dave Thaler (editor) + Microsoft + One Microsoft Way + Redmond, WA 98052 + United States + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + + Tony Hansen + AT&T Laboratories + 200 Laurel Ave. + Middletown, NJ 07748 + United States + + EMail: tony+urireg@maillennium.att.com + + + Ted Hardie + Google + + Phone: +1 408 628 5864 + EMail: ted.ietf@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + +Thaler, et al. Best Current Practice [Page 19] + |