Another Transition Plan Proposal

"Martin J. Dürst" duerst at
Fri Dec 11 10:13:09 CET 2009

Hello Gerv, others,

I'm summarizing my opinions on this thread in this mail. In general, I 
agree with most of what has been said.

On 2009/12/11 2:59, Gervase Markham wrote:
> 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.

I think this is really important. Earlier proposals were way too 

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

I have no idea about what the Swiss registry (; thinks, but my guess would be that this should be 
optional for them. First, there must be a fair number of French or 
Italian based labels registered; for those, ß would just be a joke. 
Also, there's no tradition in Switzerland to use the ß, and therefore 
essentially no market. So I would strongly encourage them to look into 
this issue, but that's about as far as I would go.

On the other hand, I would definitely include registries that are 
affected by ZWJ and ZWNJ.

I would also support what Cary has said, on leaving the exact details to 
the involved registries. Some may decide to go ahead and bundle without 
even asking the registrants. Some may decide to inform the registrants 
and giving them an opt-out option. Some may ask back and give an opt-in 
option. In some cases, it would be cost-neutral to registrants (highly 
desirable), in others, it might not be cost-neutral. Some registry may 
prefer to use a mixture of approaches (e.g. different approaches for 
sigma in final position vs. sigma in the middle of a label, potentially 
at the end of a word).

What I think is also very important is that this be documented in an RFC 
(most possibly BCP). This is very helpful to raise awareness, and to 
document consensus. Ideally, the authors would be some people from the 
client side (browsers, search engines,...) and some people from the 
registry side, but if you need some help, I'd be willing to also give it 
a try (over the holidays). This BCP would essentially say:

Clients, with respect to the 4 characters in question:
- MUST not move to IDNA 2008 before date X.
- SHOULD move to IDNA 2008 after date X as fast as possible.

Registries, with respect to the 4 characters in question:
- MUST evaluate the potential that their customers and/or third parties 
have relied on the mapping (/removal) behavior of IDNA 2003.
- If there is such a potential, offer their customers bundling or a 
sunrise or whatever to assure that domain names in actual current use 
that work under IDNA 2003 work when used with an application that uses 
IDNA 2008.

Regards,   Martin.

> 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. :-)
> Gerv
> _______________________________________________
> Idna-update mailing list
> Idna-update at

#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-#   mailto:duerst at

More information about the Idna-update mailing list