[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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