--- 1/draft-ietf-appsawg-about-uri-scheme-04.txt 2012-05-29 13:14:11.717341997 +0200 +++ 2/draft-ietf-appsawg-about-uri-scheme-05.txt 2012-05-29 13:14:11.733342660 +0200 @@ -1,18 +1,18 @@ -Applications Area WG (APPSAWG) L. Hunt, Ed. -Internet-Draft Opera Software, ASA. -Intended Status: Standards Track M. Yevstifeyev, Ed. -Expires: September 22, 2012 March 21, 2012 +Applications Area WG (APPSAWG) S. Moonesamy, Ed. +Internet-Draft +Intended Status: Informational +Expires: November 30, 2012 May 29, 2012 The "about" URI Scheme - draft-ietf-appsawg-about-uri-scheme-04 + draft-ietf-appsawg-about-uri-scheme-05 Abstract 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 @@ -46,265 +46,229 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 6 + 2. URI Scheme Specification . . . . . . . . . . . . . . . . . . . 2 + 2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 2 + 2.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 2 + 2.2.1. Well-known "about" URIs . . . . . . . . . . . . . . . . 3 + 2.3. Encoding Considerations . . . . . . . . . . . . . . . . . . 3 + 3. "about:blank" . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 + 5.1. URI Scheme Registration . . . . . . . . . . . . . . . . . . 4 + 5.2. A Registry for Well-known Tokens . . . . . . . . . . . . . 4 + 5.2.1. Registration procedure . . . . . . . . . . . . . . . . 5 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 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 + scheme. The "about" URI scheme is currently widely used by Web + browsers 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 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. - - 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]. + hidden feature or joke in an application). 2. URI Scheme Specification 2.1. URI Scheme Syntax - The "about" URI MUST syntactically conform to the rule - below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]: + The "about" URI syntactically conforms to the rule below, + expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]: about-uri = "about:" about-token [ about-query ] 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 + The resource which a particular "about" URI references is denoted by + part of the URI. The specifies + additional information about its handling and/or the information that + should be returned by the resource which the URI references. - 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 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 + 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 generally considered + as specific to a Web browser implementation. - A small, though expandable, range of s is reserved for - special purposes ("special-purpose tokens"). +2.2.1. Well-known "about" URIs - 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. + Some s have been reserved as the behavior when the + resource is referenced is well-known. (Well-known tokens). - 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. + A well-known "about" URI is a URI that has a well-known token as its + part. It is recommended that such URIs be handled in + accordance with the specification referenced in the Well-known token + registry (see Section 5.2). - 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. + Well-known "about" URIs are intended to be registered when there is a + need to codify the behavior of particular . 2.3. Encoding Considerations "about" URIs are subject to encoding rules defined in RFC 3986 - [RFC3986]. "about" IRIs [RFC3987] are not permitted. + [RFC3986]. For the sake of simplicity, "about" IRIs [RFC3987] are + not permitted. -3. Security Considerations +3. "about:blank" - Generic security considerations for URIs are discussed in Section 7 - 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. + This document defines one well-known token: "blank". The URI + "about:blank" refers to a resource represented in the browser by a + blank page. - "about" URIs can sometimes refer to a sensitive information, such as +4. Security Considerations + + Security considerations for URIs are discussed in Section 7 of RFC + 3986 [RFC3986]. However, most of those provisions do not apply to + the "about" URI scheme as they are mainly scoped to schemes used in + the Internet. + + "about" URIs can sometimes refer to 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. + that the user's data is secured and no threats are imposed by "about" + URIs. -4. IANA Considerations +5. IANA Considerations -4.1. URI Scheme Registration +5.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]: + The registration of the "about" URI scheme in the "URI Schemes" + registry is requested. The information below is provided according to + the guidelines from RFC 4395 [RFC4395]: URI scheme name: about Status: Permanent URI scheme syntax: see Section 2.1 of RFC xxxx URI scheme semantics: see Section 2.2 of RFC xxxx URI scheme encoding considerations: see Section 2.3 of RFC xxxx - Applications/protocols that use the scheme: "about" URIs are - predominantly used by Web browsers, although they may be used by - other applications. + Applications that use the scheme: "about" URIs are predominantly + Web browsers. - Security considerations: see Section 3 of RFC xxxx + Security considerations: see Section 4 of RFC xxxx Contact: IETF Applications Area Directors Author/Change controller: IESG (on behalf of the IETF) References: see Section 5 of RFC xxxx [RFC Editor: Please replace xxxx with assigned RFC number] -4.2. A Registry for Registered Tokens +5.2. A Registry for Well-known Tokens - IANA is asked to set up a new registry entitled "'about' URI Special - Purpose Tokens" following the guidelines below. + This document creates the '"about" URI Well-known Tokens' registry. - The registry entries consist of 3 fields: Special-Purpose Token, - 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: + The registry entries consist of three fields: Well-known Token, + Description and Reference. The Well-known Token field has to conform + to production defined in Section 2.1. The initial set + of assignments is as follows: +------------------+------------------------------------+-----------+ | 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 ought to provide the following registration template, which - will be made available on IANA web site: +5.2.1. Registration procedure + + The registration policy for this registry is "First Come First + Served" as described in RFC 5226 [RFC5226]. The registrant of the + token should provide the information mentioned in the following + registration template: 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, to what resource they - are to resolve. - - o Handling query component: Describe any requirements for handling - query components in "about" URIs that contain the registered token. + registered token is handled including information about the + referenced resource. - 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 Contact/Change controller: Person (including contact information) + authorized to change this registration. - o Specification. A permanent reference to a specification that can - be used to create a compliant, interoperable implementation of the - 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. + o Specification: A stable reference to a document which specifies + the registered "about" URI. The question of interoperability does + not arise. The key motivation is to have a reference to a + specification documenting well-known behavior of the "about" URI in + Web browsers. As a rule of thumb if the behavior is common to two + or more Web browser implementations it can be considered as well- + known. 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 Intended usage: The URI references a blank page. o Contact/Change controller: IESG (on behalf of IETF). - o Specification: This document. - -5. References + o Specification: RFC xxxx. [RFC Editor: Please replace xxxx with + assigned RFC number] -5.1. Normative References +6. References - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. +6.1. Normative References [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. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. -5.2. Informative References +6.2. Informative References [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. 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 and Murray - Kucherawy deserve a special credit for providing a great amount of - text which has been used in this document. - -Authors' Addresses + This document has been formed from the draft initially authored by + Lachlan Hunt and Joseph Holsten. Additionally, the contributions of + Frank Ellermann and 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. - Lachlan Hunt (editor) - Opera Software, ASA. + Lachlan Hunt and Mykyta Yevstifeyev edited previous versions of this + document. Tim Bray and John Klensin provided suggestions about how + to improve the document. - EMail: lachlan.hunt@lachy.id.au - URI: http://lachy.id.au/ +Authors' Addresses - Mykyta Yevstifeyev (editor) - 8 Kuzovkov St., Apt. 25 - Kotovsk - Ukraine + S. Moonesamy (editor) + 76, Ylang Ylang Avenue + Quatre Bornes + Mauritius - EMail: evnikita2@gmail.com + EMail: sm+ietf@elandsys.com