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

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 18 March 2011 19:45 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9863F3A6926; Fri, 18 Mar 2011 12:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.103
X-Spam-Level:
X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZSu-sRPCAy1; Fri, 18 Mar 2011 12:45:48 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C497E3A691C; Fri, 18 Mar 2011 12:45:47 -0700 (PDT)
Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TYO2wwADL3ze@rufus.isode.com>; Fri, 18 Mar 2011 19:47:16 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4D83B681.60906@isode.com>
Date: Fri, 18 Mar 2011 19:46:09 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
References: <4D4FD50E.2020503@it.aoyama.ac.jp>
In-Reply-To: <4D4FD50E.2020503@it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Cc: draft-holsten-about-uri-scheme@tools.ietf.org, "uri-review@ietf.org" <uri-review@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] apps-team review of draft-holsten-about-uri-scheme-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2011 19:45:49 -0000

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.