Additional thoughts on TRANSITIONAL

Andrew Sullivan ajs at shinkuro.com
Thu Dec 3 22:16:45 CET 2009


On Thu, Dec 03, 2009 at 08:18:28PM +0100, Alexander Mayrhofer wrote:
> 
> I strive to adhere to the KISS principle - and even though that
> means that we might experience some failures during the transition
> period, i'd like to adhere to it in that case, and choose the first
> scenario (risking some failures, but keeping it as simple as it
> always was.)

I have two responses:

      1.  Those opposed to PVALID are arguing that there are two
      failures in the simplest case: it's not that it just breaks, but
      that it is ambiguous.  I find myself forced to recognize the
      serious security and user-experience arguments when I have to
      contemplate what it means for the "same typing" to resolve to
      two different addresses at the very same time on the same
      network, simply depending on whether one is using clientX 3.0 or
      clientX 4.0.  So we have to distinguish the "failures" and
      address each class separately.  TRANSITIONAL, for instance,
      would induce "can't reach" failure whereas PVALID would induce
      "ambiguity" failure.  Which (or all) are you willing to accept?

      2.  "Keeping it as simple as it always was" actually suggests
      that we leave the mapping as it was in IDNA2003.  But as I've
      already argued, what that "simplicity" entails is "simple for
      those for whom it's already working".  In other words, those who
      want the characters just lose, and it's not simple for them at
      all: they have a usability problem, because things are not as
      natural for them as they ought to be.  One can argue that it's
      just too bad (legitimately: the O'Sullivans of the world can't
      spell their names in DNS either), of course, but we've heard
      speakers of the affected languages suggesting that they really
      want these characters.  I'm loathe to dismiss that input.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.


More information about the Idna-update mailing list