Browser IDN display policy: opinions sought

Kent Karlsson kent.karlsson14 at telia.com
Tue Dec 13 12:49:39 CET 2011


Den 2011-12-13 11:19, skrev "Martin J. Dürst" <duerst at it.aoyama.ac.jp>:

> 
To take some very simple examples, why do I have to look at
> 
http://www.xn--viagnie-eya.com/ in Firefox when I can see
> 
http://www.viagénie.com in Chrome? The other way round, why do I have to
> 
look at http://xn--80abvnkf0a.xn--p1ai in Chome when I can see
> 
http://биатлон.рф in Firefox? (and why can I see both of these in Opera
> 
and in Safari?)

Again I feel I must reiterate that the very idea of using the punycode
version of a domain name as a kind of error/warning indication is
severely flawed.

1) Pure ASCII domain names cannot be warning/error indicated this way.
The coded version is the same as the "cleartext" version. There is no
reason to assume that just because a domain name is in pure ASCII that
it should not get any error/warning indication. Nor is there a reason to
think that *just because* a domain name isn't pure ASCII, it should be
subject to scrutiny that is not afforded to pure ASCII domain names.

2) Using the "punycoded" version of a domain name as some form of
error/warning indication was never a design point for that encoding.
It is purely a content transfer encoding, designed to be efficient
(short) and the encoded form to be (a subset of) pure ASCII. It is
strongly ill-suited as a error/warning indication. It rather indicates
that there is something wrong with the browser (whatever), especially
if other browsers (whatever) can display the "proper" name. (That
there are apparently punycoded domain names that cannot be decoded
without errors is a different matter.)

3) The kind of error/warning is in no way indicated by using the
punycoded version. Could it not be decoded? Does it mix scripts
inappropriately? Is it not in the "whitelist" (of some sort)?  Is it
(in part) in a "whole script" confusable script (with a script the
user has declared wishing to see)? Or what?

4) When the warning is misdirected (as in Martins examples above) it is
hard for the end user to get the decoded (plaintext) form. It is usually
not possible to easily toggle the display form. And cut&paste may be
even more flawed.

So please use another way of indication of this kind of problems that
is not thus flawed.

    /Kent K




More information about the Idna-update mailing list