--On Wednesday, April 18, 2012 13:57 -0700 The IESG
<iesg-secretary(_at_)ietf(_dot_)org> wrote:
The IESG has received a request from the Applications Area
Working Group WG (appsawg) to consider the following document:
- 'The "about" URI Scheme'
<draft-ietf-appsawg-about-uri-scheme-04.txt> as a Proposed
Standard
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send
substantive comments to the ietf(_at_)ietf(_dot_)org mailing lists by
2012-05-02. Exceptionally, comments may be sent to
iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Hi.
I've expressed more detailed concerns on the WG list or earlier,
but, since those seem to have been in the WG rough, two very
general comments:
(1) It is not clear that this document benefits from a
historical review but, if the authors choose to provide one, it
should be accurate. For example, the second paragraph of the
Introduction says:
The concept of "about" URIs formed when applications did not
have a "friendly" user interface, to enable access to the
aforementioned resources by typing URIs into an address bar or
similar feature.
There were applications with user-friendly interfaces to
configuration long before there were URIs, so certainly the
above statement cannot be true as written. My recollection is
that "about:" came into being because the development team for a
particular early browser was unwilling or unable (given
resources and other constraints) to spend the time developing
what they would have considered an appropriate UI for options
they did not expect to be used extensively, but that is rather
different. And, fwiw, that actual history puts the origins of
"about:" into a category that is often described with language
like "quick hack", although that doesn't prevent standardizing
just as other quick hacks of that period have been recognized in
standards when they were shown to have lasting value.
(2) This document is being proposed for Standards Track, but it
is not clear what is being standardized. Certainly it registers
and reserves the scheme name "about", which I think it a good
idea (and agree with the authors that it is overdue). But, as a
particularly interesting example, the IANA Template says "see
Section 2.2" for "URI scheme semantics", but Section 2.2 doesn't
actually specify anything. That is clear from its first couple
of paragraphs which start "Generally speaking..." and "However,
it is impossible to specify a binding...".
Even the special token material is questionable. Certainly we
recognize "about:blank", but it is not clear from the text that
we really have enough understanding of other things that might
be registered to have any idea whether the specifications for
the new registry and the registration template are adequate.
Perhaps that is the result of trying to generalize from one
case, perhaps it is more broadly symptomatic. As an example,
the paragraph under the figure in Section 4.2 contains the
interesting phrasing "The registrant of the token ought to
provide...". Is "ought to" a synonym for SHOULD and, if so,
shouldn't the specification contain guidance for IANA as to when
they are to make a registration entry even when that information
is not provided? Or does it mean something else entirely and,
if so, what? I also note that, in general, we ask that
information that is required (or even optional) for registration
go into the registry but this one expects that material to
appear in separate documentation with very little in the
registry itself. I'm sure there are registries and
registrations out there that provides contact or authority
information only by indirection through other documents
(documents that are not required to be standards track RFCs or
otherwise meeting our requirements for normative references) but
they are rare and, IMO, undesirable.
Recommendation:
Before this specification is adopted as a Proposed Standard, it
should be absolutely clear what is standardized, what is general
advice, and what is just commentary. Hand waving like "ought
to" should be removed in terms of 2119-style requirements
statements is requirements are intended or clarified
sufficiently to give IANA clear guidance on content and
operation of a registry. That is especially important for an
FCFS registration spec where, in principle, only IANA evaluates
a request for conformance to the specification before modifying
the registry.
The setup for the token registry reflects the debates about
registration conventions that have waged since this document was
first proposed. However, it seems to go both ways in that
debate. On the one hand, it singles out a single keyword,
"blank", for registration. It indicates that there can be more
but that they should/will be rare. It does not encourage
registration of other keywords to lower the risk of different
applications using a given keyword for different purposes. And
I can't find any actionable criteria for when something should
be registered and when doing so is assumed to be not worth the
effort. Our old principle of conflict-reduction would argue for
trying to get all keywords registered even if they were used
only in a single implementation. If the criterion is actually
"it is common knowledge that this is used by almost everyone and
used in the same way", then it is not clear what value is added
by creating a registry. IMO, the document needs to be much more
clear about those issues and what it intends. Once it is, we
can have a meaningful discussion about consensus on those
points. As it stands today, a claim of consensus would need to
be based on the assumption that, somehow, everyone understands
what is expected to be done about registration of additional
tokens. I just don't believe that is true.
Finally the historical descriptions should either be cleaned up
or removed.
best,
john