--On Wednesday, August 7, 2019 23:00 -0400 John R Levine
<johnl@xxxxxxxxx> wrote:
>>> My one suggestion would be in sections 5 and 8 to tell IANA
>>> to remove the non-normative tables since you'll persuade
>>> people that not all IANA content is non-normative about the
>>> same time that you persuade people that not all RFCs are
>>> standards.
>>>
>>> Instead perhaps say that you hope to find workable ways to
>>> publish tools to create the tables that people can use as
>>> Unicode comes out with version 12.<n+1>. Then hand that over
>>> to the ongoing Github flame war since Github is the obvious
>>> place to put them. ...
>
> Thanks for the background. It was a suggestion, and if it
> would involve reopening old arguments I agree it's probably
> better to let sleeping dogs lie.
>
> This isn't the only situation where we have stuff that is
> authoritative but not normative and I certainly don't want to
> wait until that particular ocean is boiled.
Than let me borrow from the above and make a concrete (and I
think good engineering-type) proposal. This particular set of
tables, at least through Unicode 11 or 12, is an unusual
situation for historical reasons, because in one case (as Patrik
points out) the confusion actually helped us move forward
(although I hope the IAB is un-confused by now or that this I-D
helps), and for other reasons I hope my earlier note explained.
I can't immediately identify the other situations you refer to,
especially in IANA registries, but I have no trouble believing
your claim is true. I would assume that many or most of those
are special in some particular way too.
Because of the particular special circumstances here, let's move
this document ahead as is, partially to avoid reopening old
discussions _of this case_ and partially to run an experience in
whether clearer statements and better disclaimers make any
difference _in this case_. Let's plan, on the Unicode 13.0
timeframe, to do an evaluation of whether the changes in the
material that surrounds the tables are helpful in reducing the
confusion. It isn't immediately obvious to me how we would
measure that, but, especially if someone has a suggestion that
could be posted in I-D form, we could start thinking about that
right now without impact on this draft. If the conclusion is
that Unicode 13 is too close and a meaningful evaluation would
need an extra year, so be it: remembering the years we lost
between the discovery, with Unicode 7.0 and when we got the
tables related to 11.0 out and that, no matter how many people
were confused, the IDN world didn't end and noting that the IETF
apparently has more important things to deal with (using traffic
on the IETF list as a metric, the github war, errate processing
metrics, and the requirement for Jabber scribes seem like good
examples of higher priorities).
In the interim, if you or anyone else can come up with a
sufficiently good characterization of all or most of those
"authoritative but not normative" cases and suggested
improvements, I look forward to seeing a proposal, again in I-D
form.
Does that make sense?
best,
john
