Another Transition Plan Proposal

Gervase Markham gerv at
Thu Dec 10 18:59:27 CET 2009

Simon and I have been discussing the proposed transition plans, and have 
a suggestion of our own. We apologise if this is similar to or the same 
as an existing proposal; it's been very hard to keep up with the volume.

We assume the decision is to make sharp-S and final-sigma PVALID.

Goals (like Mark):

1) Make the characters final-sigma and sharp-S usable ASAP.
2) Avoid as much as possible the situation where the same URL goes to 
two locations in two different clients.

and also:

3) Avoid client complexity, and multiple network round trips for lookup.

Current implementation (IDNA2003): is mapped by the client to, and then looked up.

Phase 1: registries in the five key areas (Germany, Switzerland, 
Austria, Greece and Cyprus) are requested to go through their 
registrations and create secondary registrations for all sharp-S and 
final-sigma variants, registered at no cost to the same registrants. (In 
other words, bundling.) Other registries are encouraged to do this also, 
but the plan only really depends on the cooperation of those five.

We understand that this group has no ability to force registries to do 
anything. However, Shawn has said .de and .at have already indicated 
intention to bundle, so hopefully this is the direction they would be 
going anyway. We strongly suspect that .gr and .cy would bundle, given 
the nature of the use of final-sigma. We would welcome feedback from the 
other registries on their plans.

We agree the TLD registries are not in control of all domain names, but 
we think publicity (which both we, the registries, and perhaps 
organizations with good stats about the distribution of such domain 
names can cooperate on) and leading by example will inform DNS admins in 
the affected language communities such that take-up is good.

Phase 2: After a set period, and once they report back that this is done 
(3 months? 6 months?), clients start to change their implementations. 
Instead of mapping B to ss and then looking up the ss form, they look up 
the B form directly. However, due to the bundling, all clients end up at 
the same website. There is no end-user impact except in the case of a 
registry choosing that there be end-user impact - and they can be 
responsible for the confusion which results if they do so. There is no 
flag day, and clients can make these changes based on existing release 

During this time, some clients map then look up, and others look up 
directly. But, one hopes, all clients end up at the same place.

Phase 3: once a sufficient percentage of clients are the updated ones, 
registries have the freedom to unbundle if they choose to do so and it's 
appropriate for their region's understanding of the meaning of the two 
alternatives for the character. (We anticipate this would never happen 
for final-sigma, but might happen in some areas for sharp-S.) Registries 
would be entirely responsible for any confusion which resulted from 
doing this.

It seems to us that there are two ways we can do this transition; by 
making the client more complicated, or by asking registries to cooperate 
in the interests of applying the Principle of Least Surprise to users. 
There have been proposals in the first category; this one is in the 
second. :-)


More information about the Idna-update mailing list