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

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Feb 2010 17:08:49 +0100

Julian Reschke wrote:
> Lachlan Hunt wrote:
>> ...
>> (Sorry for the late reply, it seems I forgot to respond earlier.)
>>
>> The purpose of reserving a URI is so that other specifications can't 
>> suddenly redefine the URI to return something that is unneeded or 
>> unwanted by the spec that originally reserved it.  The main use is for 
>> about:legacy-compat, which needs to be reserved in HTML5, but which 
>> should never be formally defined as resolvable to anything specific.
>>
>> We don't want, for example, another specificaiton in the future 
>> suddenly defining that about:legacy-compat should resolve to some sort 
>> of unofficial HTML5 DTD.  But we still want to allow browsers to 
>> return something useful to a user that enters it into their address 
>> bar.  e.g. Some sort of informative page explaining why the URI can be 
>> used in the DOCTYPE, which would be more useful and user friendly than 
>> the error or blank page that browsers return today.
>>
>> Finally, can you please give an update on when you will be publishing 
>> a new draft, and continuing with the URI registration process?
>> ...
> 
> Joseph, Lachlan, any news on this?
> ...

I note that draft-holsten-about-uri-scheme-02 was submitted six months 
ago. We do not seem to make progress.

Joseph, Lachlan, are you still interested to finish this? Otherwise, 
this should get a new editor.

Best regards, Julian

---

From: Lachlan Hunt <[email-masked]>
Date: Mon, 08 Feb 2010 22:40:45 +0100

> this should get a new editor.

I have updated and published a new draft.  The most significant changes 
to this were in section 5.

http://www.ietf.org/id/draft-holsten-about-uri-scheme-03.txt

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

---

From: Joseph Anthony Pasquale Holsten <[email-masked]>
Date: Mon, 8 Feb 2010 22:06:56 -0600

On Feb 8, 2010, at 3:40 PM, Lachlan Hunt wrote:

> I have updated and published a new draft.  The most significant changes to this were in section 5.
> 

A quick diff suggests this is the same as what had been up in github, with
 - rfc2xml template changes
 - s/recognize/recognise/ 
 - breaking about:blank into section §5.1.1
 - using a MAY in §5.2¶1
 - saying "Note: " in §5.1¶2
All of which sounds great, and I've incorporated into the current branch an http://github.com/josephholsten/about-uri-scheme.

The current branch also includes
- s/Internationlized/Internationalized/
- s/refered/referred/

What seems to be left, none particularly important:
- add an example using a query param. about:cache?device=offline is a gecko example, I don't know of one in more than a single rendering engine.
- enclose non-terminal ABNF rules in angle brackets instead of quotes per RFC5234. Currently I'm using style=verb here, and style=vdeluxe proves it's possible to have a style that wraps in "<" and ">". Either I can patch xml2rfc, just hard code it into the source, or the buddha will show me a third way. I'm assuming I'll be hard coding it.

And I'd love it if there was a way to make Encoding Considerations and Normalization less awful to read. All I want to say is that normal encoding and normalization procedures apply, we're not trying to use any special cases. Instead I have 200 words of jargon.

Is that all that remains?
--
Joseph Holsten
http://josephholsten.com
mailto:[email-masked]
tel:+1-918-948-6747

---

From: Lachlan Hunt <[email-masked]>
Date: Tue, 09 Feb 2010 11:19:15 +0100

Joseph Anthony Pasquale Holsten wrote:
> All of which sounds great, and I've incorporated into the current
> branch an http://github.com/josephholsten/about-uri-scheme.
>

We should be consistent with the use of en-GB or en-US spellings. 
Normally, I would prefer to use en-GB, but in this case, since we have 
to deal with references to sections in RFC 3986 for "... Normalization", 
which uses the US spellings, and various other refernces that should use 
US spellings, it's easier and more consistent to use en-US for 
everything, than to carefully use en-GB for most things while leaving 
en-US where necessary.

> And I'd love it if there was a way to make Encoding Considerations
> and Normalization less awful to read. All I want to say is that
> normal encoding and normalization procedures apply, we're not trying
> to use any special cases. Instead I have 200 words of jargon.

I think these are fine as is

> Is that all that remains?

I'm not aware of anything else.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Feb 2010 12:54:47 +0100

> We should be consistent with the use of en-GB or en-US spellings. 

Spelling will be adjusted by the RFC-Editor anyway.

BR, Julian

---

From: Graham Klyne <[email-masked]>
Date: Sun, 14 Feb 2010 09:54:32 +0000

Ironically, many English people think that -ize is an Americanism, but it's also 
the traditional English form, and, with a very few exceptions, is the preferred 
form according to the Oxford English dictionary.  Go figure :)

#g
--

...

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Feb 2010 15:26:11 +0100

> I'm not aware of anything else.

One comment, one nit:

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.

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.

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

Best regards, Julian

---

From: Joseph Holsten <[email-masked]>
Date: Tue, 23 Feb 2010 03:08:10 -0600

On Feb 22, 2010, at 8:26 AM, Julian Reschke wrote:
> 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.
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Feb 2010 10:27:06 +0100

On 23.02.2010 10:08, Joseph Holsten wrote:
>> 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.
>>

Well, there aren't relative URIs. They are called "relative references". 
They do not have a scheme.

So the question needs to be rephrased as: "what does happen when I 
resolve a relative reference against an "about" URI"? The answer is the 
same for all URIs (because generic URI processors need to be able to do 
this regardless the scheme), and the answer is in RFC 3986, Section 5 
(<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5>).

Best regards, Julian

---

From: Joseph Holsten <[email-masked]>
Date: Tue, 23 Feb 2010 05:34:11 -0600

On Feb 23, 2010, at 3:27 AM, Julian Reschke wrote:

> Well, there aren't relative URIs. They are called "relative references". They do not have a scheme.
> 
> So the question needs to be rephrased as: "what does happen when I resolve a relative reference against an "about" URI"? The answer is the same for all URIs (because generic URI processors need to be able to do this regardless the scheme), and the answer is in RFC 3986, Section 5 (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5>).

I learn something new every day. Looks like I just swiped this from RFC 2397.

Trouble is, I'm seriously confused as to whether about URIs can or can't have relative references. So far as I can tell, RFC 3986 §4.4 says the handling of short same-document references (e.g. #SectionOne) is formally defined in §5.2.2. But §D.2 says:

"The determination of whether a URI reference is a same-document reference has been decoupled from the URI parser, simplifying the URI processing interface within applications in a way consistent with the internal architecture of deployed URI processing implementations. The determination is now based on comparison to the base URI after transforming a reference to absolute form, rather than on the format of the reference itself. This change may result in more references being considered "same-document" under this specification than there would be under the rules given in RFC 2396, especially when normalization is used to reduce aliases. However, it does not change the status of existing same-document references."

Which makes me think I'm wrong. Surely there is a way for non-hierarchical URIs to handle same-document references. Obviously the recomposition function in §5.3 only generates hierarchical URIs. I want to say this is a bug in RFC 3986, but that seems hard to believe.

I'm beginning to think the reason I added that line was to remind myself that this is hard to verify.

Links:
RFC 2397. The "data" URL scheme, http://tools.ietf.org/html/rfc2397
RFC 3986 §4.4. Same-Document Reference, http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.4
RFC 3986 §5.3. Component Recomposition, http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.3
RFC 3986 §D.2. Modifications. http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.D.2
--
j

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Feb 2010 14:08:28 +0100

> I learn something new every day. Looks like I just swiped this from RFC 2397.

You mean:

"The "data" URL scheme has no relative URL forms."

? Understood. I may be wrong about all of this, but this is misleading 
as well, and should be corrected in a future version.

> Trouble is, I'm seriously confused as to whether about URIs can or can't have relative references...
You can't forbid it. That being said, they may not do what you want them 
to do, so you could discourage their use.

> So far as I can tell, RFC 3986 §4.4 says the handling of short same-document references (e.g. #SectionOne) is formally defined in §5.2.2. But §D.2 says:

Where does it say that?

> I'm beginning to think the reason I added that line was to remind myself that this is hard to verify.

OK, let's consider

Base URI:  <about:config>

Reference: <#foo>

According to RFC 3986, Section 5, these are parsed into the components 
scheme, authority, path, query, fragment:

Base URI: ("about", undefined, "config", undefined, undefined)

Reference: (undefined, undefined, undefined, undefined, "foo")

According to 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.2.2>, the 
resulting resolved URI would have the following components:

("about", undefined, "config", undefined, "foo")

Recomposition according to 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.3> yields:

	<about:config#foo>

So I don't see a problem here. Am I getting this wrong?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 23 Feb 2010 15:48:12 -0800

> Trouble is, I'm seriously confused as to whether about URIs can or can't have relative references. So far as I can tell, RFC 3986 §4.4 says the handling of short same-document references (e.g. #Sec…

As Julian said, the "about" scheme has no choice in the matter.
Relative references exist.  RFC 3986 defines how to turn a relative
reference into an absolute reference, regardless of scheme.

You don't need to do or say anything about relative references
in a scheme specification other than to refer to RFC 3986.

....Roy

---

From: Joseph Holsten <[email-masked]>
Date: Tue, 23 Feb 2010 22:55:06 -0600

On Feb 23, 2010, at 7:08 AM, Julian Reschke wrote:
> Base URI:  <about:config>
> 
> Reference: <#foo>
> 
> According to RFC 3986, Section 5, these are parsed into the components scheme, authority, path, query, fragment:
> 
> According to <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.2.2>, the resulting resolved URI would have the following components:
> 
> Recomposition according to <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.5.3> yields:
> 
> 	<about:config#foo>
> 

Nope, I simply misunderstood the recomposition code. I kept imagining that it would append "//" after the scheme. No doubt I was confusing an undefined authority with an authority of "".

I should note that at least one set of about URIs will act funny with reference parsing, those with a colon in the segment, say "about:foo:bar". When parsed by the <URI> rule, it's (scheme: "about", path-rootless: "foo:bar"). But a reference from a base URI of "about:config" to reference "foo:bar" would not match entirely into the <relative-part> rule, as it is not a <path-noscheme>. Any URI with a <path-rootless> that contains colons will not match <path-noscheme>, and so will have this issue. I assume this is a known issue to people who work with URNs often. It seems harmless not to mention it, right?

I've removed the section about Relative URIs (ugh). Thanks for suggesting this and walking me through it.

It seems all that's left is text clarifying what is involved with reserving an about URI.
--
j