Applications Area WG (APPSAWG)                              L. Hunt, Ed.
Internet-Draft                                      Opera Software, ASA.
Intended Status: Standards Track                     M. Yevstifeyev, Ed.
Expires: April 19, June 11, 2012                                 October 17,                                  December 9, 2011

                         The 'about' "about" URI Scheme


   This document defines specifies the 'about' "about" URI scheme, that 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
   other groups may also distribute working documents as

   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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright and License Notice

   Copyright (c) 2011 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
   ( 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.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. URI Scheme Specification  . . . . . . . . . . . . . . . . . . .  3
     2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . .  3
     2.2. URI Scheme Semantics  . . . . . . . . . . . . . . . . . . .  3
       2.2.1. Special-Purpose 'about' "about" URIs  . . . . . . . . . . . . .  3
       2.2.2. Unrecognized 'about' URIs . . . . . . . . . . . . . . .  4
     2.3. Encoding Considerations . . . . . . . . . . . . . . . . . .  4
   3. Security Considerations . . . . . . . . . . . . . . . . . . . .  4
   4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  5  4
     4.1. URI Scheme Registration . . . . . . . . . . . . . . . . . .  5  4
     4.2. A Registry for SPTs . . . . . . . Registered Tokens  . . . . . . . . . . . . .  5
   5. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1. Normative References  . . . . . . . . . . . . . . . . . . .  6
     5.2. Informative References  . . . . . . . . . . . . . . . . . .  7
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7

1. Introduction

   This document specifies the 'about' "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' "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.

   As use of 'about' "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' "about" URIs
   are set.

   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",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2. URI Scheme Specification

2.1. URI Scheme Syntax

   The 'about' "about" URI MUST syntactically conform to the <about-uri> rule
   below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]:

     about-uri   = "about:" about-token [ about-query ]
     about-token = *( unreserved / pct-encoded )
               ; for the WG discussion: the possible variants are:
               ; = *pchar     or = segment
               ; = 1*pchar    or = segment-nz
               ; = segment-nz-nc
               ; this is to be decided by WG.
     about-query = "?" query
     pchar       = <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>,
   and <about-query> to the query component of URI.

2.2. URI Scheme Semantics

   Generally speaking, the resource a particular 'about' "about" URI resolves to
   is denoted by <about-token> part of the URI, and <about-query>
   specifies additional information concerning its handling and/or the
   information that should be returned in the resource a URI is resolved

   However, it is impossible to specify binding between all the possible
   tokens and the semantics of 'about' "about" URIs that would contain such
   tokens.  Therefore
   tokens, which this document does not attempt to do.  Therefore, any
   application MAY resolve resolving an 'about' "about" URI to any
   desired resource, and MAY redirect such URIs.  Several exceptions are
   defined, though; they are named "special-purpose 'about' URIs" and
   MUST be handled in strict accordance choose the resource it is
   resolved to at its own discretion, with provisions set in Section
   2.2.1. 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).

2.2.1. Special-Purpose 'about' "about" URIs

   A small, though expandable, range of <about-token>s are reserved for
   use in
   special purposes ("special-purpose tokens").

   A special-purpose 'about' URIs, abbreviated "SPU" (special-
   purpose URI).  Such tokens are named "special-purpose 'about' URI
   tokens", and abbreviated "SPT" (special-purpose token).

   An SPU URI is an 'about' "about" URI containing one of the registered SPTs that has a special-purpose
   token as the its <about-token> part.  An SPU  Such URIs MUST be handled in strict
   accordance with the rules defined for SPT contained therein. in the special-purpose token
   registry (see Section 4.2).  The SPT specification registered entry MAY also define
   additional provisions on for handling of the <about-query> part in part.  If no
   such provisions are defined, the corresponding SPU; by default, it query part has no meaning, and MUST
   be ignored for the purpose
   of handling SPU.

   SPU MAY be defined to be unresolvable. ignored.

   This means that an
   application MUST NOT resolve it in some particular resource.  Such
   SPUs may be used as placeholders, or in some other way.

   One pre-defined SPT is specified: the "blank" SPT. document defines one special-purpose token: "blank".  The URI
   "about:blank" MUST resolve to a blank page; this page need not
   necessarily contain no data, it should rather represent blank page. page, as seen by the end user.
   There is no additional handling of the query component in <about:blank>
   URIs: both <about:blank> and <about:blank?foo> shall resolve into the
   blank page.
   "about:blank" URIs.

   Additional SPTs may special-purpose tokens can be defined via adding the entry in the registry
   created by this document.  Please note that defining registering an SPT
   registry created in Section 4.2. Special-purpose "about" URIs are
   intended to be uncommon, and new ones should
   only be used as a last resort approach, defined only when a strict limitation on
   handling 'about' URI with such SPT
   there is necessary.

2.2.2. Unrecognized 'about' URIs

   Naturally, an application will support only a need to strongly connect a particular range of
   'about' URIs; also, some applications will support 'about' URIs that
   are not supported by an other one.  This document specifies the rules
   for handling unrecognized 'about' URIs.

   An unrecognized 'about' URIs as <about-token> with a URI that may not be recognized by
   an application.  (Correspondingly, such categorization is per-
   application, not per-fact.)  An unrecognized 'about' URI SHOULD be
   handled as the <about:blank> URI, although other behavior is
   particular function in all applications.

2.3. Encoding Considerations


   "about" URIs are subject to encoding rules defined in RFC 3986
   [RFC3986].  'about'  "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' "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' "about"

4. IANA Considerations

4.1. URI Scheme Registration

   IANA is asked to update the register the 'about' "about" URI scheme using in the
   following template, per "URI Schemes"
   registry defined in Section 5.4 of 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' "about" URIs are
     predominantly used by Web browsers, although they may be used by
     other applications.

     Security considerations: see Section 3 of RFC xxxx

     Contact: IESG <> (on behalf of the IETF)

     Author/Change controller: Applications Area IETF <> Working Group

     References: see Section 5 of RFC xxxx

   [RFC Editor: Please replace xxxx with assigned RFC number]

4.2. A Registry for SPTs Registered Tokens

   IANA is asked to set up a new registry entitled "'about' URIs SPTs" URI Special
   Purpose Tokens" following the guidelines below.

   The registry entries consist of 3 fields: SPT, Special-Purpose Token,
   Description and Reference.  The SPT Special-Purpose Token field MUST
   conform to <about-token> production defined in Section 2.1.  The
   initial registry contents consist consists of one entry:


   | SPT Special-Purpose  | Description                        | Reference |
   | Token            |                                    |           |
   | blank            | Used in 'about' "about" URIs referring to a refer to   | RFC xxxx  |
   |                  | blank page.                        |           |

   The registration policy procedures for new entries is "Specification Required",
   as defined this registry are "First Come First
   Served", described in RFC 5226 [RFC5226].  Additionally, [RFC5226], with supporting
   documentation meeting the following
   template requirements below.  The registrant of the
   token MUST provide the following registration template, which will be provided by
   made available on IANA web site:

   [[for the WG discussion:  I, as the WG participant, am convinced that
   we do need Specification Required here.  This is a burden, but this
   (and the expert) will give us a warranty that the registered token is
   really useful and is really part of some serious project, probably
   standardization effort.  I'd like this also would be discussed in the
   WG, and the registrant: WG would change its mind.  (Moreover, as I don't expect
   the registrations to be very often, this won't take a great deal of
   experts' time.)]]

   o SPT: Registered Token:  The desired special-purpose token to be used in 'about'
     "about" URIs.

   o Intended usage:  A short description of how 'about' "about" URIs with the
     registered token must be handled; especially, what they must be
     resolved to, if resolvable.

   o Resolvable:  "Yes" if resolvable (i.e. can be resolved to a
     particular resource) or "No" if unresolvable (see Section 2.2.1).

   o Handling query component:  It should be mentioned whether there are
     some provisions on handling query components in the 'about' "about" URIs
     with the registered token.

   o Contact/Change controller:  An individual or an organization which
     (1) should be contacted for more details, and (2) is authorized to
     change the registration.

   o Published specifications:  A Specification.  This provides documentation at a level that could
     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 published specification is adequate for the registered token. purpose.

   The following is a template for "blank" SPT: token:

   o SPT: Registered Token:  blank
   o Intended usage:  The <about:blank> URI must resolve to a blank
   o Resolvable:  Yes.
   o Handling query component:  No special provisions.
   o Contact/Change controller:  IESG <> (on behalf of
   o Published specifications: Specification:  This document.

5. References

5.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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

5.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 <TBD> 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.

Authors' Addresses

   Lachlan Hunt (editor)
   Opera Software, ASA.


   Mykyta Yevstifeyev (editor)
   8 Kuzovkov St., Apt. 25