Browser IDN display policy: opinions sought

Tina Dam tinadam at
Mon Dec 12 23:28:05 CET 2011

Trying to catch up on the many emails on this topic.

2011/12/10 Patrik Fältström <patrik at>
> On 10 dec 2011, at 18:26, Paul Hoffman wrote:
> > D: Unicode if the label is a single script that is displayable by the browser, Punycode otherwise.
> +1
> With the exceptions for combinations of various scripts and script COMMON.
> Or in other words: If the domain name can be displayed as a U-label, in a technically safe way, why not display it as an U-label?


I agree with others that the three other options are not to be
desired. But since I don't see us reaching a 100% solution anytime
soon, so if I had to select between A, B, and C, I would select A.
The issues between the different options have been discussed at
lenght, so let me just say that the biggest problem I have with B is
that it leave it up to Firefox to decide what is a good/bad TLD
registry. I think that belongs elsewhere, namely with ICANN.

An additional couple of points as I have been reading through all the emails:

They reminds me a lot of the discussions we had during the IDN
Guidelines revisions. For example, as opposed to making a list of
scripts allowed to be mixed the rule is:

"All code points in a single label will be taken from the same script
as determined by the Unicode Standard Annex #24: Script Names
<>. Exceptions to this guideline
are permissible for languages with established orthographies and
conventions that require the commingled use of multiple scripts. Even
in the case of this exception, visually confusable characters from
different scripts will not be allowed to co-exist in a single set of
permissible code points unless a corresponding policy and character
table is clearly defined."

It also requires registries to submit to ICANN (for display) their IDN Tables.

So I would suggest that part of the inquiry to ICANN would be to
enforce compliance with the IDN Guidelines. This should at minimum
help to:

1) ensure TLD registries supporting IDNs do so in a responsible manner.

2) display in one place the languages and scripts that each registry
is supporting (I lost track but it was requested in one of the emails
on this topic).

I understand that there are linguistic requirements in the Guidelines
that are not within ICANN's area of expertise, and that it is a major
undertaking for the ICANN staff, but there still is the opportunity
for a relevant entity to be contracted with ICANN to do some/all of
this work.


More information about the Idna-update mailing list