--- 1/draft-ietf-appsawg-about-uri-scheme-03.txt 2012-03-26 10:14:06.518756116 +0200 +++ 2/draft-ietf-appsawg-about-uri-scheme-04.txt 2012-03-26 10:14:06.538786387 +0200 @@ -1,23 +1,23 @@ Applications Area WG (APPSAWG) L. Hunt, Ed. Internet-Draft Opera Software, ASA. Intended Status: Standards Track M. Yevstifeyev, Ed. -Expires: September 5, 2012 March 4, 2012 +Expires: September 22, 2012 March 21, 2012 The "about" URI Scheme - draft-ietf-appsawg-about-uri-scheme-03 + draft-ietf-appsawg-about-uri-scheme-04 Abstract - This document specifies the "about" URI scheme, that is widely used - by Web browsers and some other applications to designate access to + This document specifies the "about" URI scheme, which is widely used + by web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -46,60 +46,53 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 2. URI Scheme Specification . . . . . . . . . . . . . . . . . . . 3 2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 3 2.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 3 2.2.1. Special-Purpose "about" URIs . . . . . . . . . . . . . 3 2.3. Encoding Considerations . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4.1. URI Scheme Registration . . . . . . . . . . . . . . . . . . 4 4.2. A Registry for Registered Tokens . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 + 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document specifies the "about" Uniform Resource Identifier (URI) scheme, that is currently widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, so called "Easter eggs" (i.e. hidden feature or joke in an application), and so on. - The concept of "about" URIs has been formed at the times when the - applications did not have the "friendly" user interface, in order to - provide an access to the aforementioned resources via typing the URIs - in the address bar. Even though the user interface of current - Internet-targeted software effectively rescinds the issue, and - "about" URIs can be thought to be a rudimentary phenomenon, they are - still supported by a variety of Web browsers and are not going to - cease to exist. + The concept of "about" URIs formed when applications did not have a + "friendly" user interface, to enable access to the aforementioned + resources by typing URIs into an address bar or similar feature. + They have however become commonplace in modern user applications. - As use of "about" URIs has been quiet long-lasting, and the URIs have - been used without any proper registration and absent any proper - specification, the necessity for the the latter two actions arises. - The purpose of this document is to provide a stable specification for - "about" URI scheme and correspondingly register it in the IANA - registry. Along, several provisions for handling the "about" URIs - are set. + Given their current ubiquity, their absence from the URI scheme + registry and lack of a defining document is conspicuous. Therefore, + this document provides a stable specification for the "about" URI + scheme and registers it with IANA. Please consult RFC 3986 [RFC3986] for definition of generic URIs syntax and RFC 4395 [RFC4395] for description of registration process for new URI schemes. 1.1. 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 RFC 2119 [RFC2119]. @@ -115,77 +108,75 @@ about-token = *pchar about-query = "?" query pchar = query = In terms of RFC 3986, part corresponds to , and to the query component of URI. 2.2. URI Scheme Semantics - Generally speaking, the resource a particular "about" URI resolves to - is denoted by part of the URI, and - specifies additional information concerning its handling and/or the - information that should be returned in the resource a URI is resolved - to. + Generally speaking, the resource to which a particular "about" URI + resolves is denoted by part of the URI, and specifies additional information concerning its handling + and/or the information that should be returned in the resource to + which the URI resolves. - However, it is impossible to specify binding between all the possible - tokens and the semantics of "about" URIs that would contain such - tokens, which this document does not attempt to do. Therefore, any - application resolving an "about" URI MAY choose the resource it is - resolved to at its own discretion, with the exception of those - defined below as 'special-purpose "about" URIs'. They MAY use - internal redirection to accomplish this (for instance, Opera - redirects all "about" URIs except "about:blank" to its internal - "opera" URIs). + However, it is impossible to specify a binding between all the + possible tokens and the semantics of "about" URIs that would contain + such tokens. Therefore, the resource referenced by the URI is + application-specific, except for those listed below as 'special- + purpose "about" URIs'. Applications MAY use internal redirection to + accomplish this (for instance, the Opera web browser redirects all + "about" URIs except "about:blank" to its internal "opera" URIs). 2.2.1. Special-Purpose "about" URIs - A small, though expandable, range of s are reserved for + A small, though expandable, range of s is reserved for special purposes ("special-purpose tokens"). A special-purpose URI is an "about" URI that has a special-purpose token as its part. Such URIs MUST be handled in strict accordance with the rules defined in the special-purpose token registry (see Section 4.2). The registered entry MAY also define additional provisions for handling of the part. If no such provisions are defined, the query part has no meaning, and MUST be ignored. This document defines one special-purpose token: "blank". The URI "about:blank" MUST resolve to a blank page, as seen by the end user. There is no additional handling of the query component in "about:blank" URIs. - Additional special-purpose tokens can be defined by registering an + Additional special-purpose tokens can be defined by by updating the registry created in Section 4.2. Special-purpose "about" URIs are intended to be uncommon, and new ones should be defined only when there is a need to strongly connect a particular with a particular function in all applications. 2.3. Encoding Considerations "about" URIs are subject to encoding rules defined in RFC 3986 [RFC3986]. "about" IRIs [RFC3987] are not permitted. 3. Security Considerations Generic security considerations for URIs are discussed in Section 7 - of RFC 3986 [RFC3986]. However, many of those provisions hardly - apply to "about" URI scheme, as they are mainly scoped to schemes - used in the Internet, not internally. + of RFC 3986 [RFC3986]. However, few of those provisions apply to + "about" URI scheme, as they are mainly scoped to schemes used in the + Internet, not internally. - "about" URIs may sometimes refer to a sensitive information, such as - user passwords stored in a cache, or parameter that, if changed, may - affect user's data. The application should therefore ensure that - user's data is in the safety, and no threats are imposed by "about" - URIs. + "about" URIs can sometimes refer to a sensitive information, such as + user passwords stored in a cache, or parameters that, if changed, + could affect user's data. The application therefore needs to ensure + that the user's data is secured, and no threats are imposed by + "about" URIs. 4. IANA Considerations 4.1. URI Scheme Registration IANA is asked to register the "about" URI scheme in the "URI Schemes" registry defined in Section 5.4 of RFC 4395 [RFC4395]: URI scheme name: about @@ -210,60 +202,57 @@ References: see Section 5 of RFC xxxx [RFC Editor: Please replace xxxx with assigned RFC number] 4.2. A Registry for Registered Tokens IANA is asked to set up a new registry entitled "'about' URI Special Purpose Tokens" following the guidelines below. The registry entries consist of 3 fields: Special-Purpose Token, - Description and Reference. The Special-Purpose Token field MUST + Description and Reference. The Special-Purpose Token field has to conform to production defined in Section 2.1. The initial registry consists of one entry: +------------------+------------------------------------+-----------+ | Special-Purpose | Description | Reference | | Token | | | +------------------+------------------------------------+-----------+ | blank | Used in "about" URIs to refer to | RFC xxxx | | | blank page. | | +------------------+------------------------------------+-----------+ The registration procedures for this registry are "First Come First Served", described in RFC 5226 [RFC5226], with supporting documentation meeting the requirements below. The registrant of the - token MUST provide the following registration template, which will be - made available on IANA web site: + token ought to provide the following registration template, which + will be made available on IANA web site: o Registered Token: The desired special-purpose token to be used in "about" URIs. o Intended usage: A short description of how "about" URIs with the - registered token must be handled; especially, what they must be - resolved to, if resolvable. + registered token must be handled; especially, to what resource they + are to resolve. - o Handling query component: It should be mentioned whether there are - some provisions on handling query components in the "about" URIs - with the registered token. + o Handling query component: Describe any requirements for handling + query components in "about" URIs that contain the registered token. - o Contact/Change controller: An individual or an organization which + o Contact/Change controller: An individual or an organization that (1) should be contacted for more details, and (2) is authorized to change the registration. - o Specification. This provides documentation at a level that could + o Specification. A permanent reference to a specification that can be used to create a compliant, interoperable implementation of the - registered "about" URI. The reference to a full specification MUST - be provided here, and there should be a reasonable expectation that - the documentation will remain available. IANA will consult with - the IESG or its specified delegate if there is doubt about whether - the specification is adequate for the purpose. + registered "about" URI. IANA will consult with the IESG or its + specified delegate if there is doubt about whether the + specification is adequate for this purpose. The following is a template for "blank" token: o Registered Token: blank o Intended usage: The URI must resolve to a blank page. o Handling query component: No special provisions. o Contact/Change controller: IESG (on behalf of IETF). o Specification: This document. @@ -294,23 +283,23 @@ [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. Appendix A. Acknowledgments This document has been formed from the draft initially authored by, additionally to Lachlan Hunt, the editor of the current one, Joseph Holsten. Additionally, the contributions of Frank Ellermann and - Alexey Melnikov are gratefully acknowledged. Barry Leiba deserves a - special credit for providing a great amount of text which has been - used in this document. + Alexey Melnikov are gratefully acknowledged. Barry Leiba and Murray + Kucherawy deserve a special credit for providing a great amount of + text which has been used in this document. Authors' Addresses Lachlan Hunt (editor) Opera Software, ASA. EMail: lachlan.hunt@lachy.id.au URI: http://lachy.id.au/ Mykyta Yevstifeyev (editor)