Another Transition Plan Proposal
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
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): wieB.com is mapped by the client to
> weiss.com, 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 (http://www.switch.ch/;
http://www.nic.ch/) 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
> 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 alvestrand.no
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
More information about the Idna-update