RFC 6694

The "about" URI Scheme

📅 published August 2012, from ietf

RFC 6694: The "about" URI Scheme 🦋

Internet Engineering Task Force (IETF) ✨ Written by S. Moonesamy, Ed. and dated August 2012 🎀. It's Informational, so it's published for information and isn't an Internet Standards Track spec 💅. The header has no Obsoletes or Updates lines, so it doesn't replace or change any other RFC 🌸. The ISSN is 2070-1721.

Internet Engineering Task Force (IETF)                 S. Moonesamy, Ed.
Request for Comments: 6694                                   August 2012
Category: Informational
ISSN: 2070-1721

Abstract

Okay so this doc is all about the "about" URI scheme 🧚. Web browsers and some other apps use it all the time to open their own internal stuff, like settings, app info, and hidden built-in features 💖.

Status of This Memo 📋

Quick heads up: this is not an Internet Standards Track spec. It's just published for info 🌈.

It's an IETF product and it reflects IETF community consensus. It got public review and the IESG approved it for publication 🫶. Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious ✨.

For the latest status, errata, or feedback, go to http://www.rfc-editor.org/info/rfc6694 🔗.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are at http://trustee.ietf.org/license-info and apply on the publication date 📜. Please actually read those, because they spell out your rights and restrictions for this doc 🙈. Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes 💀.

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 doc describes the "about" Uniform Resource Identifier (URI) scheme 🎀. Web browsers use it a lot to get to their internal resources, like settings, app info, and so-called "Easter eggs" 🥚. An Easter egg is a hidden feature or joke in an app, and it's honestly iconic 😭.

2. URI Scheme Specification 💅

2.1. URI Scheme Syntax 🧩

An "about" URI has to match the <about-uri> rule below. The grammar is written in 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>

2.2. URI Scheme Semantics 🔮

The resource a particular "about" URI points to is named by its <about-token> part. It isn't a hierarchical element for a naming authority, so no authority vibes here 🙅. The <about-query> part adds extra info about how the URI gets handled, or what the resource should return 💜.

Honestly, you can't map every possible token to a meaning, so the resource a URI points to is usually specific to whatever Web browser implementation you're using 🌈.

2.2.1. Well-Known "about" URIs 👑

Some <about-token>s are reserved, because the behavior of their resource is well-known. Those are the well-known tokens 🧁.

A well-known "about" URI is one whose <about-token> part is a well-known token. It is recommended that these URIs get handled according to the spec referenced in the "about" URI Tokens registry (see Section 5.2) 🫧.

Well-known "about" URIs are meant to get registered when someone needs to codify what a particular <about-token> does 📝.

2.3. Encoding Considerations 🔤

"about" URIs follow the encoding rules in RFC 3986 [RFC3986] ✨.

3. "about:blank" ⬜

This doc defines exactly one well-known token, which is "blank" 🫶. The "about:blank" URI points to a resource that the browser shows as a blank page 🤍.

4. Security Considerations 🔐

⚠️ Read this part carefully, bestie. It's serious.

The security stuff for URIs is in Section 7 of RFC 3986 [RFC3986]. But most of it doesn't apply to the "about" scheme, since it's mostly written for schemes used on the Internet 🙃.

"about" URIs can point at sensitive info, like user passwords stored in a cache, or parameters that could mess with a user's data if someone changed them 😭. So the application has to make sure the user's data is locked down and that "about" URIs don't pose a threat 🚨. No cap, this is the most important part of the whole doc 💀.

5. IANA Considerations 🏛️

5.1. URI Scheme Registration 📚

The "about" scheme is already in the "Permanent URI Schemes" registry 🎉. Here's the info, following the guidelines in 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.

5.2. A Registry for Well-Known Tokens 🗃️

This doc creates the '"about" URI Tokens' registry 🧾. Each entry has three fields: Token, Description, and Reference 🫧. The Token field has to match the <about-token> production from Section 2.1 💅. Here's the starting assignment:

   +--------------+------------------------------------+-------------+
   | Token        | Description                        | Reference   |
   +--------------+------------------------------------+-------------+
   | blank        | The about:blank URI references a   | RFC 6694    |
   |              | blank page.                        |             |
   +--------------+------------------------------------+-------------+

5.2.1. Registration Procedure 📝

This registry uses "First Come First Served", as described in RFC 5226 [RFC5226] 🎟️. The registrant should give the info in the template below 💖:

  • Registered token: The well-known token you want to use in "about" URIs.
  • Intended usage: A short description of how "about" URIs with that token get handled, including info about the resource they reference.
  • Contact/change controller: The person, with contact info, who's allowed to change this registration.
  • Specification: A stable reference to a doc that specifies the registered "about" URI. Interoperability isn't really the question here 🙃. The main goal is a reference to a spec that documents the well-known behavior of "about" URIs in Web browsers. As a rule of thumb, if the behavior is common to two or more Web browser implementations, it can count as well-known 🌸. An existing assignment may be duplicated if the registered token gets used in more than one Web browser implementation 🫶.

Here's the template filled in for the "blank" token ✨:

  • Registered token: blank
  • Intended usage: The about:blank URI references a blank page.
  • Contact/change controller: IESG <iesg@ietf.org> (on behalf of the IETF).
  • 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.

Appendix A. Acknowledgments 🫶

This doc grew out of an earlier draft by Lachlan Hunt and Joseph Holsten 🌷. Frank Ellermann and Alexey Melnikov also get thanks for their contributions 💜. Barry Leiba and Murray Kucherawy deserve huge credit for writing a ton of the text used here 👑.

Lachlan Hunt and Mykyta Yevstifeyev edited earlier versions 🧚. Tim Bray and John Klensin gave suggestions on how to make it better 🦋.

Author's Address 📮

   S. Moonesamy (editor)
   76 Ylang Ylang Avenue
   Quatre Bornes
   Mauritius

   EMail: sm+ietf@elandsys.com
📦 where this page comes from