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

Bjoern Hoehrmann <derhoermi@gmx.net> Fri, 22 May 2009 04:44 UTC

Return-Path: <derhoermi@gmx.net>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116D23A6C35 for <uri-review@core3.amsl.com>; Thu, 21 May 2009 21:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.113
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdVfgME5-SKZ for <uri-review@core3.amsl.com>; Thu, 21 May 2009 21:44:46 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9D6593A699F for <uri-review@ietf.org>; Thu, 21 May 2009 21:44:45 -0700 (PDT)
Received: (qmail invoked by alias); 22 May 2009 04:46:15 -0000
Received: from dslb-094-223-208-076.pools.arcor-ip.net (EHLO hive) [94.223.208.76] by mail.gmx.net (mp039) with SMTP; 22 May 2009 06:46:15 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/G82wkIqLGU5BtL0EfKUIA95SL1pUsxIPyjA+b7W xayJaDQBgLiS6J
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Joseph A Holsten <joseph@josephholsten.com>
Date: Fri, 22 May 2009 06:46:15 +0200
Message-ID: <7bac1511j86e6sphequmeeecaijp6k3dg7@hive.bjoern.hoehrmann.de>
References: <DF9860F7-1AA1-4B94-9B6A-62B9C6E4E294@josephholsten.com>
In-Reply-To: <DF9860F7-1AA1-4B94-9B6A-62B9C6E4E294@josephholsten.com>
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
Cc: uri-review@ietf.org
Subject: Re: [Uri-review] Request to review about URI scheme
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=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
scheme.

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

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
draft.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/