Subject: [I18nrp] Conservatism principle doesn't go far enough

From: Larry Masinter <[email-masked]>
Date: Thu, 31 Jan 2019 16:17:34 -0800

https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_di
splay_guidelines/url_display_guidelines.md

is interesting; one wouldn't want to register a domain which a popular
browser / OS won't display.

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Jan 2019 20:01:21 -0500

--On Thursday, January 31, 2019 16:17 -0800 Larry Masinter
<[email-masked]> wrote:

> https://chromium.googlesource.com/chromium/src/+/master/docs/s
> ecurity/url_di splay_guidelines/url_display_guidelines.md

> is interesting; one wouldn't want to register a domain which a
> popular browser / OS won't display.

Larry,

I can't speak for those who would want to do that or why.
However, I note that any application that conforms to IDNA2008
is required to reject and not look up any string that contains
code points that are DISALLOWED by that spec.  The standard is
silent on how "reject" is expressed through the UI (IIR,
deliberately), but the specification is quite clear.  And yet,
surveys in ICANN-land have have shown SLD registrations for many
such labels.

The interesting question is what should be done about it.  As
far as I know, the division of the protocol police that was to
be responsible for name syntax enforcement was never established
and chartered, the IETF does not have a role in determining what
is registered in practice, ICANN has been completely ineffective
in enforcing even its own guidelines and contractual rules for
behavior outside the root, etc. Judging from the numbers and
some advertising, a good number of registrants are convinced
that domain names can be treated as trophies or art objects that
can be obtained and held and either admired or eventually sold
speculatively without any need to consider actual usability.
Others seem to believe it is appropriate (and potentially
profitable) to obtain names that may not be handled consistently
by different applications and whose sole purpose is to confuse
people and take advantage of the confusion.  Again, I don't know
what, if anything, can or should be done about that, but I'm
fairly confident that effective fixes do not lie within the
IETF's authority.

    best,
     john

---

From: "John Levine" <[email-masked]>
Date: 31 Jan 2019 21:18:01 -0500

>> popular browser / OS won't display.

I am reasonbly sure that and domain you could register today in an
ICANN contracted TLD would be OK with Chrome.  You can put non-OK
subdomains under an OK 2LD, but I can't see what registries or
registrars can do about that, particularly when they're not hosting
the domains' DNS.

>surveys in ICANN-land have have shown SLD registrations for many

Funny you should mention that.  I went through and looked at all of
the IDNs in every contracted TLD zone file.  There's about 2 million,
half in .COM, half in other TLDs.  I checked for IDNA2003 and 2008
compliance, and I also parsed the per-TLD script rules at IANA and
checked whether the names match the rules.

I was pleasntly surprised to find that over 99% of the names are valid
under IDNA2008 and match one of the script rules for the TLD.  Of the
maybe 5000 that aren't, the biggest single group are ancient names in
.COM and .NET registered a decade or longer ago before there were
script rules, and that contain stupid stuff like currency symbols and
other punctuation.  I did some spot checks and could not find any that
were in use other than maybe pointing to a parked or for-sale web
page, so really, who cares?

Some of the new TLDs are just lazy.  They have to tell ICANN what
scripts they'll allow, and send the script rules to IANA.  Most do,
it's not hard, but a few can't be bothered. I found some TLDs with
names in scripts not on their list (Chinese mostly), and some with
scripts on their lists but not at IANA.  Nearly all of the rogue
Chinese names would be fine if the TLDs published the same Chinese
script tables as other gTLDs, so they seem lazy, not malicious, at
least in their choice of names.  ICANN agrees these are compliance
issues and I'm arranging to give them a feed of violators.

The ccTLDs of countries big enough to matter seem OK.  I can't get
many zone files but of the few I can get, .US has no IDNs, .se and .nu
(managed by .se) are squeaky clean, and a few small African countries
that allow public AXFR have no IDNs in their tiny zones.

There are a few bad actors like .WS and .LA who have sold their TLDs
to speculators whose registration rules primarily involve checking
that the charge went through.  There are emoji 2LDs in .la and .ws,
but given how few names there are in those TLDs that anyone cares
about, overblocking would be appropriate.

I'll be giving a talk on Two Million IDNs and What I Found at ICANN
Tech Day in Kobe in March.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Jan 2019 21:46:23 -0500

(top post)

John,

Understood and we have, of course, been through some of these
numbers in a different context.  But Larry's assertion, at least
as I understood it, was a little different and asserted that one
would not want to register a domain name that wouldn't be
displayed properly by a major browser).  For that assertion, the
"non-contracted parties" count.   If one goes back a few years,
so would the FQDNs whose IDN components were displayed by a few
popular browsers as A-labels because the TLDs involved did not
meet the criteria of those browsers for reputation checks.  If
Larry has said "only an idiot who did not care whether a name
was consistently usable or not would register a domain name that
would not be displayed by a popular browser or OS", then we
could have a conversation (that some might find interesting)
about the size of the world's population of idiots.   But that
isn't what he said or at least not what I understood him to be
saying.  

So I don't disagree with your analysis or numbers, I just think
we are addressing different issues.

    john

--On Thursday, January 31, 2019 21:18 -0500 John Levine
<[email-masked]> wrote:

>>> https://chromium.googlesource.com/chromium/src/+/master/docs
>>> /s ecurity/url_di splay_guidelines/url_display_guidelines.md
>> 
>>> is interesting; one wouldn't want to register a domain which
>>> a popular browser / OS won't display.
> 
> I am reasonbly sure that and domain you could register today
> in an ICANN contracted TLD would be OK with Chrome.  You can
> put non-OK subdomains under an OK 2LD, but I can't see what
> registries or registrars can do about that, particularly when
> they're not hosting the domains' DNS.
> 
>> surveys in ICANN-land have have shown SLD registrations for
>> many such labels.
> 
> Funny you should mention that.  I went through and looked at
> all of the IDNs in every contracted TLD zone file.  There's
> about 2 million, half in .COM, half in other TLDs.  I checked
> for IDNA2003 and 2008 compliance, and I also parsed the
> per-TLD script rules at IANA and checked whether the names
> match the rules.
> 
> I was pleasntly surprised to find that over 99% of the names
> are valid under IDNA2008 and match one of the script rules for
> the TLD.  Of the maybe 5000 that aren't, the biggest single
> group are ancient names in .COM and .NET registered a decade
> or longer ago before there were script rules, and that contain
> stupid stuff like currency symbols and other punctuation.  I
> did some spot checks and could not find any that were in use
> other than maybe pointing to a parked or for-sale web page, so
> really, who cares?
> 
> Some of the new TLDs are just lazy.  They have to tell ICANN
> what scripts they'll allow, and send the script rules to IANA.
> Most do, it's not hard, but a few can't be bothered. I found
> some TLDs with names in scripts not on their list (Chinese
> mostly), and some with scripts on their lists but not at IANA.
> Nearly all of the rogue Chinese names would be fine if the
> TLDs published the same Chinese script tables as other gTLDs,
> so they seem lazy, not malicious, at least in their choice of
> names.  ICANN agrees these are compliance issues and I'm
> arranging to give them a feed of violators.
> 
> The ccTLDs of countries big enough to matter seem OK.  I can't
> get many zone files but of the few I can get, .US has no IDNs,
> .se and .nu (managed by .se) are squeaky clean, and a few
> small African countries that allow public AXFR have no IDNs in
> their tiny zones.
> 
> There are a few bad actors like .WS and .LA who have sold
> their TLDs to speculators whose registration rules primarily
> involve checking that the charge went through.  There are
> emoji 2LDs in .la and .ws, but given how few names there are
> in those TLDs that anyone cares about, overblocking would be
> appropriate.
> 
> I'll be giving a talk on Two Million IDNs and What I Found at
> ICANN Tech Day in Kobe in March.
> 
> R's,
> John

---

From: "John R Levine" <[email-masked]>
Date: 31 Jan 2019 21:54:03 -0500

> "non-contracted parties" count.

Oh, no disagreement there.  I hardly need to tell you that the 
relationship between some ccTLDs and ICANN (and in some cases, everyone 
else) can be fraught.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Fri, 01 Feb 2019 00:08:45 -0500

--On Thursday, January 31, 2019 21:54 -0500 John R Levine
<[email-masked]> wrote:

>> numbers in a different context.  But Larry's assertion, at
>> least as I understood it, was a little different and asserted
>> that one would not want to register a domain name that
>> wouldn't be displayed properly by a major browser).  For that
>> assertion, the "non-contracted parties" count.
> 
> relationship between some ccTLDs and ICANN (and in some cases,
> everyone else) can be fraught.

I spent a bit of time with alternate parsings of that sentence,
because it would be nearly as accurate (or perhaps not even
"nearly") to say that ICANN's relationship with [almost]
everyone else can be fraught.  

In the unlikely event it wasn't clear, my other intended message
to Larry was that trying to put IETF into the middle of those
situations would not be a good idea... and not only because it
would be unlikely to be productive.

best,
    john