--On Thursday, March 12, 2015 19:05 +0900 "\"Martin J. Dürst\""
<duerst(_at_)it(_dot_)aoyama(_dot_)ac(_dot_)jp> wrote:
Here are some last call comments on
draft-ietf-appsawg-uri-scheme-reg-04. The review was started a
while ago, and completed, but the writeup took a lot of time
and is still not completed, sorry. I may be able to complete
it tomorrow, but please don't hold your breath.
[Just in case this is necessary, as a process point, I have
seen various tracker messages (such as the draft being placed
on telechat, or that the last call has ended), but I'd like to
note that the Last Call mentions an end date of 2015-03-12,
and it's still 2015-03-12 here in Japan, which means that this
date has barely started in some other locations around the
world.]
...
Hi. I had decided to just let this Last Call expire without
comment -- my IETF time in the last several weeks has been
completely taken up by other issues, notably URNBIS and i18n
(IDNA, LUCID, etc.) work on which I'm on the critical path.
However, with the last of those drafts posted, Martin's notes
and a few recent comments prompt a comment from a slightly
different perspective.
(1) First, several people have commented, directly or
indirectly, about the precision and clarity of the document. I
agree: it is less clear and precise than it should be. Clarity
and precision are especially important for a document that
specifies expert review because there is limited exposure and
broad community discussion of these documents. Registration
proposal review lists are not a substitute for the type of
review that occurs (or should occur) in IETF LC because people
with subject matter expertise associated with a particular
registration proposal are unlikely to on on those lists.
(2) The clarity and precision problem is particularly important
in this case because there are issues with the clarity and
precision of the underlying documents. Both the apps-discuss
and URN mailing lists (and associated WGs) have been treated to
long, and mostly, IMO, still unresolved, threads about what RFC
3986 actually means, specifies, recommends, or requires.
Regardless of the position one takes on those arguments, having
a document that is necessarily dependent on 3986 is problematic
unless they are adequately resolved for its purposes and should
be considered unacceptable if it substantially or completely
ignores those issues.
I note that there have been discussions in other forums,
including WHATWG, W3C, and private discussions among the latter
and relevant ADs, about drafts and proposals that are being
developed outside the IETF with the intention of superceding all
or part of 3986 in the relatively near future. Regardless of
the other effects of those efforts and how the IETF should
respond to them, work that is heavily dependent on practical
definitions (including definitions-by-practice (aka "running
code") as well as 3986) of URIs needs to be completely clear
about what it is specifying and expecting.
One example arises in passing in Martin's comment (an issue that
has also come up in URNBIS and elsewhere). 3986 parsing and
semantics are either normative or they are not (the current
working assumptions in URNBIS is that semantics need to be
excluded for URNs by amending 3986 for that purpose) and, again,
this document needs to be clear rather than glossing over the
issue and hoping things will work out "by default".
(3) Similarly, as soon as a URI-related specification starts to
discuss non-ASCII characters, it either needs to link itself
_very_ closely to 3986 or it inherently gets tangled up with
IRIs. In that area, there is a Proposed Standard (RFC 3987).
There was an effort to update 3987 in the IETF that identified a
number of (IMO important) issues but that was unsuccessful in
resolving then, leading to the effort collapsing. As with 3986,
there are now efforts going on outside the IETF to revise or
reinterpret the IRI spec and/or to simply fold IRIs and URIs
together. Under other circumstances, that situation might
result in a "health warning" applicability statement about 3987,
but there apparently hasn't been energy to create and debate
such a thing. It seems to me that we could have an
interesting debate about whether 3986 applies (i.e., no
non-ASCII characters except via %-encoded UTF-8), some broader
statement about IRIs should be made, or some other direction
taken, but that is is not acceptable to not be clear about the
options for whatever is being registered.
(4) Finally, this Last Call identifies a procedural issue with
APPSAEG in particular and perhaps some other Area WGs. The
applications area, and hence AppsAWG, span a very broad
collection of topic areas (a situation that will certainly
become worse with the upcoming reorganization and
consolidation). Most participants are active in other WGs (to
which they may have primary commitments) and few have the time
and expertise to dig deeply into every topic the WG chooses to
take up. I favor such WGs as a way to discussion Area-wide
topics and to help strike a balance between the overhead of
traditional WGs that have highly constrained and topic-specific
charters and the use of AD-sponsored individual submissions for
immature or controversial drafts. But because of their breadth
and the difficulty of assuming that there is a significant
number of WG participants who are expert about and examining
each specification in careful and appropriately skeptical way,
automatic use of two-week IETF Last Calls from the output of
such groups may not be consistent with fairness.
john