On 2011-06-22 06:39, Mykyta Yevstifeyev wrote:
(1) There seems to be consensus that registering this URI as a
mechanism for accessing built-in functionality and configuration
information such as application information, preferences, or
settings. (Text derived from the Abstract with "configuration
information", which may mean more to some readers, added and
"easter eggs" dropped. Dropping "easter eggs" reflects other
comments on the list and my opinion that it isn't worth the
trouble to define.
With regard to easter eggs I have no strong position. If it is
troubling, I don't object to remove any mention of them from the document.
The easter eggs are mentioned only in non-normative parts of the
document, including the abstract and examples, and just reflect the
reality of what some implementations use about URLs for. I do not
understand the objection.
(2) The document itself reflects an attempt to define the
undefinable. There is no cross-implementation interoperability
issue here; if anything, the document should me more clear that
it would be stupid to assume it. The document, nonetheless,
tries to define what is done with some specific URIs in some
places and then has to turn around and indicate that they may be
used in entirely different ways in other places and should not
be relied upon. In the process, it skips back and forth between
being descriptive and being normative, with some definitions
becoming circular in the process. That just isn't a good
combination and some of it actually looks pretty silly.
This feedback is not helpful, as it just vague hand waving and dismissive.
I may partly agree with you. Reading the document for a number of times
I've also noticed this. A logical conclusion of everything
aforementioned is below.
"about:blank" is particularly troubling in that regard because
the text essentially says that it is reserved except where it
isn't.
Nonsense. "about:blank" is clearly defined as reserved, and nowhere
does it indicate otherwise. Perhaps you are confused where it excludes
variations that include query strings?
Option 2: Really try to make this normative wrt some subset of
URI values. In this approach, stop the extremely confusing
circling around.
The circular definitions have been resolved in the editor's draft.
https://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-07.txt
Indicate explicitly that "about" URIs have been used enough and in
enough different circumstances that no application should assume
that an "about" URI, if encountered, is actually its own and that
due caution needs to be taken about non-conforming implementations.
That's the whole point of the unreserved category.
Then explicitly reserve, not only"about:blank", but everything the
authors think is worth listing in Examples _and_ create an IANA
registry for more of them.
No. The registry is a completely unnecessary bureaucratic mess that I'm
strongly fighting against, and will most likely be removing from a
future draft. Mykyta added mention of it to the draft* against my
wishes after I allowed him/her to become an editor even though (s)he has
still not been able to provide justification for why such a registry is
necessary. (However, I allowed the draft to be publicised with it for
public review and comment.)
* Note: That change hasn't been checked into github, and I don't know
if Mykyta has those changes somewhere public yet.
The purely informative value of a registry can and has already been
achieved by Wikipedia. The three known reserved about URIs (blank,
legacy-compat and scrdoc) are already documented, as are many other
unreserved, but recognised application-specific URIs.
Beyond that, the whole concept of reservation only exists to give other
specifications a clear way to define about URIs for their own purposes
and doesn't need any formal registration process. It doesn't have any
impact on any implementations that are not implementing the given
specification.
the document should be really clear that all that the use of
"about:" really tells someone is that it is application-specific
and that a particular implementation of a particular application
may do whatever it pleases with them.
It still says that, though the way it is written is a quite ambiguous
and convoluted and I understand the confusion here. I'll rephrase the
section on recognised URIs to address this.
Smaller issues:
(i) Section 6, Normalization, sadly really doesn't belong here
unless the authors can show that everyone interprets "about:"
according to those rules. Otherwise, it would be better to say
that the URI is interpreted in an implementation-specific way
and that implementations would be well-advised to conform to
normal URI syntax rules unless there is a strong reason not
Agree here. This thread restarted with the response to Boris's comment
regarding Gecko's normalization rules. This was to claim that no unified
rules for the scheme which is a priori used by the applications on their
own. As I proposed below, if no document is to be written, the template
may contain such statement about implementation-specific normalization
rules.
Yes, normalisation requirements will be removed.
(ii) IMO, Section 7, Security Considerations, should be modified
to include an explicit statement that, since these things are
intended for convenience use within an implementation of an
application, passing them between systems (embedded in files or
otherwise) is very risky behavior and should generally be
discouraged except, possibly, in documentation contexts.
I agree here.
...
Section 4 is what is also questionable. This issue was raised during
Last Call and I think can be resolved by saying that an about URIs may
contain UTF-8 encoded characters in the <segment>, as suggested by RFC
3986 and that's all.
Mykyta, feel free to revise sections 4 and 7 as you see fit.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf