Hello John,
Thanks for your thoughts and proposals. Please see my comments (as one
of the document co-authors) in-line.
17.06.2011 19:49, John C Klensin wrote:
Given the controversies, I decided I needed to do a careful
reading of this document. While I respect and appreciate what
the authors are trying to do, as a would-be standards track
specification, it is pretty troubling.
I may agree here.
It is troubling
editorially as well.
And here as well.
I think all or most of the specific issues have been identified
by others, so let me try a different perspective and a 10 km
view.
(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.
Recommendation: Let's get it registered.
That's what we're trying to do. But see the paragraph before "Smaller
issues".
(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.
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.
Recommendation: Choose one of the following and redo the
document to match.
Option 1: Do this descriptively. Strip it down as much as
possible, more or less repeating the suggested language above.
If the Wikipedia article really contains a better and more
authoritative list of applications than the I-D text (and
especially if it is being kept up to date), just reference it as
a place where a non-normative listing and examples can be found.
The effect of doing this at all would be to reserve the name for
purposes internal to particular implementations of particular
applications, not unlike RFC 1918 addresses.
Option 2: Really try to make this normative wrt some subset of
URI values. In this approach, stop the extremely confusing
circling around. 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. 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.
Actually your Option 2 is what we were trying to do all the time.
However, considered a number of existing implementations, each one
having their own behavior with regard to about URIs, I actually don'
think is is possible. Option 1 seems to be much more realistic; in fact
what we had in -00
(http://tools.ietf.org/id/draft-holsten-about-uri-scheme-00.txt) seems
the best of any further version of the draft. -00 said that
"applications are free to resolve any about URI to any resource, either
internal or external, or redirect to an alternative URI, with
about:blank being the only exception". That's indeed better that what
we have in the -06. Currently, I even question me whether we need to
have an RFC published for the purpose of reservation of the scheme. The
situation is probably the same as with the view-source URIs. It was
ultimately registered with IANA upon a simple request whereas the
initial intent was to publish the Informational RFC (see
http://www.iana.org/assignments/uri-schemes/prov/view-source;
https://datatracker.ietf.org/doc/draft-yevstifeyev-view-source-uri/).
RFC 4395 intended the URI scheme registration to be lightweight -
template provided is everything you need. So we could just process this
registration in such way, as Permanent registration, without any
separate specification.
But, even the second approach is taken, 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.
----
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 to.
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.
(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.
(iii) I know this is partially a problem with the general URI
and IRI definitions, but I'm supposed to know something about
i18n and encoding and Section 4, Encoding Considerations, is
almost incomprehensible to me. It isn't quite clear what "this
syntax" refers to (if it is "the 'about' variation on the
general URI syntax described in Section 3", say that). Then I
think it says I may use any Unicode character, but I have to
%-encode it, but, if it isn't unreserved, it shouldn't be
%-encoded. If there isn't a clearer way to say that, I suggest
that almost anyone trying to figure out how to use this URI from
the spec is in trouble. And, fwiw, I've seen "about:" URIs that
use non-ASCII strings without %-encoding. Whether one calls
those IRIs, URIs, or pumpkins, I see absolutely no reason why an
implementation that knows it is UTF-8 capable (and clean) should
require that an xRI that is intended only for internal use
should require %-encoding of UTF-8 strings... especially since,
in practice, these URIs are often expected to be direct user
input.
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 Yevstifeyev
best,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf