Re: ACTION-103 Follow up on the about: scheme Registration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Joseph Holsten
The suggested text sounds fine, but I'm not sure I understand the  
expected behavior of reserved but unresolvable "about" URIs.

On Sep 18, 2009, at 8:12 AM, Lachlan Hunt wrote:
> The revised text I've suggested for section 5 is as follows: [...]
> 5.1 Reserved "about" URIs [...]
>   Other specifications MAY reserve additional "about" URIs.
>   Applications attempting to resolve reserved "about" URIs that are
>   not defined to be resolvable, MAY treat such URIs as being
>   unreserved.

Doesn't this defeat the purpose of reserving an unresolvable about  
URI? If applications can treat unresolvable "about" URIs (such as  
about:legacy-compat) as unreserved, what exactly is being reserved for  
them?
--
Joseph Holsten
http://josephholsten.com
mailto:[hidden email]
tel:+1-918-948-6747


Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Lachlan Hunt
Joseph A Holsten wrote:

> The suggested text sounds fine, but I'm not sure I understand the
> expected behavior of reserved but unresolvable "about" URIs.
>
> On Sep 18, 2009, at 8:12 AM, Lachlan Hunt wrote:
>> The revised text I've suggested for section 5 is as follows: [...]
>> 5.1 Reserved "about" URIs [...]
>> Other specifications MAY reserve additional "about" URIs.
>> Applications attempting to resolve reserved "about" URIs that are
>> not defined to be resolvable, MAY treat such URIs as being
>> unreserved.
>
> Doesn't this defeat the purpose of reserving an unresolvable about URI?
> If applications can treat unresolvable "about" URIs (such as
> about:legacy-compat) as unreserved, what exactly is being reserved for
> them?

(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?

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

Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Julian Reschke
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?

Best regards, Julian



Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Julian Reschke
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

Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Lachlan Hunt
Julian Reschke wrote:
> 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.

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/

Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

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

> Julian Reschke wrote:
>> 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.
>
> 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

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:[hidden email]
tel:+1-918-948-6747


Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Lachlan Hunt
Joseph Anthony Pasquale Holsten wrote:

> On Feb 8, 2010, at 3:40 PM, Lachlan Hunt wrote:
>> http://www.ietf.org/id/draft-holsten-about-uri-scheme-03.txt
>
> A quick diff suggests this is the same as what had been up in github, with
>   - s/recognize/recognise/
>     ...
> 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/

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Julian Reschke
Lachlan Hunt wrote:

> Joseph Anthony Pasquale Holsten wrote:
>> On Feb 8, 2010, at 3:40 PM, Lachlan Hunt wrote:
>>> http://www.ietf.org/id/draft-holsten-about-uri-scheme-03.txt
>>
>> A quick diff suggests this is the same as what had been up in github,
>> with
>>   - s/recognize/recognise/
>>     ...
>> 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/
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Graham Klyne-4
In reply to this post by Lachlan Hunt
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
--

Lachlan Hunt wrote:
> Joseph Anthony Pasquale Holsten wrote:
>> A quick diff suggests this is the same as what had been up in github,
>> with
>>   - s/recognize/recognise/

...

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



Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Lachlan Hunt
On 09.02.2010 11:19, Lachlan Hunt wrote:
> ...
>> Is that all that remains?
>
> 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



Reply | Threaded
Open this post in threaded view
|

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

Joseph Holsten
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
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
On 23.02.2010 10:08, Joseph Holsten wrote:

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

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

Reply | Threaded
Open this post in threaded view
|

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

Joseph Holsten

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

> On 23.02.2010 10:08, Joseph Holsten wrote:
>> 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."
>
> 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
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
On 23.02.2010 12:34, Joseph Holsten wrote:
> 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?

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

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

Reply | Threaded
Open this post in threaded view
|

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

Roy T. Fielding
In reply to this post by Joseph Holsten
On Feb 23, 2010, at 3:34 AM, Joseph Holsten wrote:
> 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:

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


Reply | Threaded
Open this post in threaded view
|

Re: ACTION-103 Follow up on the about: scheme Registration

Julian Reschke
In reply to this post by Lachlan Hunt
On 09.02.2010 11:19, Lachlan Hunt wrote:
> ...
>> Is that all that remains?
>
> I'm not aware of anything else.
> ...

Just checking...

- Do you need to submit a new draft? If yes, be any means, do so.

- Has an official review request been sent to the uri review mailing
list yet?

Best regards, Julian