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

Erik van der Poel erikv at
Thu Mar 5 19:21:40 CET 2009


Thank you for publicly posting DENIC's historical and current
positions on Eszett.

I don't know where this leaves us. John's "add lower-case mappings
only" suggestion and the more recent "try IDNA2008 first, then map a
la IDNA2003" suggestion give the impression that at least one member
of the WG appears to be willing to add some mappings to the base specs
(definitions, protocol, table, bidi and rationale), if I have
understood John's suggestions correctly.

DENIC's position on Eszett appears to be conditional. I.e. if the base
spec does not include mappings, you want Eszett under xn--, and if the
base spec includes some mappings, you want Eszett to be mapped to ss.

I do applaud your consideration of compatibility issues, but at the
same time, I wonder if we are currently at a point in time, relatively
early in the adoption of IDNA, where we can consider handling Eszett
in the way that you originally hoped (pre-2003).

I.e. Eszett and ss are two different things, users can input them both
and get two different results, and implementations can output
(display) them both, as distinct things.

So, as a working group, we can either decide to cling to the past,
following a simple plan that maintains strict compatibility with the
unfortunate choices we made earlier, or we can decide to solve the
Eszett problem once and for all, laying out a relatively complicated
plan for a transition.

Complicated plans are fraught with danger because it is very easy to
have misunderstandings or missteps.

However, now that we have a better understanding of client-side
mapping, perhaps we can consider a transition plan, and try to get as
many implementers on board as we can. One possible transition plan
would be:

(1) Get the clients to accept xn-- labels that contain Eszett
underneath. This includes being able to click on links that contain
such xn-- labels.

(2) Wait until most users are using such clients. During this period,
the clients can either continue to map Eszett to ss, or they can try
both (Eszett under xn--, and ss). I think I would prefer the mapping,
rather than the double lookup, from HTML URLs. But I don't mind double
lookup from the UI.

(3) When most users are using new clients, start using Eszett under
xn-- in DNS zones, URLs, etc. I.e. Eszett can be /registered/ under
xn-- in step (1), but cannot be /looked up/ until this step (3).


On Wed, Mar 4, 2009 at 1:26 PM, Marcos Sanz/Denic <sanz at> wrote:
> 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