Re: [I18ndir] text of conclusion

[John C Klensin <[e-mail]>]

Peter (and, ultimately, Alexey),

Perhaps others are in better shape, but I'm rather burned out at
this point and am sure my ability to think and write clearly
would benefit from a couple of days away from these document
drafts.   Without going back and looking, I'm guessing the
question about the cross-reference to 6.2 or 6.3 is a result of
our asking (even implicitly) Patrik to turn out drafts a bit too
fast, especially when he is in the middle of an ICANN meeting.
Many of Adam's nits in the tracker (see
https://datatracker.ietf.org/doc/draft-faltstrom-unicode11/ballot/
), especially references that are still in the document after
the citing text was removed, are symptoms of the same sorts of
problem.  Yesterday, Alissa indicated in the tracker that she
added a management item on tomorrow's IESG agenda to tell IANA
to post the tables.  Her note seems to suggest posting the
Unicode 11 table, with which I'm comfortable; were that to morph
into the Unicode 12 table, I think that would allow others
insufficient time for others to review it and it once again
punts the issue of review of the new code points.  Alissa's note
points to the 2018 IANA statement but, despite noting that the
IANA tables are not normative, that statement's claim of
"well-known failure modes which were demonstrated in the
deployment of IDNA 2003" appears to contradict that comment and,
given the IDNA2008 requirement for matching versions of Unicode
and derived properties in any given implementation or
application, substitutes one problem for another unless/until
IANA alters the registry to make tables available for every
Unicode version (or at least major version) from 5.2 to the
present (presumably 12.0) available.   Such a management action
also interacts with whether the RFC that descends from
draft-faltstrom-unicodeXX should, or should not, include the
appendices or at least the final appendix.

AFAICT, while, according to the tracker, Alexey hasn't taken the
vote on the agenda itself off tomorrow's agenda, he has recorded
a DISCUSS because of the new draft and the need for another IETF
LC (a statement I believe would be true even for unicode11-08
even if there were no unicode12-00/unicode11-09 draft around.
IIR IESG rules, a DISCUSS from the sponsoring AD, especially of
an individual submission. stops forward progress until it is
resolved.  Your note (and possibly others to come) indicate,
unsurprisingly, that the latter may need one more iteration.

Recommendation:

(1) The IESG should approve Alissa's management item and get the
Unicode 11.0 derived tables to, and posted by, IANA.  In part
because Unicode 11 and those tables have been around for a
while, I'm willing to live with largely skipping the new code
point review (also, ARAICT, skipped for 8.0, 9.0, and 10.0).
That should take the immediate pressure off IANA'x only posted
table version being over seven years old.    Note that because
of insufficient time to review and the new code point review
issue, an instruction to IANA to post the 12.0 tables at this
point would almost certainly result in an appeal, which would
presumably hold the IANA tables at 6.x until it was resolved and
would hence be counterproductive relative to getting the IANA
tables closer to current versions of Unicode.

(2) The IESG should do whatever it decides to do with the vote
tomorrow, as long as it is not to forward any of the three
relevant incarnations of the draft (unicode11-07, unicode11-08,
unicode12-0/unicode11-09 to the RFC Editor for publication.

(3) Almost contrary to my suggestion in my note to Alexey about
versioning, if we are agreed that the unicode12 draft, whatever
it is called, is going to need another iteration, another
possibility is that Patrik posts that version as unicode11-09,
superceding unicode12-00, and we just move on.  That should keep
things completely straight and cause zero pain or confusion.  Or
not, as long as everyone (including the tracker) is clear about
which draft is the current and active one going forward.

(4) We (the directorate) take at least the next 24 hours and
preferably the rest of the week off.

(5) Presumably somewhat refreshed and with clarity as to which
draft (and which draft name) we are working on, we proceed to
look at the paragraph you have identified and your suggestion,
other outstanding issues (include Adam's and Benjamin Kaduk's
lists from the tracker), and whatever else turns up after a more
relaxed review, to produce another document iteration that we
can actually recommend.  

(6) In parallel, we see if we can reach sufficient consensus on
the substance of what should be in the "future review plan"
document, including whether we want to improve the procedure for
new code point review or modify 5892 to eliminate that apparent
requirement, to make a recommendation about that and maybe get
started on such a draft.  We guess is that we are about 75%
agreed, so should get the details fleshed out and written down
(and ideally stronger consensus) before we forget.

(7) We also put together a recommendation to the IESG about
working with IANA to get tables for all relevant Unicode
versions up.   IF that requires an update to the IANA
Considerations sections of IDNA2008, we figure out how to get
that written.

We do all of (5)-(7) in the mode of a directorate trying to get
one or more documents sorted out, not with the constraints of a
team review on a particular version of a document.  

(8) I've got an incomplete idea about working with Asmus and the
"troublesome" list to efficiently put together a "new code
point" review for either 12.0 or 8.0 forward.  I'd be astonished
if we found anything, but it would be, IMO, worth doing the
review and posting a summary.   Details sometime (and to be
discussed with him before I make a more concrete proposal), but
not now.

(9) Because directorates generally don't submit I-Ds (given
comments made when this one was being put together, I imagine
any attempt to do that would cause a waste of time), both the
next version of draft-faltstrom-unicode11 and the "review plan"
document will need to be individual submissions (unless Alexey
wants to convene a WG) but I think, especially given the nice
words from several ADs in the tracker about the amount of work
that has been done in the last five weeks or so, those drafts
should explicitly recognize that they were the result of
directorate efforts.   That would also provide some protection
for Patrik if we have somehow botched things and send a message
to those watching that this is a consensus team effort.   I've
got some specific ideas about how to do that, but not today.

Does that make sense to others?
    john




--On Wednesday, March 13, 2019 11:25 -0600 Peter Saint-Andre
<[e-mail]> wrote:

> Looking again at Section 6 ("Conclusion") of
> draft-faltstrom-unicode12, I have a question:
> 
>    As described in Section 4 and Section 5, changes have been
> made to    Unicode between version 6.2.0 and 12.0.0.  Some
> changes to specific    characters changed their derived
> property value, while other changes    did not.  Given what is
> described in Section 3.3 and the changes    described,
> including implications to normalization, the conclusion of
> this document is to not add any exception rules to IDNA2008.
> 
>    This does not preclude any such updates to RFC 5892
> [RFC5892] or any    other IDNA2008 related document in the
> future when new versions of    the Unicode Standard is
> released, and it might also happen that it is    found the
> algorithm specified in IDNA2008 is not suitable for DNS
> without additional rules, categories, or tuning.
> 
> Depending on what we mean by "such updates", this could be
> read as implying that updates to RFC 5892 would happen only or
> primarily because of changes introduced in new versions of the
> Unicode Standard. However, although the issues described in
> draft-klensin-idna-5892upd-unicode70 might have been noticed
> because U+08A1 was introduced in Unicode 7.0.0, as we know
> they were lurking in the shadows all along.
> 
> (Also, should "6.2.0" be "6.3.0" in the first paragraph?)
> 
> Here is a suggested modification:
> 
>    As described in Section 4 and Section 5, changes have been
> made to    Unicode between version 6.3.0 and version 12.0.0.
> Some changes to    specific characters resulted in changes to
> their derived property    value for IDNA, whereas other
> changes did not.  Given the deployment    considerations
> described in Section 3.3 and the Unicode changes    described
> in Section 4 and Section 5, including implications for
> normalization, the conclusion of this document is to not add
> any    exception rules to IDNA2008.
> 
>    This document addresses only changes to Unicode between
> version 6.3.0    and version 12.0.0.  Changes in future
> Unicode versions might result    in the conclusion that
> exception rules need to be added to IDNA2008.    Separately
> from any changes in Unicode, the IETF might conclude that
> updates to RFC 5892 [RFC5892] or other IDNA2008 documents might
>    become necessary; such updates might include changes to the
> algorithm    specified in IDNA2008 as well as additional
> rules, categories, or    other forms of tuning.
> 
> Thoughts?
> 
> Peter