Stephane,
First, I agree with all of Brian's comments and thank him for them.
I will try to address a largely separate set of issues (including one
or two raised by others after your note was posted) below...
--On Friday, February 14, 2025 09:14 +0100 Stephane Bortzmeyer
<bortzmeyer=40nic.fr@xxxxxxxxxxxxxx> wrote:
> On Thu, Feb 06, 2025 at 01:32:22PM -0800,
> The IESG <iesg-secretary@xxxxxxxx> wrote
> a message of 38 lines which said:
>
>> The IESG has received a request from an individual submitter to
>> consider the following document: - 'Internationalized Domain Names
>> in Applications (IDNA): Registry
>> Restrictions and Recommendations'
>> <draft-klensin-idna-rfc5891bis-09.txt> as Proposed Standard
>
> Summary: there are big problems with this draft. It should not be
> published as-is.
>
> The biggest one is the fact that it spends most time criticizing the
> business model of some domain name registries than talking about
> internationalized domain names (sections 1 and 4, things like "in a
> zone in which the revenues are derived exclusively, or almost
> exclusively, from selling or reserving (including "blocking") as
> many names as possible"). IETF typically does not talk about
> business models of Internet actors (otherwise, many RFC would have
> to be expanded…) and specially in derogatory terms. All these
> rants about registries being for-profit or not should be removed,
> it is irrelevant for IDNA. Nostalgic references to RFC 1591 are not
> really useful.
Let me try again to explain the situation that motivated this
document. I, Asmus, and several others have struggled with how to
make these things clear; if, after reading what follows, you have
good suggestions about how to improve the text consistent with the
explanation below, they would be very welcome.
When IDNA2008 was under development, people from the domain name
industry (IIR, not commonly called that yet), and ICANN in
particular, were very actively involved in the process (one might
even say "taking lead roles in driving the process). They, and
others involved, understood that, while a collection of global rules
based on categorizing of code points and relationships among them was
critically important and necessary to defining IDNs -- IDNs that were
usable and effective as identifiers-- they were not going to be
sufficient. Instead, those categories and rules were necessarily
just one layer in sets of rules that would likely differ depending,
for example, on language groups, or even locales, served by
particular zone or domain subtrees. Those discussions and the
related design reflected another recognition: even if the IETF had
the expertise and energy, it would be inappropriate for us to start
dividing domains up into categories with some rules for some and
other rules for others. Instead, with the possible exception of the
root zone, IETF protocol work had to apply to the entire DNS, top to
bottom and (however one looks at the tree) right to left or left to
right. Even without the help of the Protocol Police or other
sanctions, the assumption of IDNA2008 was that the rules would apply
equally to top-level domains (in today's language, contracted,
country-code, or special) and to domains four or five or more levels
down in any of those trees... and, in each case, to the
administrators and decision-makers for those domains. The latter are
referred to in the IDNA (and other) documents as "registries" in the
same sense that IANA uses the term. In other words the term
"registry" is simply about the policy-making, administrative, and
record-keeping function of each zone, not any special meaning it
might have in ICANN-land or elsewhere (if that is not clear enough in
the I-D, I would welcome proposed text to fix it).
The rest of that understanding was that, while intermediate layers of
rules would be entirely appropriate, the ultimate responsibility for
rules about what names could be placed in which zones had to lie with
the registry (in the sense above) for each zone. I ask your patience
in going through what follows even if you know it all already -- some
of the comments seem to indicate that some people don't.
Some years after IDNA2008 was published, ICANN recognized the
importance of that intermediate layer and launched the Variant
Information Project (VIP), which led to the MSR specification, LGRs
for various languages, and recommendations about second level domain
name labels (and possibly beyond). However, the notion that
registries (again in the sense above) would have to bear final
responsibility and should make appropriate rules didn't change, if
only because that ICANN work is, at most, only about recommendations
at the top and second level ... and those recommendations are
considerably weaker for other than Contracted Parties. Those
recommendations may, nonetheless, be a good starting point for zones
elsewhere in the tree, and this I-D says that.
As to "Nostalgic references to RFC 1591", those references will
become irrelevant (not just nostalgic) after the IETF identifies that
document as historic _and_ ICANN stops citing it and treating it as a
fundamental source of their authority. Even if it stopped citing it
in the context of Contracted Parties (which I don't think has
happened yet), there are multiple citations to the role and authority
with ccTLDs and special domains.
> Also, IETF RFC do not set policies for registries (for instance,
> this is why RFC 954 on whois was replaced by RFC 3912) so sentences
> like "actually be treated as requirements" should be deleted.
It is not clear to me why you think WHOIS (or RDAP, etc.) have
anything to do with this. Again, if you can suggest better language
that does not depart from the point, I'm anxious to hear it. But
this document is not intended to tell registries what to do beyond
the degree to which any IETF protocol spec tells implementers or
others what to do: not only are there no Protocol Police, but they
don't have an IDNA enforcement division. It isn't setting, or trying
to set, policies for registries (especially in the ICANN sense rather
than the sense used in this document) either. What it is saying is
that the rules and structure of RFCs 5891, 5892, and, where
applicable, 5893, were never intended to be the last word on the
subject but that they simply describe the least restrictive layer of
a multi-layer system, with more language-specific or zone-specific
restrictions being necessary to a well-functioning DNS that includes
domain names that are interpreted as non-ASCII and that the final
responsibility for the set of rules and restrictions appropriate to a
particular zone rest with the registry (again in the sense above -- I
can't repeat that too often given repeated confusion about it) for
that zone. Is that setting policy for registries? No more than,
e.g., RFC 3986 sets policy for web browsers.
It also makes some recommendations as to how registries who make
decisions, probably policy decisions, to register labels they don't
fully understand wrt script, writing system, or locale implications
might reasonably proceed. We've said in the current IDNA2008 specs
say (although maybe not clearly enough) that they SHOULD have that
level of understanding and apply it. But, if they have reasons
(policy or otherwise) for not doing so, the document provides advice
about where they might reasonably look for alternatives and/or
advice. It is hard for me to believe that providing such advice is
not reasonable and appropriate. It is not that they are breaking
some sort of rule and we are telling them how to better do break it;
it is very close to what I believe is the BCP 14 intended meaning of
SHOULD, i.e., that reasonable implementations or operations may have
reasons to make exceptions.
I think that brings us to the question of why this document is needed
given that we have had IDNA2008 for 15 years and it is working fine.
The short, and IDNA2008-specific, answer is that those who were
involved in the writing of IDNA2008 thought that it was clear that
final responsibility for determining what names should go into a
particular zone rested with the registry for that zone and that
whatever each one of those registries decided should be consistent
with the letter and spirit of IDNA2008 (including that layered
restriction part). Subsequent experience strongly suggests that it
was not clear enough and hence that an updating document that focused
on those issues was entirely appropriate. Interestingly, even some
of the reviews of this document since its publication was first
proposed reinforce the belief that it was not clear enough.
The "15 year" part of that argument is particularly sensitive for me
personally because, if we should not be updating or revising specs
that have mostly worked, and worked reasonably well for 15 years, I
don't know what the EMAILCORE WG (and myself as editor of one or two
of its documents) are doing working on revisions to RFCs 5321 and
5322. Those specs are not only in their 17th year but, while they
are considerably more clear and precise, they are actually not very
different in important and substantive ways from RFCs 2821 and 2822,
which are in their 24th.
> Another serious issue is that, while it refers to RFC 9499 on domain
> name and DNS terminology, it creates new definitions (section 4)
> which are quite vague and do not seem useful for IDNA. I've read the
> beginning of section 4 with the definitions of "zones operating
> primarily" and I still don't know where .fr would fit, for
> instance. The mention of "public domains" is specially confusing.
> (RFC 9499, section 9, has the proper definitions, which should be
> used.)
Part of the problem is that this document addresses issues, for the
reasons above, that did not appear to be under consideration when RFC
9499 was written and hence different language was required. I'll
take another look at this, but do not believe you are correct that
there is any inconsistency. While it did seem appropriate to cite
RFC 9499 and try to use its terminology where possible, if the
community concludes that it would be better for the document to
explain why it should fork from RFC 9499 and define the unusual
terminology it uses locally, that could certainly be done.
As far as, e.g., .FR is concerned, if the IDNs that they/you are
registering are based on languages that are familiar enough to the
registry that they can, and do, avoid registering strings as labels
that they don't understand and that might raise issues, then they are
fully compliant with this spec (and with the IDNA2008 base specs).
If, on the day that a new version of Unicode appears that contains
characters needed for writing Lower Slobbovian and there is no one in
France who writes or speaks that language (likely since it is made
up) and no LGR for Lower Slobbovian (even more likely for the same
reason) but the .FR registry races to be first in line to register
Lower Slobbovian labels... Well, someone should consider calling the
Protocol Police. And, for the record, I cannot imagine the .FR
registry, especially with your input, being that irresponsible or
stupid but, if you tell me I'm wrong, I'd probably believe you.
> And the last important problem is that it mentions vague risks
> ("most dangerous and otherwise problematic cases", "obscure
> characters", this last one bordering on western-centricism) without
> a threat analysis. Homograph attacks are as cool in security
> conferences (and are a sure way to make english-speaking people
> laugh) as they are rare in the wild. (Most users do not check the
> domain names and even if they do, they typically don't spot the
> difference between
> secure-bank.example and secure.bank.example; the security issue is
> not in IDN.) The [Gabrilovich2002] reference is a poor two-page
> document that speaks only about theoretical possibilities, not
> about actual attacks observed.
First, I share your discomfort about treating the homograph cases are
if they were the critical ones. But, IIR, an earlier version of this
draft was criticized (IIR, including by an AD or Area/Directorate
review) for leaving it out and that didn't seem to be a fight worth
having. More important, I agree about your secure-bank.example. I
would also agree if you had cited micr0s0ft.com, which I believe I've
seen in the wild (typically in upper case). Now, we don't spend time
worrying about those all-ASCII cases, but they, and the comparison to
IDN homegraphs and other issues, were discussed extensively in the
work leading to IDNA2008. To move to a completely non-western
example, it is reasonable to expect someone who is familiar with
Latin script to recognize the difference between F00.EXAMPLE and
FOO.EXAMPLE (even if we know that some users will be tricked).
However, it is not as reasonable to expect someone whose primary
reading and correspondence is in Han Script to be able to spot a
similar issue in Devanagari or Arabic script. Maybe they will, but
the implication of that difference is that, by allowing IDNs, we are
creating a risk that did not exist to nearly the same degree with
all-ASCII domain names and therefore have some obligation to try to
mitigate that risk.
Conversely, an argument that we (the IETF) or zone registries have no
obligation to be concerned about those risks and don't need to worry
about those cases for IDNs is ultimately an argument that we don't
need (and should never have standardized) IDNA2008 or PRECIS beyond
"use Unicode" and should not have draft-bray-unichars in Last Call,
because all of them, in different ways, address the problems of
arbitrary, unrestricted, strings of Unicode code points. As to
"obscure characters", I was (or we were, but I may be to blame)
thinking in terms of characters from scripts that no one has used for
a couple of millennia or longer except in specific scholarly
contexts, not characters that are in wide (or even not-so-wide) use
in today's world. If you can suggest better terminology, I am,
again, listening.
john
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
