Another Transition Plan Proposal

Vint Cerf vint at
Thu Dec 10 19:39:20 CET 2009


This is very similar to what I was going to try out on the WG. I am glad to
see someone else is thing along similar lines. I have some specifics to add
and perhaps some variation in detail. I hope to put this up tomorrow.

----- Original Message -----
From: idna-update-bounces at <idna-update-bounces at>
To: idna-update at <idna-update at>
Sent: Thu Dec 10 12:59:27 2009
Subject: Another Transition Plan Proposal

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. :-)

Idna-update mailing list
Idna-update at

More information about the Idna-update mailing list