registrant <-> user

[Erik van der Poel]

Forgive me for posting another IDea, without writing an ID.

We have been talking about bundling on the server side, as one of a
number of different transition strategies. This bundling strategy
allows clients to use either the IDNA2003 rules or the IDNA2008 rules
to convert to an xn-- name and look up the IP address and other info
from the registrant.

We have also been talking about a display preference that allows the
registrant to tell the client how to display the domain name. More
generally, we can imagine a registrant saying "Hello, welcome to my
home. You have arrived via one of my older IDNA20XX domain names. In
the future, please use the name xxx.yyy."

This is somewhat analogous to the HTTP 301 Moved Permanently redirect.

So how about a special prefix xu-- that is intended to be used in "the
other direction", i.e. from registrant to user. This prefix, when used
in CNAME, DNAME or some other future *NAME, would basically tell the
client "Please decode the following Punycode and then try converting
the resulting Unicode back to Punycode using the rule sets that you
know of, such as IDNA2003, IDNA2008 and IDNA2013. If one of the
A-labels you end up with is the same as the one that you used to look
me up, you can use the Unicode string for display. However, if the
matching A-label is from an old version of IDNA, please try to get
your source data fixed. If the Unicode string contains a character
that you do not yet know about, or if none of your computed A-labels
is the one you used to look me up, this means that you need to upgrade
to the latest version of IDNA and also get your source data fixed."

The basic idea is that IDNA would be updated a number of times, until
we have stopped adding characters like the Chillu. I.e. clients would
always first look up with their latest version of IDNA, falling back
to successively older versions of IDNA until the lookup succeeds or
none of the IDNA versions worked. The registries and lower-level zones
would be expected to bundle the related names until they have stopped
receiving lookups with the old names. The long-term steady state that
we would hope to reach is one where this type of bundling is no longer
necessary because all clients have the latest version of IDNA, there
are no longer any old xn-- names stored in files such as HTML, and
clients are able to use only the latest version of IDNA, never falling
back to older versions.

This strategy can be used to move to Chillu in Malayalam, to map
tonos-ful characters to tonos-free ones, to register distinct Eszett
and ss names (eventually), to start using contextual geresh/gershayim,
and so on.

For example, let's suppose that we decided to map tonos-ful characters
to tonos-free ones in IDNA2013, but the client is still at IDNA2008.
Let's also suppose that the client's U-label has tonos on some of the
characters, but not on the registrant's preferred characters. Then the
DNS server would return a *NAME with an xu-- label containing the
desired tonos placements. The client would convert the Punycode to
Unicode and then convert that Unicode string back to Punycode using
IDNA2003 and IDNA2008 rules. Neither of these A-labels would match the
one that the client used to look up the original name, so the client
can deduce that it is using an old IDNA version and should probably be
careful about displaying the Unicode string, or display a warning.

Note that this time, I am not suggesting a new prefix because of
MSIE7. This time, the new prefix is specifically being suggested as a
way of overloading the meaning of CNAME, DNAME and *NAME.

By the way, the xu-- prefix is just a playful choice where the u is an
upside-down n that signifies that xu-- labels and xn-- labels are
intended to be used in opposite directions (registrant <-> user).

The reason for recommending the display of the decoded Unicode string
only when one of the computed A-labels is matched is because the user
might copy and paste the Unicode string to another app on the device,
which is somewhat likely to be using the same versions of IDNA,
perhaps due to a common library.

Finally, this is just an idea at the moment, and I have not worked out
the details, so there may be some problems.

Erik