Andrew Sullivan ajs at shinkuro.com
Wed Dec 2 22:29:21 CET 2009

On Wed, Dec 02, 2009 at 01:14:05PM -0800, Mark Davis ? wrote:
> The problem with bundling is that everyone has to do it, otherwise links
> don't work as expected.  The problem isn't limited to .DE, .AT, and .GR.

Fully agreed, although I'm uncomfortable with "expected" there.  The
early arguments (which you have, I concede, argued have no numbers
behind them) partly depended on the premise that mapping was bad
because it eliminated a number of cases that people wanted.  But leave
that aside.

> Schloß Schönbrunn - http://xn--schloss-schnbrunn-9zb.blogspot.com/
> Schloß Schönbrunn - http://xn--schlo-schnbrunn-uib90b.blogspot.com/ - not
> mapping ß
> Unless the registry maintained by blogspot also bundles, these will have the
> transition problem. And there are gazillions of registries: for
> example, Schönbrunn.de ( = xn--schnbrunn-27a.de) is the registry for:

Sure.  But let me push hard on that: so what?  If there's a real
problem here for users, then there will be pressure to develop some
kind of bundling.  Otherwise, there won't be, because people won't
care.  It seems to me that we have no real empirical evidence one way
or the other about this, but in the past cases where this sort of
ambiguity happened (ö/oe, colour/color, whatever) humans adapted and
figured it out.  What is troubling me about your argument that
something _has_ to be done is that it basically depends on the premise
that humans can't deal with this transition.  That seems to be
empirically false, because it seems we've examples where humans did
cope.  So why not allow the alternatives, suggest what we think would
work best, but let operators (who are lamentably absent from IETF
discussions by and large) work out how to handle the additional
diversity?  (I'm being intentionally hard about this in the above.  I
haven't made up my own mind, but I'm trying to push as hard as
possible so that we expose as many assumptions and premises as we


Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.

More information about the Idna-update mailing list