Browser IDN display policy: opinions sought
jefsey at jefsey.com
Fri Dec 9 15:22:03 CET 2011
IMHO if we want to force everyone to be happy in the only way we
would want and use mandatory lists, we will make no one happy. IDNofA
as an architecture is broken: your questions demonstrate it: five
sister applications, at least 3 approximative different behaviours,
and possibly five different IP resolution.
The only stable solution is a single common IDNApplication because
there is a single common Internet DNS. This was not in our charter,
but this was Lisa Dussault's wished us to address once we agreed over
the WG/LC. Either the IAB eventually documents it, or we will
disseminate it. The point is in the "WITISWISISWIS" IDNApplications
requirement: what I type is what I see is what I send.
Please let us explain around that :
- there are 22500 language entities throught the world listed by the
FLOSS Linguasphere database.
- there will be billions of TLDs and trillions of IDNs supported by
IDv6 (IPv6 ID used on a global basis)
- the open code browsers will be forked to support IDNA transparent support.
Why not to just keep the browsers transparent and support your 3
buckets as a single option set (one can chose the default depending
on the local needs pattern). As they are I really fail to see how
each of these bucket can clearly and easily support plurilingual
users, multilingual applications or be used in an aerport or hotel cybercafe.
At 12:12 09/12/2011, Gervase Markham wrote:
>Recently, Mozilla community member Jothan Frakes was kind enough to do
>some research about how different popular web browsers implement IDN,
>and when they display the real characters and when they display
>Punycode. This is in the context of a Mozilla review of our policy. I am
>interested in the opinions of people on this list (see below).
>As it turns out, the behaviour of all popular browsers is summarised at
>the bottom a Chromium project document here:
>The policies fall into 3 approximate buckets:
>A (IE, Chrome): Unicode if the (single) 'language' of the string is
>configured in the options, Punycode otherwise.
>B (Firefox, Opera): Unicode if the TLD is in a whitelist, Punycode
>otherwise. Arbitrary script mixing permitted (registry policy used to
>C (Safari): Unicode if the script is in a whitelist (which by default
>does not include Cyrillic or Greek), Punycode otherwise. Not sure about
>Firefox has historically resisted adopting a Type A policy because we
>consider it seriously detrimental to IDN adoption and use. It seems to
>me that IDN can never be reliable for site owners, and therefore will
>not succceed, if a significant proportion of the world's browsers adopt
>Type A or Type C policies. This is because site owners can never know
>what proportion of their visitors will see gobbledegook in the URL bar
>rather than their nice domain name. Perhaps for sites whose visitors are
>all guaranteed to be from a particular country or language group, with
>properly-configured browsers and OSes which know that they speak a
>certain language or use a certain script, it might work - but I suggest
>that's a small subset of all sites. Many people in non-English-speaking
>countries still use English OSes and English browsers, with default
>Type C is particularly bad - Russian and Greek IDNs are broken by
>default, but even if you persuade your users to turn it on, they can
>then be mixed-script spoofed. You get to choose between functionality
>By contrast, with a Type B policy, if your IDN domain works in one copy
>of Firefox, it works in them all. If everyone had Type B policies, there
>would be no risk of a properly-registered domain coming up as gibberish.
>It has been suggested that Firefox switch to a Type A policy. As it is,
>the mix of policies means that the goal of universal acceptability is
>not being met anyway. Firefox switching to Type A would also not meet
>that goal by itself, but one could argue that there's a bit more
>consistency to browser behaviour.
>I would be interested in the opinion of people on this list as to:
>- whether my analysis seems reasonable;
>- whether they prefer type A, B or C; and
>- whether they see any particular policy as more damaging to IDN
> adoption than another.
>Has anyone lobbied one browser manufacturer or another to change their
>policy? Is there another option that is not currently in use which would
>(Note that "no restrictions" is not an option, given what happened in
>2005 with payp-cyrillic-a-l.com, and I would rather not derail this
>debate by rehearsing those arguments again.)
>Idna-update mailing list
>Idna-update at alvestrand.no
More information about the Idna-update