What registries might do (was: Consensus Call on Latin Sharp S and Greek Final Sigma)

Lisa Dusseault lisa.dusseault at gmail.com
Mon Nov 30 18:48:38 CET 2009

On Mon, Nov 30, 2009 at 7:20 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:

> But to be fair, the "registry completely restricts" policy won't work
> if ß is PVALID in IDNA2008.  Suppose .at by policy excludes (and
> doesn't map) ß.  What will happen then is that IDNA2003 clients will
> map ß to ss, and so a label ${example}ß.at will work for them; when
> the human on the other side of that client does its next upgrade,
> ${example}ß.at suddenly stops working.  This is the problem that
> opponents of making ß PVALID are talking about.

Instead of restriction, what if registries could be relied upon to
bundle a PVALID ß with 'ss' for a period?  If registries are required
or recommended to bundle ß with ss for a limited number of years,
before allowing those registrations to diverge, then browsers ought to
have a clear upgrade path: they can upgrade any time in that period of
years, knowing that as long as the domain with ß resolves then it is
not a change to deployed behavior.

There's still a nuance where possibly the registry has not yet
registered those ß as bundled with the equivalent ss domains, and I
can imagine two ways of doing this.  One would be to suggest a start
date for registries to respond to requests for ß domains with all the
appropriate ß/ss bundled domains, and that's the date when browsers
can start to upgrade behavior.  Another way would be for browsers to
look up ß first and fall back to mapping.

Lisa D

More information about the Idna-update mailing list