Another Transition Plan Proposal

Shawn Steele Shawn.Steele at
Fri Dec 11 00:07:53 CET 2009

I think Gerv's suggestion is reasonable.  A couple comments:

Phase 1:  I think that in addition to the 5 key areas, that other zone operators should be encouraged to consider if this applies to them as well.

Phase 2:  Instead of "reporting" back.  I'd like to see something like "6 months after the RFC is published clients start to change their implementations."  My reasoning is that we'd have to form another group to decide if the reporting back worked or not and then do whatever came of that.  I want a clear period for the registries to adjust their policies, and then allow the clients to proceed, whether the registries are done or not.  I also don't want it to drag on for too long.  

Phase 3:  I think the registries you've mentioned aren't very interested in un-bundling the sharp s, so I don't think the conjecture is helpful, and is perhaps misleading.  I'm also wondering if this is even desirable?  Since the bundling is encouraged in Phase 1, mightn't it provide even more expectation that the bundling is permanent.  So maybe suggesting that bundling is no longer required, but registries are strongly encouraged to give the user's needs & expectations great thought before unbundling?


-----Original Message-----
From: idna-update-bounces at [mailto:idna-update-bounces at] On Behalf Of Vint Cerf
Sent: ???????, ???????? 10, ??? 2009 10:39
To: gerv at; idna-update at
Subject: Re: Another Transition Plan Proposal


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 schedules.

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
Idna-update mailing list
Idna-update at

More information about the Idna-update mailing list