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

Mykyta Yevstifeyev <> Wed, 15 June 2011 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 838C421F849F; Wed, 15 Jun 2011 08:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f4uAHzqLyrAp; Wed, 15 Jun 2011 08:24:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 655E721F8493; Wed, 15 Jun 2011 08:23:59 -0700 (PDT)
Received: by fxm15 with SMTP id 15so565897fxm.31 for <multiple recipients>; Wed, 15 Jun 2011 08:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZZmwJ/ktzzzR3063P7pQViUholgyEuGU7r6QURRbk6E=; b=bCELpv2PpHdyCNWXuHwDI8GARX/XM6r3mCHK2u29twC/0yqsL52IG97QWJKoQWhTpR bUdvElOw1BnZQi3pqdydHBSb7QAiQkOIqnUrHjJ114+vXFUrt4kAOoAeXn61b1ZcBNMs Ltp+SIDhICRJAKOHvwO4b+jbeLomMOpLIfTok=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wXbNJ3AfYdgcMm+WdfX2C1RYv4FCBkXnRkDFd75nzFOV4WPvJ9558lGrHmoAuudpXG rp4W90+ttbamHf6pLzT4c6xQWCkdhNNcKJpi/jqTcFXMCM4roy6K49oN4LgHqqRcOznv 9Tr+/T7E65in1DrY/gSaf2bo9pMKrsFStl3dk=
Received: by with SMTP id w1mr771281fai.42.1308151438466; Wed, 15 Jun 2011 08:23:58 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id l26sm281789fah.14.2011. (version=SSLv3 cipher=OTHER); Wed, 15 Jun 2011 08:23:56 -0700 (PDT)
Message-ID: <>
Date: Wed, 15 Jun 2011 18:24:41 +0300
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Alexey Melnikov <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "" <>,, "" <>, IESG <>
Subject: Re: [apps-discuss] apps-team review of draft-holsten-about-uri-scheme-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jun 2011 15:24:07 -0000

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

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

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

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