Subramanian,
Thanks, but...
That question was specifically intended for Peter and Stephane in
their capacities as having close relationships to ccTLD registries
that have some historical importance to this community and because
Stephane asked a question about, IIR, conformance or the lack thereof
by .FR. My doing so was not intended to say that ccTLDs were
special, nor (as noted in text you quoted below) to provide the
explanation, but to see if I could get their answers to calibrate the
impact of what the document suggests. While it may be useful for
others to perform the tests (vis-a-vis any DNS zone that accepts
IDNs, at any level of the tree), it has now been three weeks and the
test cases were intended specifically for their domains. I've heard
from one of them, off list, and had a constructive discussion that
led me to a new idea or two. I have not heard from the other.
Given your experiment, a partial explanation. Some of those examples
violate Unicode rules (and, btw, the rather liberal rules of
draft-bray-unichars). If they render properly, it might be a sign of
a bug in a browser somewhere, but it is not even clear what
"properly" would mean. All of those examples violate rules of
IDNA2008, even the original 2010 version. Other examples violate
current IDNA2008 requirements. At least one pushes the boundaries of
what should be allowed given some W3C discussions and documents.
Another subset might illustrate either differences between what is
reasonable in German and French or may illustrate differences between
what is allowed by those registries (and, in at least one or two
cases, necessary for the associated language) and what is allowed by
the corresponding ICANN 2nd level LGR.
What does this show? Given a sample of registries that is both very
small (two) and chosen by looking at two comments about particular
registries, perhaps nothing. On the other hand, AFAICT, both
registries are being thoughtful and at least reasonably conservative
about the names they allow, making them in conformance with IDNA2008,
the requirement there that registries do that, and the clarifications
and requirements of the current I-D.
It is not hard to identify registries that don't apply similar (or
any) standard of care, with an extreme example being one ccTLD
registry that allows (and actively promoted at one time and probably
still does) registration of labels containing code points not allowed
by IDNA2008. What, if anything, to do about that is an ICANN problem
and ICANN is still discussing what, if anything, should be done about
it seven years after the problem was clear. Again, not an IETF
problem without a direct line to the Protocol Police, but it seems to
be that we are required to be clear about what our standards do and
do not allow. In the latter context, the base IDNA2008 specs require
that registries (again, for zones at any level) apply a standard of
care that goes beyond the code point classifications and rules of
those specs. In that regard, all the current I-D does it to repeat
that, try to give examples of why it is important, and provide some
pointers if a registry concludes that some range of labels should be
acceptable in spite of their not having detailed knowledge of the
scripts or languages involved... pointing out, as IDNA2008 does, that
the optimal solution for most registries and high-quality identifiers
is to have precisely that knowledge and conservatively prohibit
everything else, but that they might have other considerations for
optimality.
As I implied above, I've now got some new ideas as to how to rewrite
parts of the document to possibly be more clear about the above and
possibly be less easily interpreted as criticizing, e.g., registry
business models. I don't know whether I/we should try that or not.
When this document came out of Last Call and IESG review in 2019,
there was, IIR, one DISCUSS comment that caused the IESG to send it
back asking for a new draft. In the time between then and sometime
in 2024, efforts to actually discuss the issue with the AD
responsible for the DISCUSS always failed for reasons that had
nothing to do with the content of the document (AFAICT, low priority
or just non-response). AFAICT, the two specific issues addressed by
that DISCUSS have long since been resolved; again AFAICT, nothing
came up in this IETF LC or IESG review that was equivalent to them.
So now we have a new set of reviews and comments, some of which
question, not the content of this document but the fundamental
strategy/methods of IDNA2008. Interestingly, questions were raised
in 2019 about the absence of one specific reference and about whether
the draft's claims that its suggestions had a long history. The
reference was added and the discussion of the history expanded, only
to have comments this time that suggest removing the reference and
most or all of the history (as well as raising new complaints).
There are probably other explanations, but those particular issues
are strongly suggestive of being run around in circles.
It seems to me as author that there are three possible ways to
interpret the current situation. One is that things have changed,
that a serious discussion is possible within a reasonable amount of
time, and that the document will then move forward. The second is
that the document will be approved only if it is completely stripped
of key content. Comments that appear to be requests (or demands) to
remove the history, remove all of Section 4, and probably just leave
the errata fixes in Section 5 are in that category. So are comments
that would involve relitigating parts of the IDNA2008 documents.
And the third possibility is that the IESG just doesn't like the idea
of this document and that any attempt to reconcile the DISCUSSes and
generate a corresponding document will just result in a repeat: no
way to get a serious discussion, long delays, changes of ADs and
roles, and, if a new document is generated, there would be a new Last
Call and new demands to remove material that was added as the result
of the previous round of discussions.
If either of the last two interpretations actually describes the
situation, then trying to move forward with the document -- even
getting further comments about it from you or others -- is a waste of
time. If those are the case, if we should be working on anything at
all in the IDNA space, perhaps it is deprecating IDNA2008 entirely or
at least removing some of its key requirements. I don't know how to
answer the question about moving forward without an answer from the
IESG that will start being seated in about a week and I don't even
know how to get that answer then. I am sure from the various Last
Call reviews that there are people in the community who would be
pleased if this I-D were dropped (or at least completely gutted) but
I don't know how much of this IESG, much less the next one, are
alighted with that position.
best,
john
--On Sunday, March 9, 2025 08:27 -0700 S Moonesamy
<sm+ietf@xxxxxxxxxxxx> wrote:
> Hi John,
> At 11:10 AM 05-03-2025, John C Klensin wrote:
>> Most of the above are from Latin script because they will be easier
>> for most IETF participants (possibly including the two of you) to
>> read and were easier for me to construct. Your answers may be
>> different for some of them. I will happily post an explanation of
>> each example after I get your responses or, if the IESG wanted
>> them, sooner.
>
> I copied the list into a web page to get a better view
> <https://www.elandsys.com/~sm/unicode-tmp.html>. I probably made a
> mistake for example (3) as it was not rendered correctly.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
