Network Working Group D. Thaler, Ed. Internet-Draft Microsoft Obsoletes: 4395 (if approved) T. Hansen Intended status: Best Current Practice AT&T Laboratories Expires: April 23, 2015 T. Hardie Google L. Masinter Adobe October 20, 2014 Guidelines and Registration Procedures for URI Schemes draft-ietf-appsawg-uri-scheme-reg-04 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 23, 2015. Copyright Notice Copyright (c) 2014 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 Thaler, et al. Expires April 23, 2015 [Page 1] Internet-Draft URI Scheme Guidelines October 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 Considerations . . . . . . . . . . . . . . 7 3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 7 4. Guidelines for Provisional URI Scheme Registration . . . . . 8 5. Guidelines for Historical URI Scheme Registration . . . . . . 9 6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 9 7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 10 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Registration Procedures . . . . . . . . . . . . . . . . . 10 7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 12 7.4. URI Scheme Registration Template . . . . . . . . . . . . 12 8. The "example" Scheme . . . . . . . . . . . . . . . . . . . . 13 8.1. "Example" Scheme Registration Request . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 Thaler, et al. Expires April 23, 2015 [Page 2] Internet-Draft URI Scheme Guidelines October 2014 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, as well as a 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 standard 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 avoid names that might be confused with existing ones; o encourage registration by setting a low barrier for registration. As originally defined, URIs only allowed a limited repertoire of characters chosen from US-ASCII. An Interationalized Resource Identifier (IRI), as defined by [RFC3987], extends the URI syntax to allow characters from a much greater repertoire, to accomodate resource identifiers from the world's languages. RFC 3987 [RFC3987] also defined a mapping between URIs and IRIs. A URI scheme name is the same as the corresponding IRI scheme name. 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]. [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 re-used outside the generic syntax restrictions. A scheme definition must specify the scheme name and the syntax of the scheme-specific part, which is clarified as follows: Thaler, et al. Expires April 23, 2015 [Page 3] Internet-Draft URI Scheme Guidelines October 2014 URI = scheme ":" scheme-specific-part [ "#" fragment ] scheme-specific-part = hier-part [ "?" query ] 2. Terminology Within this document, the key words MUST, MAY, SHOULD, REQUIRED, RECOMMENDED, and so forth are used within the general meanings established in [RFC2119], within the context that they are requirements on future registrations. This document distinguishes between a "scheme specification", being a document defining the syntax and semantics of a scheme, vs. a "scheme registration request" being the request submitted to IANA. The term "scheme definition" refers generically to the syntax and semantics of a scheme, typically documented in a scheme specification. 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 IETF Standards-Track documents, Permanent registration status is REQUIRED. 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 syntax. Care must be taken to ensure Thaler, et al. Expires April 23, 2015 [Page 4] Internet-Draft URI Scheme Guidelines October 2014 that all strings matching their scheme-specific syntax will also match the 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 previously registered schemes. Schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." 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 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 SHOULD NOT use double slashes following the ":" string. New schemes SHOULD clearly define the role of [RFC3986] reserved characters 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 Thaler, et al. Expires April 23, 2015 [Page 5] Internet-Draft URI Scheme Guidelines October 2014 message. For such schemes, the description of the mapping MUST be 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, might be represented in a valid URI. See Section 3.6 for guidelines for encoding binary or character strings 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 are 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 bi-directional 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. Most commonly, URIs are used as references to resources within directories or hypertext documents, as hyperlinks to other resources. In some cases, a scheme is intended for use within Thaler, et al. Expires April 23, 2015 [Page 6] Internet-Draft URI Scheme Guidelines October 2014 a different, specific set of protocols or applications. If so, the scheme definition SHOULD describe the intended use and include references to documentation that define the applications and/or protocols cited. 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 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 considerations (see, for example [RFC4690]). All percent-encoded variants are automatically included by definition for any character given in an IRI production. 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. 3.7. Clear Security Considerations Definitions of schemes MUST be accompanied by a clear analysis of the security 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. 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 registered schemes 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 names itself MUST be registered using lowercase letters. Thaler, et al. Expires April 23, 2015 [Page 7] Internet-Draft URI Scheme Guidelines October 2014 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 7.4 of [RFC3978].) 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" although, 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.info 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. The URI scheme name registration procedure can be used in such an event. 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. 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 are REQUIRED: o The scheme name meets the syntactic requirements of Section 3.8. Thaler, et al. Expires April 23, 2015 [Page 8] Internet-Draft URI Scheme Guidelines October 2014 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 is 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 a 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. 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 the 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 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 (see Section 3.8) MUST be used, and it is strongly encouraged to do a Provisional registration unless the scheme name is constructed from a domain name. Thaler, et al. Expires April 23, 2015 [Page 9] Internet-Draft URI Scheme Guidelines October 2014 7. URI Scheme Registration Procedure 7.1. General The IANA policy (using terms defined in [RFC5226]) for Provisional registration was formerly Expert Review and is now changed to simply use a First Come First Served policy. The policy for Permanent and Historic registration continues to be Expert Review. The registration procedure is intended to be very lightweight for non-contentious 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. 7.2. Registration Procedures Someone wishing to register a new scheme MUST: 1. Check the IANA 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 completed template can also be submitted in some other form (as part of another document or as a stand-alone document), but the completed template will be treated as an "IETF Contribution" under the guidelines of [RFC3978]. 3. If the registration request is for a Permanent registration: 1. Review the requirements in Section 3. 2. Send a copy of the completed template or a pointer to the containing document (with specific reference to the section with the completed template) 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 could be discussed on uri@w3.org; schemes for a network protocol Thaler, et al. Expires April 23, 2015 [Page 10] Internet-Draft URI Scheme Guidelines October 2014 could 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) registration template (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 sections of the template are missing or any citations are not correct, IANA will reject the registration request. 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 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 Thaler, et al. Expires April 23, 2015 [Page 11] Internet-Draft URI Scheme Guidelines October 2014 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 Expert Review approves registration for a given status, IANA adds the registration to the registry. Either based on an explicit request or independently initiated, the Designated Expert or 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: 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: Thaler, et al. Expires April 23, 2015 [Page 12] Internet-Draft URI Scheme Guidelines October 2014 See Section 3.5. Contact: Person (including contact information) to contact for further information. Author/Change controller: Person (including contact information) authorized to change this. References: Include full citations for all referenced documents. Registration templates 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 following fields are no longer required in a scheme registration request. 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: If the person or group registering the scheme is aware of any details regarding the scheme that might impact interoperability, identify them here. For example: proprietary or uncommon encoding methods; inability to support multibyte character sets; incompatibility with types or versions of any underlying protocol. Security considerations: See Section 3.7 for guidelines. 8. The "example" 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. The "example" scheme is specified as follows: Thaler, et al. Expires April 23, 2015 [Page 13] Internet-Draft URI Scheme Guidelines October 2014 Scheme syntax: The entire range of allowable syntax specified in [RFC3986] is allowed for "example" URIs. 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" 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 Author/Change controller: IETF References: Section 8 of this RFC XXXX. RFC Editor Note: Replace XXXX with this RFC's reference. 9. IANA Considerations Previously, the former "URL Scheme" registry was replaced by the "Uniform Resource Identifier (URI) Schemes" registry. The process was based on [RFC5226] "Expert Review" 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 is requested to do the following: o Update the URI Schemes registry to point to this document. Thaler, et al. Expires April 23, 2015 [Page 14] Internet-Draft URI Scheme Guidelines October 2014 o Combine the "Permanent URI Schemes", "Provisional URI Schemes", and "Historical URI Schemes" sub-registries into a single common registry with an additional "Status" column containing the status (Permanent, Provisional, Historical, or Pending Review), and an additional "Notes" column which is normally empty, but may contain notes approved by the Designated Expert. o Add 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 accurate security consideration sections; 'permanent' registered scheme names are expected to contain complete definitions. 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. 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 versions. 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]. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. Thaler, et al. Expires April 23, 2015 [Page 15] Internet-Draft URI Scheme Guidelines October 2014 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, March 2005. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [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, August 2011. 12.2. Informative References [RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999. [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006. [W3CWebArch] W3C Technical Architecture Group, "Architecture of the World Wide Web, Volume One", December 2004, . Thaler, et al. Expires April 23, 2015 [Page 16] Internet-Draft URI Scheme Guidelines October 2014 Appendix A. Changes Since RFC 4395 1. Combined the Historical, Permanent, and Provisional URI Schemes registries into one registry with a status column. This is done to make it easier to prevent duplicates and see existing conventions. 2. Added a Notes column in the registry for notes approved by the Designated Expert. 3. Moved the following fields out of the scheme registration request template and into the requirements for a scheme specification: Scheme syntax, Scheme semantics, Encoding considerations, Interoperability considerations, and Security considerations. 4. Simplified the process for Provisional registration significantly: changed from Expert Review to First Come First Served, and clarified that mailing list review is not required. 5. Updated process for handling of scheme name conflicts, so that adding a note can be approved by the Designated Expert rather than the IESG. 6. Clarified that a "URI scheme name" and an "IRI scheme name" are the same thing and thus use the same IANA registry. 7. Clarified that a registration request falls under the "IETF Contribution" rules, but the scheme's specification need not. 8. Added the "example:" URI scheme. 9. Added text about when to use Provisional registration. 10. Updated convention for Private use schemes to use "." (instead of "-") between domain name labels, to reduce chance of collision, and recommended use of a reverse domain name prefix to allow identifying the owning organization. 11. Recommended that scheme definitions define a "default" operation for when a URI is invoked. 12. Recommended that a scheme name be the same as the service name, when there exists a 1:1 correspondence. 13. Elaborated on when a Provisional request should be upgraded to Permanent. Thaler, et al. Expires April 23, 2015 [Page 17] Internet-Draft URI Scheme Guidelines October 2014 Authors' Addresses Dave Thaler (editor) Microsoft One Microsoft Way Redmond, WA 98052 US Phone: +1 425 703 8835 Email: dthaler@microsoft.com Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA Email: tony+urireg@maillennium.att.com Ted Hardie Google Phone: +1 408 628 5864 Email: ted.ietf@gmail.com Larry Masinter Adobe 345 Park Ave. San Jose, CA 95110 US Phone: +1 408 536 3024 Email: masinter@adobe.com URI: http://larry.masinter.net Thaler, et al. Expires April 23, 2015 [Page 18]