RE: Mississippi Hißes

John C Klensin klensin at
Sun Dec 13 21:17:55 CET 2009

--On Sunday, December 13, 2009 12:16 +0100 Alexander Mayrhofer
<alexander.mayrhofer at> wrote:

>> > That seems to be headed down a garden path that wouldn't 
>> really serve anybody well.
>> > So Stewart & Stevenson:
>> > would then automatically trigger the bundling of what? 
>> ß, sß, sß.com, and ßß.com? Does anybody
>> really  want to go there?
>> > What about some snake afficionadoes who decide to register 
> Even worse, bundling introduces a lot of side effects on
> registry processes, and make all those processes harder to
> understand for the registrant.
> For example:
> - what do you do when the registrant transfers one of the
> "bundled" domains to a different registrar?
>  - When he changes ownership of one of the bundled domains?
>  - When he
> re-delegates just one out of the 8 bundled domains?  Do you
> "block" the transaction until the registrant has applied the
> same transaction to those other domains as well?
>  - What do
> you do if the registrant cancels one domain out of the bundle? 
> - What if he doesn't pay for one of them? 
> (And that's the result of just 10 minutes of brainstorming...)
> Therefore, it makes sense for registries to avoid bundling at
> almost any cost, and hence and hißß.at should be
> two completely independent domains.
> Which is just possible if mapping "ß" to "ss" stops as soon
> as IDNA2008 gains major deployment. Otherwise, we'll never
> ever get rid of the "tainting".


The CJK-related domains that adopted the JET recommendations
(see RFC 3743 and, for Chinese, RFC 4713) figured out these
consequences some years ago.  So did registries for several
other TLDs that considered, or adopted, other forms of variant
bundling.  It is perhaps an oversimplification, but these are
prominent among the reasons why "sunrise" periods and
registration linkages* have been much more popular in practice
than long-term bundling.  There are circumstances in which
long-term bundling is worth it, but it is, as you point out, a
big development, operational, and management issue, so
registries need to be able to make their own decisions about
when it is important enough.


* "registration linkages" is used to describe all of those
techniques that involve checking whether a label that is somehow
related to one that is proposed to be registered is already
present.  If one is, then several things are possible including
rejecting the new registration proposal, trying to require and
validate a particular relationship between the existing
registrant and the new one, getting permission of the existing
registrant in some form, just notifying the existing registrant
so that dispute resolution procedures can be applied if desired,
etc.  The thing that all of those techniques have in common is
that the registry doesn't have to maintain a "name bundle"
status long-term and sort out the issues you identify (and a few
more) with respect to it.

More information about the Idna-update mailing list