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

[Alexey Melnikov <[e-mail]>]

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

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.

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

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

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

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

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

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

Yes.