Re: [Uri-review] ACTION-103 Follow up on the about: scheme Registration

On Feb 22, 2010, at 8:26 AM, Julian Reschke wrote:
> 1)
> 
> "7. Relative "about" URIs
> 
>   As "about" URIs do not use a hierarchical path, relative "about" URIs
>   are not permitted."
> 
> I think this is misleading.
> 
> A relative reference, as defined in <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.2>, does not contain a URI scheme (by definition). So it's meaningless to talk about the scheme of a reference.
> 
> In doubt, just drop the paragraph.

It's meaningless, but there are a few issues. First, as a stupid implementor writing a URI parser and handler, I'm used to having to deal with relative URIs. Obviously, I'm going to be confused about the right thing to do is. I want to tell these people, "Don't worry, you don't have to deal with relative about URIs, they don't exist."

Second, what exactly should happen if an application shows an HTML page at about:config, and that page has a link to a URI without a scheme? Opera's about:config (nee opera:config) includes links with same-document references like:

  <a href="#AuthorDisplayMode|AuthorCSS" onclick="sct(this);">»</a>

So it's reasonable to wonder what might happen if that link looked like a relative URI.

Maybe it should also say, 'Applications that want to link from a resource at an "about" URI should either use an absolute URI (e.g. about:cache?device=offline) or a same-document URI (e.g. #SectionOne).'

Thoughts?

> 2) The spec talks a lot about reserved "about:" URIs, but does not state how they can be reserved. I understand that there is no process for that, and that this is by design, but maybe it should be stated more clearly.

Part of me thinks there should be a registry for ones reserved by specs. By the time of publication, the reserved ones are about:blank, about:legacy-compat, and about:srcdoc. If someone wants to reserve one, they're welcome to spec it out and publish it somewhere, be that w3.org or whatever.info. An app that wants to implement that spec should provide any about URIs defined by that spec. Otherwise, those URIs are unreserved with respect to that app, regardless of whether they recognize them or not.

For example, someone could write a spec reserving about:cache and defining what resources should be available through it. An app not implementing that spec can recognize the URI (that is, not treat it the same as about:blank) but treat it as unreserved and respond with whatever resource it wants.

Does that sound about right? I'll go about editing those sections to be more clear. Is anyone hurting for lack of a registry? I'm not inclined to create one otherwise.

> That being said, once the recent comments are addressed I would advise to request publication.

Sounds lovely.
--
j

Received on Tuesday, 23 February 2010 09:08:46 UTC