Paul,
We can get into the next level of detail if they turn out to be
needed, but let me try to respond at a fairly high level because,
despite your response to Victor, I'm not sure I fully understand what
you are concerned about. In no particular order...
(1) The ICANN work resulting from the Variant Information Project
dates from 2011 and Dennis Jennings' reports to the Board and
community in 2013. That work was discussed in the 2019 versions of
the document and prior to the former Last Call. Mentioning it seemed
to us (including in discussions of early versions of the I-D in the
late i18n directorate) to be likely to helpful to readers. In part
because the work based on that Project has advanced considerably in
the five years since the original Last Call, three types of changes
have been made to that discussion in the I-D:
(i) Provision has been made for a separate document that discusses
the body of that work and its various components with the intention
of using a stable reference in this document. I hope that separate
document (not necessarily an RFC) will include a table of specific
languages (or at least scripts) and associated specifications but it
should clearly be, as far as the IETF is concerned, a reference
rather that a set of requirements or normative recommendations. If
no one wants to go to the trouble of creating that document, that
would be, IMO, really sad but would change nothing substantive about
the I-D now under discussion. If you have reason to believe that
document will never be constructed and posted, please explain as I
would want to review the discussion of it in the I-D.
(ii) The remaining references have been brought up to date.
(iii) Text in the earlier version that appeared to make use of that
work a requirement has been removed, The work is now more clearly
treated as examples of second-level, more restrictive, rules that a
registry might consider for adoption or as a starting point for their
own rules. As a result, all of the associated references are now
Informative. Referring to Murray's note as well as my own
recollections and notes about the previous Last Call, if your concern
is that this I-D has added, or appears to add, requirements that go
beyond the core specifications, this version is less problematic than
the earlier one. We've tried to make the distinction between
requirements (even SHOULD-level ones) and discussion of possible
examples for examination and use clear. If it is not clear enough,
I'd welcome specific suggestions for improvements. FWIW, the
comments about the repertoire for the root zone are somewhat stronger
(closer to normative) than those for zones below because that is an
area in which ICANN clearly has authority to make and enforce rules.
If that distinction is objectionable or should be spelled out in more
detail, specific suggestions would, again, be welcome.
(2) The principle that IDNA2008 was a multl-layered system with a
broad, global, set of requirements and the expectation of more
restrictive requirements on a per-zone (or zone collection) basis has
been there all along even if your reading of the 2010 documents does
not show it. It was explicitly discussed and agreed to, not only in
the IETF community but in discussions with ICANN DNS registry-related
constituencies and Unicode Consortium leadership (it is even
reflected in the later UTS#46, which assumes choices on the part of
registration entities). ICANN, of course, endorsed it in the most
explicit of ways by creating a review committee for strings to be
allowed for ccTLD IDNs and later the entire MSR/LGR system. The
principle that registries are responsible for the decisions they make
is even older, going back to RFC 1591 and earlier. I've been told it
is also embedded in ICANN's relationship with Contracted Parties.
The latter is not a concern for the IETF, but, if correct, does
further reinforce the view that it is not something this I-D made up.
So I hope those topics are neither the history you claim we made up
nor a perceived new requirement on IDNA2008.
(3) The changes listed in Section 5 are based on errata filed against
the listed documents and processed normally. I believe it says
that; if that is not clear enough, I would welcome specific pointers
and suggestions. Other than those corrections, the I-D is about
clarification and updating of references. There are no other
intentional changes, vast or otherwise. Again, if you think there
actually are such changes that are "deceptively and woefully
understate[d]" please identify them so they can be discussed one by
one.
john
--On Monday, October 7, 2024 16:28 -0700 Paul Hoffman
<paul.hoffman@xxxxxxxx> wrote:
> On 7 Oct 2024, at 16:19, Viktor Dukhovni wrote:
>
>> On Mon, Oct 07, 2024 at 03:29:55PM -0700, Paul Hoffman wrote:
>>
>>> Section 5.1 woefully and deceptively understates the vast changes
>>> from RFC 5891.
>>
>> Paul, I am curious what specifically in Section 5.1 caught your
>> eye?
>
> The lack of listing the many other changes that
> draft-klensin-idna-rfc5891bis-07 makes to the implementation of RFC
> 5890. The same is true for Section 5.2. Someone looking at these
> sections might think that the rest of the material in the document
> was already in 5980/5981, which is isn't.
>
> Again, my preference would be for this IETF Last Call to, again,
> end with this draft not moving forward and leaving the existing
> standards as-is.
>
> --Paul Hoffman
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
