RE: Standardizing on IDNA 2003 in the URL Standard

--On Wednesday, August 21, 2013 16:14 +0000 Shawn Steele
<Shawn.Steele@microsoft.com> wrote:

>> But I believe that it is. If there is a phishing problem in
>> any particular TLD due to this change, then I place the blame
>> for that squarely on the registry concerned.
> 
> Historically users blamed the browsers, not the registrars for
> things like the paypal-with-cyrillic-a homograph.

Shawn, you can generalize from that to "historically, users
blame either the software with which they directly interact or
their blame their first-hop ISP" without any loss of
information.  Taking the Eszett problem as an example, if a
registry decides to register a label containing an Eszett but
block a similar one containing an "ss" (a rational, but probably
not optimal, strategy by Mark's reasoning or mine), then the
complaints will be about inaccessibility from an IDDA2003 or
IDNA2008-with-UTR46-transition=on browser.  If they allow "ss"
but not Eszett, than someone using an IDNA2008 browser (with no
transition tools) will be happy but someone expecting "ss" to
just work will be unhappy with all browsers.

That situation of course has the potential to provide clear
feedback to registries, even though well down in the tree.  If
they sell or otherwise allocate and delegate names that often
don't "work", they are likely to have trouble with their own
customers and constituencies.  Whether it is better to have
browsers (and other UIs) lead or follow is not a simple question
(although I clearly have biases about the right answer).

This is ultimately a "lose either way" situation, a problem that
was reasonably well understood and accepted when the IDNABIS WG
made its decisions.  The question is where on the curve one
wants to fall and when.  That question has no easy answers
although it is clear to me that "IDNA2003 forever" isn't one of
the reasonable ones.

best,
   john

Received on Wednesday, 21 August 2013 16:39:49 UTC