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

Joseph A Holsten <joseph@josephholsten.com> Mon, 01 June 2009 17:10 UTC

Return-Path: <josephholsten@gmail.com>
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 1904B3A6ADE for <uri-review@core3.amsl.com>; Mon, 1 Jun 2009 10:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 xZquBDsVKxIZ for <uri-review@core3.amsl.com>; Mon, 1 Jun 2009 10:10:49 -0700 (PDT)
Received: from mail-qy0-f112.google.com (mail-qy0-f112.google.com [209.85.221.112]) by core3.amsl.com (Postfix) with ESMTP id BB3BF3A681D for <uri-review@ietf.org>; Mon, 1 Jun 2009 10:10:48 -0700 (PDT)
Received: by qyk10 with SMTP id 10so4949620qyk.29 for <uri-review@ietf.org>; Mon, 01 Jun 2009 10:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=LfjohPuoYYkGsMa1bftLbpRFJ7p2V2MiGNwe3F8R4xY=; b=Iplsz7yR+iKNtzfYjDhEOrsZpeePjAopZ4UTFlGsaG73d1QNtJD3Mk1HngRICyJLGe Ag6fgFoPdB7xtuFyMPqZzi9/dSODcDdPu1Tw7Hs/Ci5ux2TZox65abDi8tZ2ENPklUWB UDpRmGbsA1EHA4oEieillQAe8Wr0IcwnkUy4U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=hepmCYLIhAfyHmpclxRonecky2bZUtsoMdCyMjAgbr5ggDb7ckzurUNXtDEXsPQVuC dObsJiFsPI0Rv2nXN9Wm0IV+GSMJgeDFVfIU1ulxRy2IsBCh/bOcTiFfGc5TUV9qiR91 svxJo83V6oHY2kTUhZcs+hzfxkyzUCAnkeSAI=
Received: by 10.224.11.137 with SMTP id t9mr5825371qat.178.1243876245744; Mon, 01 Jun 2009 10:10:45 -0700 (PDT)
Received: from ?10.0.1.166? (adsl-70-234-133-221.dsl.tul2ok.sbcglobal.net [70.234.133.221]) by mx.google.com with ESMTPS id 4sm14142191yxj.2.2009.06.01.10.10.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 10:10:45 -0700 (PDT)
Sender: Joseph Holsten <josephholsten@gmail.com>
Message-Id: <97B77D67-06C8-4C6E-89FE-1B2AACA263BC@josephholsten.com>
From: Joseph A Holsten <joseph@josephholsten.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
In-Reply-To: <7bac1511j86e6sphequmeeecaijp6k3dg7@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Mon, 01 Jun 2009 12:10:43 -0500
References: <DF9860F7-1AA1-4B94-9B6A-62B9C6E4E294@josephholsten.com> <7bac1511j86e6sphequmeeecaijp6k3dg7@hive.bjoern.hoehrmann.de>
X-Mailer: Apple Mail (2.935.3)
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: Mon, 01 Jun 2009 17:10:50 -0000

Let me be sure I understand all of this before I draft the necessary  
changes:

Straghtforward changes:
* Remove fragment part from syntax
* Reframe URI syntax as an IRI syntax to automagically handle  
character encoding
* Remove information about relative URI syntax
* Request provisional IANA scheme status, removing mention of  
permanent status
* Move RFC2119 reference to Terminology section
* Replace 'SHOULD NOT need to' with 'SHOULD NOT'
* Change 'About URIs SHOULD NOT cause the application to modify any  
data' to 'Implementations of the scheme SHOULD NOT modify data when  
processing about resource identifiers'

Changes which will require thinking:
* Clarify comparison of about URIs, eg whether (about:blank ==  
about:BLANK), (about:blank == about:blank?)
     I'm inclined to only require applications to use string  
comparison for about URIs, if an application wants about:BLANK to  
identify a resource similar to about:blank, that's their business.

* Clarify in what way about URIs are application specific/ 
implementation defined
     I still feel that the act of 'resolving' and 'representing'  
resources identified by about URIs is a purely implementation defined.  
To me that means: the meaning of the resource should be the same, but  
the way of getting and showing the resource is undefined. But the  
language is obviously not clear. The semantics are in line with URNs,  
but some existing URIs (e.g. about:cache?device=offline in mozilla)  
use characters that don't work in URN. Otherwise I'd just say about:  
URIs are equivalent to urn:about: URNs. I'll see if there's some  
language I can reuse in one of those..

* Isolate what depends on HTML5 and remove it.
     I'm not sure the mention of effective script origin for an HTML  
document identified by about:blank needs to be said here. I'm  
comfortable saying about:blank must identify an empty resource and  
have a representation with media-type  text/html;charset=utf-8.

Did I miss anything?

Joseph Holsten


On May 21, 2009, at 11:46 PM, Bjoern Hoehrmann wrote:

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