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.
Thanks,
Lisa D
More information about the Idna-update
mailing list