diff options
Diffstat (limited to 'doc/rfc/rfc6694.txt')
-rw-r--r-- | doc/rfc/rfc6694.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc6694.txt b/doc/rfc/rfc6694.txt new file mode 100644 index 0000000..7050c38 --- /dev/null +++ b/doc/rfc/rfc6694.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Moonesamy, Ed. +Request for Comments: 6694 August 2012 +Category: Informational +ISSN: 2070-1721 + + + The "about" URI Scheme + +Abstract + + This document describes 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 document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6694. + +Copyright 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. + + + + + + +Moonesamy Informational [Page 1] + +RFC 6694 The "about" URI Scheme August 2012 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. URI Scheme Specification ........................................2 + 2.1. URI Scheme Syntax ..........................................2 + 2.2. URI Scheme Semantics .......................................3 + 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 ...........................5 + 5.2.1. Registration Procedure ..............................5 + 6. References ......................................................6 + 6.1. Normative References .......................................6 + 6.2. Informative References .....................................6 + Appendix A. Acknowledgments ........................................7 + +1. Introduction + + This document describes the "about" Uniform Resource Identifier (URI) + scheme. The "about" URI scheme is currently widely used by Web + browsers to designate access to their internal resources, such as + settings, application information, and so-called "Easter eggs" (i.e., + a hidden feature or joke in an application). + +2. URI Scheme Specification + +2.1. URI Scheme Syntax + + The "about" URI syntactically conforms to the <about-uri> rule below, + expressed using the Augmented Backus-Naur Form (ABNF) [RFC5234]: + + about-uri = "about:" about-token [ about-query ] [ about-fragment ] + about-token = *pchar + about-query = "?" query + about-fragment = "#" fragment + pchar = <as specified in RFC 3986, Appendix A> + query = <as specified in RFC 3986, Appendix A> + fragment = <as specified in RFC 3986, Appendix A> + + + + + + + + + + +Moonesamy Informational [Page 2] + +RFC 6694 The "about" URI Scheme August 2012 + + +2.2. URI Scheme Semantics + + The resource that is referenced by a particular "about" URI is + denoted by the <about-token> part of the URI. It is not a + hierarchical element for a naming authority. The <about-query> part + specifies additional information about its handling and/or the + information that should be returned by the resource referenced by + the URI. + + 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 + to be specific to a Web browser implementation. + +2.2.1. Well-Known "about" URIs + + Some <about-token>s have been reserved, as the behavior of the + resource that is referenced is well-known (well-known tokens). + + A well-known "about" URI is a URI that has a well-known token as its + <about-token> part. It is recommended that such URIs be handled in + accordance with the specification referenced in the "about" URI + Tokens registry (see Section 5.2). + + Well-known "about" URIs are intended to be registered when there is a + need to codify the behavior of a particular <about-token>. + +2.3. Encoding Considerations + + "about" URIs are subject to encoding rules as defined in RFC 3986 + [RFC3986]. + +3. "about:blank" + + This document defines one well-known token: "blank". The + "about:blank" URI refers to a resource represented in the browser by + a blank page. + +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. + + + + + + + +Moonesamy Informational [Page 3] + +RFC 6694 The "about" URI Scheme August 2012 + + + "about" URIs can sometimes refer to sensitive information, such as + user passwords stored in a cache, or parameters that, if changed, + could affect a user's data. The application therefore needs to + ensure that the user's data is secured and no threats are imposed by + "about" URIs. + +5. IANA Considerations + +5.1. URI Scheme Registration + + The "about" URI scheme has been registered in the "Permanent URI + Schemes" registry. 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 6694. + + URI scheme semantics: See Section 2.2 of RFC 6694. + + URI scheme encoding considerations: See Section 2.3 of RFC 6694. + + Applications that use the scheme: "about" URIs are predominantly + used by Web browsers. + + Security considerations: See Section 4 of RFC 6694. + + 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 6 of RFC 6694. + + + + + + + + + + + + + + + +Moonesamy Informational [Page 4] + +RFC 6694 The "about" URI Scheme August 2012 + + +5.2. A Registry for Well-Known Tokens + + This document creates the '"about" URI Tokens' registry. + + The registry entries consist of three fields: Token, Description, and + Reference. The Token field has to conform to <about-token> + production as defined in Section 2.1. The initial assignment is as + follows: + + +--------------+------------------------------------+-------------+ + | Token | Description | Reference | + +--------------+------------------------------------+-------------+ + | blank | The about:blank URI references a | RFC 6694 | + | | blank page. | | + +--------------+------------------------------------+-------------+ + +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 well-known token to be used in + "about" URIs. + + o Intended usage: A short description of how "about" URIs with the + registered token are handled, including information about the + referenced resource. + + o Contact/change controller: Person (including contact information) + authorized to change this registration. + + o Specification: A stable reference to a document that 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 + well-known. An existing assignment may be duplicated if the + registered token is used in more than one Web browser + implementation. + + + + + + + + + +Moonesamy Informational [Page 5] + +RFC 6694 The "about" URI Scheme August 2012 + + + The following is a template for the "blank" token: + + o Registered token: blank + + o Intended usage: The about:blank URI references a blank page. + + o Contact/change controller: IESG <iesg@ietf.org> (on behalf of the + IETF). + + o Specification: RFC 6694 + +6. References + +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. + +6.2. Informative References + + [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and + Registration Procedures for New URI Schemes", BCP 35, + RFC 4395, February 2006. + + + + + + + + + + + + + + + + + + + +Moonesamy Informational [Page 6] + +RFC 6694 The "about" URI Scheme August 2012 + + +Appendix A. Acknowledgments + + This document was formed from a previous draft document 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 special + credit for providing a great amount of text that was used in this + document. + + Lachlan Hunt and Mykyta Yevstifeyev edited previous versions of this + document. Tim Bray and John Klensin provided suggestions about how + to improve the document. + +Author's Address + + S. Moonesamy (editor) + 76 Ylang Ylang Avenue + Quatre Bornes + Mauritius + + EMail: sm+ietf@elandsys.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moonesamy Informational [Page 7] + |