idnits 2.17.1 draft-ietf-appsawg-about-uri-scheme-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2012) is 4436 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Applications Area WG (APPSAWG) L. Hunt, Ed. 3 Internet-Draft Opera Software, ASA. 4 Intended Status: Standards Track M. Yevstifeyev, Ed. 5 Expires: September 5, 2012 March 4, 2012 7 The "about" URI Scheme 8 draft-ietf-appsawg-about-uri-scheme-03 10 Abstract 12 This document specifies the "about" URI scheme, that is widely used 13 by Web browsers and some other applications to designate access to 14 their internal resources, such as settings, application information, 15 hidden built-in functionality, and so on. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. URI Scheme Specification . . . . . . . . . . . . . . . . . . . 3 58 2.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 3 60 2.2.1. Special-Purpose "about" URIs . . . . . . . . . . . . . 3 61 2.3. Encoding Considerations . . . . . . . . . . . . . . . . . . 4 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. URI Scheme Registration . . . . . . . . . . . . . . . . . . 4 65 4.2. A Registry for Registered Tokens . . . . . . . . . . . . . 5 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 This document specifies the "about" Uniform Resource Identifier (URI) 75 scheme, that is currently widely used by Web browsers and some other 76 applications to designate access to their internal resources, such as 77 settings, application information, so called "Easter eggs" (i.e. 78 hidden feature or joke in an application), and so on. 80 The concept of "about" URIs has been formed at the times when the 81 applications did not have the "friendly" user interface, in order to 82 provide an access to the aforementioned resources via typing the URIs 83 in the address bar. Even though the user interface of current 84 Internet-targeted software effectively rescinds the issue, and 85 "about" URIs can be thought to be a rudimentary phenomenon, they are 86 still supported by a variety of Web browsers and are not going to 87 cease to exist. 89 As use of "about" URIs has been quiet long-lasting, and the URIs have 90 been used without any proper registration and absent any proper 91 specification, the necessity for the the latter two actions arises. 92 The purpose of this document is to provide a stable specification for 93 "about" URI scheme and correspondingly register it in the IANA 94 registry. Along, several provisions for handling the "about" URIs 95 are set. 97 Please consult RFC 3986 [RFC3986] for definition of generic URIs 98 syntax and RFC 4395 [RFC4395] for description of registration process 99 for new URI schemes. 101 1.1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2. URI Scheme Specification 109 2.1. URI Scheme Syntax 111 The "about" URI MUST syntactically conform to the rule 112 below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]: 114 about-uri = "about:" about-token [ about-query ] 115 about-token = *pchar 116 about-query = "?" query 117 pchar = 118 query = 120 In terms of RFC 3986, part corresponds to , 121 and to the query component of URI. 123 2.2. URI Scheme Semantics 125 Generally speaking, the resource a particular "about" URI resolves to 126 is denoted by part of the URI, and 127 specifies additional information concerning its handling and/or the 128 information that should be returned in the resource a URI is resolved 129 to. 131 However, it is impossible to specify binding between all the possible 132 tokens and the semantics of "about" URIs that would contain such 133 tokens, which this document does not attempt to do. Therefore, any 134 application resolving an "about" URI MAY choose the resource it is 135 resolved to at its own discretion, with the exception of those 136 defined below as 'special-purpose "about" URIs'. They MAY use 137 internal redirection to accomplish this (for instance, Opera 138 redirects all "about" URIs except "about:blank" to its internal 139 "opera" URIs). 141 2.2.1. Special-Purpose "about" URIs 143 A small, though expandable, range of s are reserved for 144 special purposes ("special-purpose tokens"). 146 A special-purpose URI is an "about" URI that has a special-purpose 147 token as its part. Such URIs MUST be handled in strict 148 accordance with the rules defined in the special-purpose token 149 registry (see Section 4.2). The registered entry MAY also define 150 additional provisions for handling of the part. If no 151 such provisions are defined, the query part has no meaning, and MUST 152 be ignored. 154 This document defines one special-purpose token: "blank". The URI 155 "about:blank" MUST resolve to a blank page, as seen by the end user. 156 There is no additional handling of the query component in 157 "about:blank" URIs. 159 Additional special-purpose tokens can be defined by registering an 160 registry created in Section 4.2. Special-purpose "about" URIs are 161 intended to be uncommon, and new ones should be defined only when 162 there is a need to strongly connect a particular with a 163 particular function in all applications. 165 2.3. Encoding Considerations 167 "about" URIs are subject to encoding rules defined in RFC 3986 168 [RFC3986]. "about" IRIs [RFC3987] are not permitted. 170 3. Security Considerations 172 Generic security considerations for URIs are discussed in Section 7 173 of RFC 3986 [RFC3986]. However, many of those provisions hardly 174 apply to "about" URI scheme, as they are mainly scoped to schemes 175 used in the Internet, not internally. 177 "about" URIs may sometimes refer to a sensitive information, such as 178 user passwords stored in a cache, or parameter that, if changed, may 179 affect user's data. The application should therefore ensure that 180 user's data is in the safety, and no threats are imposed by "about" 181 URIs. 183 4. IANA Considerations 185 4.1. URI Scheme Registration 187 IANA is asked to register the "about" URI scheme in the "URI Schemes" 188 registry defined in Section 5.4 of RFC 4395 [RFC4395]: 190 URI scheme name: about 192 Status: Permanent 193 URI scheme syntax: see Section 2.1 of RFC xxxx 195 URI scheme semantics: see Section 2.2 of RFC xxxx 197 URI scheme encoding considerations: see Section 2.3 of RFC xxxx 199 Applications/protocols that use the scheme: "about" URIs are 200 predominantly used by Web browsers, although they may be used by 201 other applications. 203 Security considerations: see Section 3 of RFC xxxx 205 Contact: IETF Applications Area Directors 207 Author/Change controller: IESG (on behalf of the 208 IETF) 210 References: see Section 5 of RFC xxxx 212 [RFC Editor: Please replace xxxx with assigned RFC number] 214 4.2. A Registry for Registered Tokens 216 IANA is asked to set up a new registry entitled "'about' URI Special 217 Purpose Tokens" following the guidelines below. 219 The registry entries consist of 3 fields: Special-Purpose Token, 220 Description and Reference. The Special-Purpose Token field MUST 221 conform to production defined in Section 2.1. The 222 initial registry consists of one entry: 224 +------------------+------------------------------------+-----------+ 225 | Special-Purpose | Description | Reference | 226 | Token | | | 227 +------------------+------------------------------------+-----------+ 228 | blank | Used in "about" URIs to refer to | RFC xxxx | 229 | | blank page. | | 230 +------------------+------------------------------------+-----------+ 232 The registration procedures for this registry are "First Come First 233 Served", described in RFC 5226 [RFC5226], with supporting 234 documentation meeting the requirements below. The registrant of the 235 token MUST provide the following registration template, which will be 236 made available on IANA web site: 238 o Registered Token: The desired special-purpose token to be used in 239 "about" URIs. 241 o Intended usage: A short description of how "about" URIs with the 242 registered token must be handled; especially, what they must be 243 resolved to, if resolvable. 245 o Handling query component: It should be mentioned whether there are 246 some provisions on handling query components in the "about" URIs 247 with the registered token. 249 o Contact/Change controller: An individual or an organization which 250 (1) should be contacted for more details, and (2) is authorized to 251 change the registration. 253 o Specification. This provides documentation at a level that could 254 be used to create a compliant, interoperable implementation of the 255 registered "about" URI. The reference to a full specification MUST 256 be provided here, and there should be a reasonable expectation that 257 the documentation will remain available. IANA will consult with 258 the IESG or its specified delegate if there is doubt about whether 259 the specification is adequate for the purpose. 261 The following is a template for "blank" token: 263 o Registered Token: blank 264 o Intended usage: The URI must resolve to a blank 265 page. 266 o Handling query component: No special provisions. 267 o Contact/Change controller: IESG (on behalf of 268 IETF). 269 o Specification: This document. 271 5. References 273 5.1. Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, March 1997. 278 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 279 Resource Identifier (URI): Generic Syntax", STD 66, 280 RFC 3986, January 2005. 282 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 283 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 284 May 2008. 286 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 287 Syntax Specifications: ABNF", STD 68, RFC 5234, January 288 2008. 290 5.2. Informative References 292 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 293 Identifiers (IRIs)", RFC 3987, January 2005. 295 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 296 Registration Procedures for New URI Schemes", BCP 35, 297 RFC 4395, February 2006. 299 Appendix A. Acknowledgments 301 This document has been formed from the draft initially authored by, 302 additionally to Lachlan Hunt, the editor of the current one, Joseph 303 Holsten. Additionally, the contributions of Frank Ellermann and 304 Alexey Melnikov are gratefully acknowledged. Barry Leiba deserves a 305 special credit for providing a great amount of text which has been 306 used in this document. 308 Authors' Addresses 310 Lachlan Hunt (editor) 311 Opera Software, ASA. 313 EMail: lachlan.hunt@lachy.id.au 314 URI: http://lachy.id.au/ 316 Mykyta Yevstifeyev (editor) 317 8 Kuzovkov St., Apt. 25 318 Kotovsk 319 Ukraine 321 EMail: evnikita2@gmail.com