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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/