Mappings - some examples

[Andrew Sullivan]

On Mon, Nov 30, 2009 at 10:01:26AM -0800, Mark Davis ? wrote:

> (and not a compatibility scheme like http://unicode.org/reports/tr46/). The
> only real purpose to allowing ß is so that you can distinguish from ss. But
> what happens when Herr Stosser gets stosser.at and Herr Stoßer gets
> stoßer.at <http://stosser.at>?

I am uneasy with that premise.  It might be that the real purpose to
allowing ß is so that people can write labels in a way that seems most
natural to them.  People who want to write such labels might
nevertheless be willing to assent to the claim that an alternative
(perhaps less-natural) spelling would be ok, or that for some period
of transition (possibly indefinitely long) it would be better if the
two labels "be the same", where that unpacks to "a domain name
containing the ß-form label, and another domain name containing the
ss-form label, are kept together as the same name as far as resolution
behaviour goes."  Or something equally laboriously stated.  I hope I
make myself clear.

Now, if this state of affairs were to be true, then I think your claim
that the only "real purpose" is not quite right, and also the problem
you have identified does not happen.  Right?

> in their web pages or in email until essentially all existing browsers were
> supplanted, which will be maybe 5 years down the line. 

So if there were a recommendation for how to make this transition over
(say) 10 years, would that change your opinion of what the right thing
to do is?  

It seems to me that you are arguing at base that, because there is
ample opportunity for confusion and difficulty right now, that we need
to make a particular policy decision (ß maps to ss) a permanent part
of the protocol itself.  Yet your example contains a case where Herr
Stosser and Her Stoßer are different people, with different spellings
of their names.  So competent speakers of the language are able to
make the distinction, and the fundamental problem here is that they've
adapted themselves to their technology.  As the technology changes,
their behaviour might too.  

It's not as though we don't have this problem in simple-minded ways
today.  For instance, color and colour are different strings, and will
be different DNS labels.  There is no policy in .com -- or even .ca --
to guarantee that the target of labels under color.com is the same as
the target of labels under colour.com.  (Indeed, in both .com and .ca,
if whois is reliable, the registrants are different.  In Canadian
spelling, note, depending on which dictionary you follow they are just
alternative spellings of one another.)

> like http://unicode.org/reports/tr46/; that allows the browsers, emailers,
> search engines and others to keep functioning correctly - there is no
> transition.

I'm pretty uncomfortable here with the claim that things will "keep
functioning correctly" under this sort of compatibility mechanism.
What you really mean is that they'll continue to function the way that
works for some people (i.e. the installed base).  There's always a
trade-off here, because of course when we break compatibility with a
previous system, we necessarily hurt those relying on the particular
features of that system.  But it's not like this is being broken just
for the fun of it: people complained that the historical functionality
does not allow them to do something they want to do.  So this is not a
matter of which is "correct", but which is, on the whole, better over
the long term, accepting that whatever happens, someone has to pay.

When this work started, I accepted the argument that certain backwards
incompatible changes would need to be made in order to achieve what
seemed like a good goal: to provide a more-locally-sensitive
experience for those whose natural language isn't written using just
ASCII.  As near as I can tell, your argument is that the gain for ß
and ς just isn't worth the risk, and therefore backward compatibility
with IDNA2003 should be maintained at all costs.  Is that a fair
assessment?  If so, does it commit you to the position that, if the
IETF gets any internationalization work wrong in the future, we'll
have to live forever with the consequences anyway, because changing
just can't be done?

Best regards,

Andrew

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