Applications Area WG (APPSAWG)                              L. Hunt,                         S. Moonesamy, Ed.
Internet-Draft                                      Opera Software, ASA.
Intended Status: Standards Track                     M. Yevstifeyev, Ed. Informational
Expires: September 22, November 30, 2012                               March 21,                                  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

   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.

   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
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2012 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
   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. URI Scheme Specification  . . . . . . . . . . . . . . . . . . .  2
   2.
     2.1. URI Scheme Specification Syntax . . . . . . . . . . . . . . . . . . .  3
     2.1. . .  2
     2.2. URI Scheme Syntax Semantics  . . . . . . . . . . . . . . . . . . .  2
       2.2.1. Well-known "about" URIs . .  3
     2.2. URI Scheme Semantics . . . . . . . . . . . . . .  3
     2.3. Encoding Considerations . . . . .  3
       2.2.1. Special-Purpose "about" URIs . . . . . . . . . . . . .  3
     2.3. Encoding Considerations
   3. "about:blank" . . . . . . . . . . . . . . . . . .  4
   3. . . . . . . .  3
   4. Security Considerations . . . . . . . . . . . . . . . . . . . .  4
   4.  3
   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.
     5.1. URI Scheme Registration . . . . . . . . . . . . . . . . . .  4
     4.2.
     5.2. A Registry for Registered Well-known Tokens  . . . . . . . . . . . . .  4
       5.2.1. Registration procedure  . . . . . . . . . . . . . . . .  5
   5.
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  5
     6.1. Normative References  . . . . . . . . . . . . . . . . . . .  6
     5.2.  5
     6.2. Informative References  . . . . . . . . . . . . . . . . . .  6
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7  6

1. Introduction

   This document specifies the "about" Uniform Resource Identifier (URI)
   scheme, that
   scheme.  The "about" URI scheme is currently widely used by Web
   browsers and some other
   applications to designate access to their internal resources, 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]. application).

2. URI Scheme Specification

2.1. URI Scheme Syntax

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

     about-uri   = "about:" about-token [ about-query ]
     about-token = *pchar
     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
   The resource to which a particular "about" URI
   resolves references is denoted by
   <about-token> part of the URI, and <about-
   query> URI.  The <about-query> specifies
   additional information concerning about its handling and/or the information that
   should be returned in by the resource to which the URI resolves.

   However, it references.

   It is impossible to specify a binding between all the possible tokens
   and the semantics of "about" URIs that would contain such tokens.  Therefore,
   Therefore the resource referenced by the URI is
   application-specific, except for those listed below generally considered
   as 'special-
   purpose "about" URIs'.  Applications MAY use internal redirection specific to
   accomplish this (for instance, the Opera web a Web browser redirects all
   "about" URIs except "about:blank" to its internal "opera" URIs). implementation.

2.2.1. Special-Purpose Well-known "about" URIs

   A small, though expandable, range of

   Some <about-token>s is have been reserved for
   special purposes ("special-purpose tokens"). as the behavior when the
   resource is referenced is well-known. (Well-known tokens).

   A special-purpose well-known "about" URI is an "about" a URI that has a special-purpose well-known token as its
   <about-token> part.  Such  It is recommended that such URIs MUST be handled in strict
   accordance with the rules defined specification referenced in the special-purpose Well-known token
   registry (see Section 4.2).  The registered entry MAY also define
   additional provisions for handling of the <about-query> 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 by updating the
   registry created in Section 4.2. Special-purpose 5.2).

   Well-known "about" URIs are intended to be uncommon, and new ones should be defined only registered when there is a
   need to strongly connect a particular <about-token> with a codify the behavior of particular function in all applications. <about-token>.

2.3. Encoding Considerations

   "about" URIs are subject to encoding rules defined in RFC 3986
   [RFC3986].  For the sake of simplicity, "about" IRIs [RFC3987] are
   not permitted.

3. "about:blank"

   This document defines one well-known token: "blank".  The URI
   "about:blank" refers to a resource represented in the browser by a
   blank page.

4. Security Considerations

   Generic security

   Security considerations for URIs are discussed in Section 7 of RFC
   3986 [RFC3986].  However, few most of those provisions do not apply to
   the "about" URI scheme, scheme as they are mainly scoped to schemes used in
   the
   Internet, not internally. Internet.

   "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, secured and no threats are imposed by "about"
   URIs.

4.

5. IANA Considerations

4.1.

5.1. URI Scheme Registration

   IANA is asked to register

   The registration of the "about" URI scheme in the "URI Schemes"
   registry defined in Section 5.4 of 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

     Applications that use the scheme: "about" URIs are predominantly used by
     Web browsers, although they may be used by
     other applications. browsers.

     Security considerations: see Section 3 4 of RFC xxxx

     Contact: IETF Applications Area Directors <app-ads@tools.ietf.org>

     Author/Change controller: IESG <iesg@ietf.org> (on behalf of the
     IETF)

     References: see Section 5 of RFC xxxx

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

4.2.

5.2. A Registry for Registered Well-known Tokens

   IANA is asked to set up a new registry entitled "'about' URI Special
   Purpose Tokens" following

   This document creates the guidelines below. '"about" URI Well-known Tokens' registry.

   The registry entries consist of 3 three fields: Special-Purpose Well-known Token,
   Description and Reference.  The Special-Purpose Well-known Token field has to conform
   to <about-token> production defined in Section 2.1.  The initial registry consists set
   of one entry: assignments is as follows:

   +------------------+------------------------------------+-----------+
   | Special-Purpose  | Description                        | Reference |
   | Token            |                                    |           |
   +------------------+------------------------------------+-----------+
   | blank            | Used in "about" URIs to refer to   | RFC xxxx  |
   |                  | blank page.                        |           |
   +------------------+------------------------------------+-----------+

5.2.1. Registration procedure

   The registration procedures policy for this registry are is "First Come First
   Served",
   Served" as described in RFC 5226 [RFC5226], with supporting
   documentation meeting the requirements below. [RFC5226].  The registrant of the
   token ought to should provide the information mentioned in the following
   registration template, which
   will be made available on IANA web site: 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 is handled including information about the registered token.
     referenced resource.

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

   o Specification. Specification:  A permanent stable reference to a specification that can
     be used to create a compliant, interoperable implementation of document which specifies
     the registered "about" URI.  IANA will consult with The question of interoperability does
     not arise.  The key motivation is to have a reference to a
     specification documenting well-known behavior of the IESG or its
     specified delegate "about" URI in
     Web browsers.  As a rule of thumb if there is doubt about whether the
     specification behavior is adequate for this purpose. 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 <about:blank> URI must resolve to references a blank page.
   o Handling query component:  No special provisions.
   o Contact/Change controller:  IESG <iesg@ietf.org> (on behalf of
     IETF).
   o Specification:  This document.

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

6. References

5.1.

6.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
              2008.

5.2.

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 by
   Lachlan Hunt, the editor of the current one, 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.

Authors' Addresses

   Lachlan Hunt (editor)
   Opera Software, ASA.

   EMail: lachlan.hunt@lachy.id.au
   URI:   http://lachy.id.au/ and Mykyta Yevstifeyev edited previous versions of this
   document.  Tim Bray and John Klensin provided suggestions about how
   to improve the document.

Authors' Addresses

   S. Moonesamy (editor)
   8 Kuzovkov St., Apt. 25
   Kotovsk
   Ukraine
   76, Ylang Ylang Avenue
   Quatre Bornes
   Mauritius

   EMail: evnikita2@gmail.com sm+ietf@elandsys.com