Re: Last Call: <draft-klensin-idna-unicode-review-02.txt> (IDNA Review for New Unicode Versions) to Proposed Standard

["John R Levine" <[e-mail]>]

OK with me, with the obvious caveat that we're not very good at 
remembering when we said we would do something later.

On Thu, 8 Aug 2019, John C Klensin wrote:
> --On Wednesday, August 7, 2019 23:00 -0400 John R Levine
> <[e-mail]> 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
>
>
>

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly