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

["Martin J. Dürst" <[e-mail]>]

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.

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


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).

- 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

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

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

- 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).

- Section 5.1.1 contains a lone sentence fragment 'i.e. "about:blank".', 
which seems to be unnecessary.

- 5.4. Examples is inconsistent with final punctuation.

- I seem to remember that the change controller for standards track 
stuff is the IESG. But I may be wrong.


Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[e-mail]