From: Marcos Sanz/Denic <sanz@denic.de>
Date: Wed, Mar 4, 2009 at 13:26
Subject: Eszett again (was Re: Parsing the issues and finding a middle ground -- another attempt)
To: Erik van der Poel <erikv@google.com>
Cc: idna-update@alvestrand.no


Erik,

> I don't know
> whether the German registry will use DNAME for Eszett and whether they
> are happy with DNAME.

and I don't think this is actually relevant to the discussion. DNAME is
just a technical means of achieving something (e.g. bundling) that can be
done in many other ways (generating the same zone over and over, or
softlinking them all to a single one in the filesystem, or creating a view
in your relational database or...). FWIW at the moment we are not bundling
any IDNs at all and we have no DNAME RRs in our zone.


I had a private mail exchange recently with Mark on UTS#46 and he
encouraged me to post here (again) what our thoughts on the eszett are,
maybe with a different wording and a bit of historical perspective on top:

a) In the pre 2003 era, we wanted eszett to be a separate IDN character,
available for registration. Eszett and "ss" are just two different things.
b) We had to accept the roundtrip-case-conversion "rule" introduced with
IDNA 2003, though it was contrary to our preference. We have now got used
to live with it.
c) IDNA2003 is now well established and widespread. With a new version of
IDNA we would like and would expect the situation to be backwards
compatible with IDNA2003. That is, for all practical effects: eszett
*works* for the users and is mapped to ss.
d) The charter of IDNABIS says that mappings are to be eliminated from the
protocol (and that is the current draft situation), so the situation is
from the start not backwards-compatible anymore. Thus, either we have to
accept eszett as a character available for registration or start getting
used to the fact that eszett will not work anymore for users in domain
names. Yes, I know the current draft situation reflects the possibility of
local mappings on the user side that *could* map ß to "ss", but a strict
IDNA2008 implementation just does not have to. Room for havoc.

Breaking backwards compatibility is to my eyes the big stigma of IDNA2008.

So:

e) If mappings are to be removed from the standard, as we thought they
were, then we fall back to our pre 2003 position, that is: we would like ß
to be PVALID (and this is reflected by the current draft situation). Then
there is no havoc anymore, it is up to us as a registry to deal with
eszett, and we'll do it the right way.
f) But if there is room for negotiation and mappings could be (again) part
of the standard, then we would like eszett to be mapped to "ss" to ensure
backwards compatibility.

Hope that helps.

Best
Marcos
_______________________________________________
Idna-update mailing list
Idna-update@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update