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. It is troubling
editorially 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.
Recommendation: Let's get it registered.
(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.
"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.
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.
(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.
(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.
best,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf