Subject: Re: [apps-discuss] apps-team review of draft-holsten-about-uri-scheme-06

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 15 Jun 2011 18:24:41 +0300

18.03.2011 21:46, Alexey Melnikov wrote:
> Hi Martin,
> As authors didn't respond to your comments and I need to pass on 
> shepherding of this document to Peter, so I will quickly respond to 
> clarify where I stand on your comments (as the shepherding AD):
Hello all,

The authors of draft-holsten-about-uri-scheme allowed me to help them 
with the draft.  The -07 version is almost ready; it is believed to 
incorporate comments from Martin above.  Let me inform what was changed 
with regard to each of these points.
>
> Martin J. Dürst wrote:
>
>> I have been selected as the Applications Area Review Team reviewer for
>> this draft (for background on apps-review, please see
>> http://www.apps.ietf.org/content/applications-area-review-team).
>> Please resolve these comments along with any other Last Call comments
>> you may receive. Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>>
>>
>> Document: draft-holsten-about-uri-scheme-06
>> Title: The 'about' URI scheme
>> Reviewer: Martin J. Dürst
>> Review Date: February 7, 2011
>>
>>
>> Summary: This draft is not ready for publication, but because it is 
>> short, the problems identified below could be fixed soon.
>>
>> This draft defines the about: URI scheme, a scheme that has been used 
>> internally, informally by browsers since ages. It's good to see this 
>> defined and registered finally, but there are some problems that need 
>> to be fixed.
>>
>>
>> Major Issues:
>>
>> - Section 5.1: "Other specification MAY reserve "about" URIs.": How 
>> is this done? And done in a way that gives implementers a chance to 
>> know about it? Surely if specifications are involved, a very 
>> lightweight version of IANA registry/process should not be too heavy. 
>> For my own taste, even a Wikipedia page might do the job, but just 
>> leaving this open looks like a bad idea. If additions are thought to 
>> be very infrequent, "updates to this specification" might also do the 
>> job.
>
> I think pretty much everybody (including GenArt, Ted Hardie and 
> myself) spotted this issue.
Currently, the registry for 'about' URI tokens is intended to be 
created.  The proposed text is:
> 9.2. IANA Registry for Reserved 'about' URIs Tokens
>
>    IANA is asked to create and maintain the registry called "Reserved
>    'about' URIs Tokens" following the guidelines below.
>
>    The registry provides a listing of registered reserved 'about' URI
>    tokens.  The reserved 'about' URI token refers to the string used in
>    the <about-token> part of reserved 'about' URIs, with the syntax
>    described in Section 2 for this rule.  The entries in the registry
>    MUST refer only to those values that are used in reserved 'about'
>    URIs, as described in Section 5.1.
>
>    The registration procedures for this registry are 'First Come First
>    Served', described in RFC 5226 [RFC5226].  The registrant of such
>    token SHALL also provide the following registration template, that
>    SHALL be available on IANA web site:
>
>      Reserved 'about' URI Token.  REQUIRED field.  Desired 'about' URI
>      token, compliant to the syntax described in Section 2 of this
>      document for the <about-token> rule
>
>      Intended Usage.  REQUIRED field.  A short description of intended
>      usage of 'about' URI with such token
>
>      Resolvable 'about' URI.  REQUIRED field.  Should be "yes" if
>      resolvable or "no" if unresolvable, per Section 5.2 of this
>      document
>
>      Specification.  OPTIONAL field.  References to the document(s), if
>      any, that described the registered 'about' URI token
>
>      Assignment Notes.  OPTIONAL field.  Any additional information
>      about the assignment
>
>      Contact/Change Controller.  REQUIRED field.  A person or an
>      organization, authorized to change this registration, that should
>
>      be contacted for further information on the registered 'about'
>      URI,with their contact points
>
> 9.2.1.  Initial Contents
>
>    The registry initially contains the following registration:
>
>      'about' URI token:  blank
>
>      Intended usage:  The "about:blank" URI returns the blank page
>
>      Resolvable 'about' URI:  Yes
>
>      Specification:  RFC XXXX (this document - note to RFC Editor)
>
>      Author/Change Controller:  W3C <[email-masked]>

>
>> - 6. Normalization: This is confused. There are NO standard URI 
>> normalization rules, just various choices, in RFC 3986. And the 
>> choice of normalization rule is NOT a per-scheme choice, it's a 
>> per-usage choice, where usage for XML namespaces differs widely from 
>> usage for some protocol-based resolutions, and that again differs 
>> widely from what spiders and robots do. As an example, when used as 
>> an XML namespace URI, "about:blank" and "about:blan%6B" identify 
>> different namespaces. The text should make it excruciatingly clear 
>> that the normalization rules given there apply ONLY to (browser 
>> built-in) resolution of about URIs. Also, the phrase "Due to the 
>> structure of the "about" URI, some normalizations do not apply, 
>> specifically ..." is inappropriate given the examples following, and 
>> unnecessary.
>
> Right.
This was considered.  The current Section 7 (the renumbered Section 6) 
reads:

> 7.  Normalization
>
>    'about' URIs use the following URI normalization rules of [RFC3986]:
>    Simple String Comparison, Case Normalization, and Percent-Encoding
>    Normalization.  For example, "about:blank", "about:blan%6B" and
>    "about:blan%6b" are equivalent, though the percent-encoded forms are
>    discouraged.
>
>    Note that these normalization rules apply only to the case of
>    application built-in resolution of 'about' URIs, i.e. "about:blan%6B"
>    and "about:blank" SHALL be resolved in the same way.  Other cases of
>    these URIs usage would require other normalization rules
Some words concerning 
http://www.ietf.org/mail-archive/web/ietf/current/msg66862.html are also 
planned to be added, I think.
>> Minor Issues:
>>
>> - The split of about: URIs into three kinds (reserved, unreserved, 
>> and unrecognized) is highly confusing. It looks as if two binary 
>> distinctions are conflated: a) The distinction between reserved and 
>> unreserved, which is a distinction from a specification point. b) The 
>> distinction between recognized and unrecognized, which is a 
>> distinction from an implementation (resolution) point. There's 
>> nothing to rule out reserved but unrecognized about: URIs in the 
>> future (with only about:blank being standardized at the moment, and 
>> unrecognized about: URIs defaulting to about:blank, there's currently 
>> no such case).
>
> Agreed.
I think this is considered in the following paragraph added in Section 5:

>    The division of 'about' URIs into the reservation and resolution
>    categories is per-fact while the recognition per-application.
>    Therefore, while an 'about' URI may be classified as, for example,
>    reserved and resolvable, it may be not be recognized by all
>    applications.

>
>> - The abstract describes the about: scheme. It should explicitly 
>> contain the wording "defines ... the about: scheme", because that's 
>> the most important thing done with this document. That will also make 
>> the Abstract more different from the Introduction; currently the read
>
> Ok.
Current abstract is:

> Abstract
>
>    This document specifies the 'about' URI scheme, that may be used by
>    the applications for almost any desired purpose, such as providing
>    access to application information, settings, preferences, etc.  This
>    URI scheme has been used by many web browsers for quite a long time
>    informally, i. e. without being documented; this document is to
>    remove such uncertainty and give this scheme an official
>    specification.

>
>> - The abstract and the text mention "easter eggs". There are large 
>> parts of the world where Easter isn't known, and nor are Easter eggs 
>> (in the general sense of fancifully colored eggs). On top of this, 
>> the use of the term "easter egg" in the document is a very 
>> specialized hacker jargon use. Proposal: Remove from abstract, add 
>> explanation in text.
>
> Possibly. I wouldn't worry too much about this particular issue: I 
> hope RFC Editor can provide a good advice on this.
The reference to http://en.wikipedia.org/wiki/Easter_egg_%28media%29 was 
added to clarify this.
>
>> - End of first paragraph of Section 4: "then only those octets that 
>> do not correspond to characters in the unreserved set [RFC3986] 
>> SHOULD be percent-encoded." This can very easily be misunderstood. 
>> The writer seems to want to apply the SHOULD to 'only', but readers 
>> will apply it to 'percent-encoded', meaning that an implementation 
>> might be okay even if it didn't percent-encode characters outside the 
>> unreserved set. The best thing to do here is to not make this 
>> normative language (because RFC 3986 already defines what's allowed 
>> and what not). The authors seems to be worried that some people might 
>> apply percent-escaping to a-z and such, but this is not something to 
>> worry about in practice.
>
> I actually found similar text in other RFCs.
The sentence was changed to:

> those octets that correspond to characters in the unreserved set 
> [RFC3986] should noy be percent-encoded.

>
>> - Section 5 starts defining various kinds of "about" URIs. It should 
>> start by first saying that there are three different kinds of "about" 
>> URIs, to make the reader's job easier (but see above).
Now it is:

> 5.  Resolving 'about' URIs
>
>    All 'about' URIs are categorized in three ways:
>
>    o Reservation.  [ . . . ]

>>
>> - Section 5.1.1 contains a lone sentence fragment 'i.e. 
>> "about:blank".', which seems to be unnecessary.
Corrected.
>>
>> - 5.4. Examples is inconsistent with final punctuation.
Corrected as well.
>>
>> - I seem to remember that the change controller for standards track 
>> stuff is the IESG. But I may be wrong.
>
> Yes.
After some internal discussions it was decided to remain W3C change 
controller; yet, they will still need IESG approval to make changes to 
registration.

As soon as some other minor issues are considered, I think -07 will be 
published.  At least, at the end of June, I hope.

Mykyta Yevstifeyev
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Jun 2011 18:23:14 +0200

Back in January I sent a comment to the authors of this good
I-D, but I guess that mail never made it.  Just in case, because it's
apparently still not *too* late, I add the content below.
----------------------------------------------------------------
Hi, I like your "about" Internet-Draft. If you are not already
in Last Call a simple suggestion:

You offer well-known examples such as about:plugins and about:mozilla.
One thing users often have to fight with is to
FIND relevant about: URIs for their UA. Sometimes
about:about is used to display a list of relevant about: URIs.

If you would add about:about as example this will encourage
developers to support it in their product.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 17 Jun 2011 06:21:54 +0300

> apparently still not *too* late, I add the content below.
I think this will be considered.

Mykyta
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>