Re: [Uri-review] Request to review about URI scheme

Bjoern Hoehrmann <> Fri, 22 May 2009 04:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 116D23A6C35 for <>; Thu, 21 May 2009 21:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.113
X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=-4.114, BAYES_00=-2.599, J_CHICKENPOX_55=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XdVfgME5-SKZ for <>; Thu, 21 May 2009 21:44:46 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 9D6593A699F for <>; Thu, 21 May 2009 21:44:45 -0700 (PDT)
Received: (qmail invoked by alias); 22 May 2009 04:46:15 -0000
Received: from (EHLO hive) [] by (mp039) with SMTP; 22 May 2009 06:46:15 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/G82wkIqLGU5BtL0EfKUIA95SL1pUsxIPyjA+b7W xayJaDQBgLiS6J
From: Bjoern Hoehrmann <>
To: Joseph A Holsten <>
Date: Fri, 22 May 2009 06:46:15 +0200
Message-ID: <>
References: <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.58
Subject: Re: [Uri-review] Request to review about URI scheme
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 May 2009 04:44:52 -0000

* Joseph A Holsten wrote:
>I've published draft-holsten-about-uri-scheme[1], which defines the  
>about URI scheme. It is ready for public review. There is also some  
>background for the scheme under HTML ACTION-103[2].

There are several contradictions in the draft. For example, the Abstract
says resolution is entirely implementation defined, then goes on to say
this is not the case for about:blank; another example are the IANA Con-
siderations, they request both permanent and provisional status for the

Section 4.1 fails to define what an empty resource is. It is also
unclear what exactly is an "about:blank URI", for example, does that
include an "about:BLANK URI", or a "about:blank? URI"?

BCP 115 requires a description of character encoding issues and IRI com-
patibility. The draft fails to account for that.

Editorially, the introduction is a bad place to reference the RFC 2119
keywords, a separate section called e.g. "Terminology" would be a better
place. Also, in section 4, the statement "SHOULD NOT need" is difficult
to understand correctly.

The statement in section 3 that "No relative URI syntax is defined."
does not make sense. Processing of relative references happens at a
different layer than about scheme specific processing.

In section 5 the statement "About URIs SHOULD NOT cause the application
to modify any data." is probably misphrased, clearly, a string cannot
cause an application to do anything. Perhaps you mean to say that imple-
mentations of the scheme should not modify data when processing about
resource identifiers.

The encoding considerations in the template appear to be incorrect. For
example, percent-encoding is also allowed in the fragment and query
components. On that I will also note that it is incorrect to define the
fragment part in the scheme registration; the scheme specific part of a
resource identifier ends immediately before the fragment identifier.

Further, proper content for the field would rather be something about
character encodings and IRI processing. On that I would recommend to
simply define an IRI scheme rather than an URI scheme, the mapping to
URIs would then be covered by the IRI specificiation.

>The main outstanding issue is a normative reference to HTML5, which  
>defines some behavior for about:blank. It seems wrong to normatively  
>reference a working draft, and the best way to solve the issue isn't  

The draft does not seem to rely on "HTML5" at all, in fact, it seems
rather that the "HTML5" draft has "about:blank" specific processing
requirements for a specific class of applications. If so, then you
can avoid the problem by simply removing any mention of this from the
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·