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

From: Donald Eastlake <[email-masked]>
Date: Sat, 3 Aug 2019 22:24:09 -0400

I have reviewed this draft and support its publication. It makes
reasonable and well motivated changes.

Thanks,
Donald

PS: typo: "also also'" -> "also"
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

On Fri, Aug 2, 2019 at 12:09 PM The IESG <[email-masked]> wrote:
>
>
> The IESG has received a request from an individual submitter to consider the
> following document: - 'IDNA Review for New Unicode Versions'
>   <draft-klensin-idna-unicode-review-02.txt> as 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
> [email-masked] mailing lists by 2019-08-30. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    The standards for Internationalized Domain Names in Applications
>    (IDNA) require a review of each new version of Unicode to determine
>    whether incompatibilities with prior version or other issues exist
>    and, where appropriate, to allow the IETF to decide on the trade-offs
>    between compatibility with prior IDNA versions and compatibility with
>    Unicode going forward.  That requirement, and its relationship to
>    tables maintained by IANA, has caused significant confusion in the
>    past.  This document makes adjustments to the review procedure based
>    on experience and updates IDNA, specifically RFC 5892, to reflect
>    those changes and clarify the various relationships involved.  It
>    also makes other minor adjustments to align that document with
>    experience.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-klensin-idna-unicode-review/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-klensin-idna-unicode-review/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Barry Leiba <[email-masked]>
Date: Sat, 3 Aug 2019 22:46:12 -0400

Thanks for the review, Donald; it’s much appreciated.

Barry

On Sat, Aug 3, 2019 at 10:24 PM Donald Eastlake <[email-masked]> wrote:

>  1424 Pro Shop Court
> <https://www.google.com/maps/search/1424+Pro+Shop+Court?entry=gmail&source=g>,
> Davenport, FL 33896 USA
>  [email-masked]
>

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2019 22:50:46 -0400

>>   <draft-klensin-idna-unicode-review-02.txt> as Proposed Standard

I took another look and I still think it's good, keeping in mind that I know
much less about the tortured history of IDNA and Unicode than jck and Patrik do.

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.

R's,
John

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 07 Aug 2019 10:59:10 +0200

> people that not all RFCs are standards.

Note that the original goal of the tables is to provide a central
place where a registry can provide information which chararcter
repetoire is supported.

This original idea is illustrated by the table for the TLD .at (one
TLD, one registry). The way it is organized now doesn't make a lot of
sense, especially since the qualification into script and languages
seems to be inconsistent.

There are likely legal requiremets that prevent removing the tables on
the moment.

	jaap

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2019 17:18:28 -0400

In article <[email-masked]> you write:
> > IANA content is normative about the same time that you persuade

I think we're talking about different tables.  The ones I suggest they
delete are in the parameter registry here:

https://www.iana.org/assignments/idna-tables-11.0.0/idna-tables-11.0.0.xhtml

The ones I believe you're talking about are over in the domain name registry
here:  

https://www.iana.org/domains/idn-tables

I agree that the latter are useful, even though they're incomplete,
often out of date, and some registries don't follow their own tables.

R's,
John

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 08 Aug 2019 00:03:09 +0200

"John Levine" writes:

 > I think we're talking about different tables.

Ah yes, we are. Thanks for clearing that up.

	jaap

 > The ones I suggest they

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Aug 2019 22:52:51 -0400

--On Tuesday, August 6, 2019 22:50 -0400 John Levine
<[email-masked]> wrote:

>>> The IESG has received a request from an individual submitter
>>> to consider the following document: - 'IDNA Review for New
>>> Unicode Versions' <draft-klensin-idna-unicode-review-02.txt>
>>>   as Proposed Standard
> 
> I took another look and I still think it's good, keeping in
> mind that I know much less about the tortured history of IDNA
> and Unicode than jck and Patrik do.

Thanks.  

> 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.

This was discussed during the period in which
draft-faltstrom-unicode11 was being developed and refined and
again when we were putting together this I-D, more or less as a
summary of those discussions.  My personal position on it is out
toward the radical end of the spectrum of opinions, that is, I'd
rather see the IANA tables gone.  Patrik can speak for himself
(copying him in case he is not following the IETF list these
days), but he has been more inclined to leave the IANA tables
there an attach disclaimers.  Possibly some of his reasons align
with mine below.

Despite my belief that the IANA tables have created confusion
and done more harm than good, I'm convinced that we should
transition out of them rather than dropping them abruptly.
First, while your analogy is interesting, I'm not sure that the
set of people who believe that all RFCs are standards and who
have not been deliberately misled is large enough to worry
about.  If you want to include the group that has been
deliberately misled, then the evidence of people who have been
convinced that I-Ds are standards (or other authoritative IETF
documents) suggests that we could have the same problem with a
repository somewhere else.  Second, the thing that propelled
draft-faltstrom-unicode11 and then draft-faltstrom-unicode12 and
the associated version was the IAB's conclusion that the tables
were important enough to give instructions to the Designated
Expert to get those tables out and essentially that they were
important enough to ignoring some outstanding issues.   I think
we are better off moving forward than reopening those questions,
and the way forward probably involves keeping the current
versions of the tables and improving the descriptions of what
they are rather than having the IETF repudiate those IAB
decisions.

A different way to say almost the same thing is that the actions
associated with draft-faltstrom-unicode11/12 involve an
assumption of IETF consensus the publish the tables with IANA.
Reversing that decision is likely to be controversial enough
that it would be better to just keep moving forward rather than
revising the recommendations in a new version of this document,
trying to resolve that controversy, and presumably going through
a second Last Call.  To me, I think there would need to be a
rather strong case for immediately removing those registries to
justify that amount of delay and level of effort.  I don't
believe your suggestion above makes that case.

As to github repositories with the tables, I have to admit
having given up on trying to follow what you describe as a flame
war, but I'd think that having the IETF start putting things
into github that are formally considered authoritative, even if
not normative, would put an entirely different spin on that set
of arguments.

best,
    john

---

From: "John R Levine" <[email-masked]>
Date: 7 Aug 2019 23:00:40 -0400

>> 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.

R's,
John

> not normative, would put an entirely different spin on that set

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

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 08 Aug 2019 07:33:21 +0200

On 8 Aug 2019, at 4:52, John C Klensin wrote:

> draft-faltstrom-unicode11 was being developed and refined and again when we were putting together this I-D, more or less as a summary of those discussions.  My personal position on it is out toward the radical end of the spectrum of opinions, that is, I'd rather see the IANA tables gone.  Patrik can speak for himself (copying him in case he is not following the IETF list these days), but he has been more inclined to leave the IANA tables there an attach disclaimers.  Possibly some of his reasons align with mine below.

The tables are also a bit confusing for even "insiders". People do not understand what "non-normative" means.

I am though as John said of the view that the IANA tables help, as I have seen people doing everything from copying them (and ask why not new ones exists) to diff the output from their tools with what IANA has.

Now with the new view that the derived property values should be fixed, and the algorithm change, I think the tables will be somewhere (the non-normative ones) and why not at IANA.

> Despite my belief that the IANA tables have created confusion and done more harm than good, I'm convinced that we should

Agree as you know.

> First, while your analogy is interesting, I'm not sure that the set of people who believe that all RFCs are standards and who have not been deliberately misled is large enough to worry
> deliberately misled, then the evidence of people who have been convinced that I-Ds are standards (or other authoritative IETF documents) suggests that we could have the same problem with a repository somewhere else.  Second, the thing that propelled draft-faltstrom-unicode11 and then draft-faltstrom-unicode12 and the associated version was the IAB's conclusion that the tables were important enough to give instructions to the Designated Expert to get those tables out and essentially that they were important enough to ignoring some outstanding issues.

This is one of my evidence that people do not get what non-normative means. Even IAB members felt the IANA tables where extremely important. I do think I misunderstood what the real issue was and....ultimately it did get the ball rolling again :-) So if there was a misunderstanding, it was a good one :-D

> I think we are better off moving forward than reopening those questions, and the way forward probably involves keeping the current
> versions of the tables and improving the descriptions of what they are rather than having the IETF repudiate those IAB
> decisions.
>
> A different way to say almost the same thing is that the actions associated with draft-faltstrom-unicode11/12 involve an
> Reversing that decision is likely to be controversial enough that it would be better to just keep moving forward rather than revising the recommendations in a new version of this document, trying to resolve that controversy, and presumably going through a second Last Call.  To me, I think there would need to be a rather strong case for immediately removing those registries to justify that amount of delay and level of effort.  I don't

Agree.

> having given up on trying to follow what you describe as a flame war, but I'd think that having the IETF start putting things into github that are formally considered authoritative, even if not normative, would put an entirely different spin on that set of arguments.

As long as we have the excellent staff at IANA we have, I do not see any difference between a pull request and IANA doing the updates when needed.

I do not want a wikipedia war.

To conclude, as long as we do not really know what the non-normative tables are used for, I rather have control over them than letting them completely loose, as I have no idea what could happen with them.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Aug 2019 08:34:51 -0400

--On Wednesday, August 7, 2019 23:00 -0400 John R Levine
<[email-masked]> 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.
>>> 
> 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

---

From: "John R Levine" <[email-masked]>
Date: 8 Aug 2019 09:49:20 -0400

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

Regards,