Eszett again (was Re: Parsing the issues and finding a middle ground -- another attempt)

Marcos Sanz/Denic sanz at denic.de
Wed Mar 4 22:26:10 CET 2009


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


More information about the Idna-update mailing list