Eszett and IDNAv2 vs IDNA2008

[Erik van der Poel]

On Thu, Mar 12, 2009 at 7:25 PM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> On Thu, Mar 12, 2009 at 03:34:03PM -0700, Erik van der Poel wrote:
>> What about using CNAME with xd-- like this:
>>
>> ;; QUESTION SECTION:
>> ;www.strasse.de.   IN  A
>>
>> ;; ANSWER SECTION:
>> www.strasse.de.  0 IN  CNAME www.xd--strae-oqa.de.
>> www.xd--strae-oqa.de.  300 IN  A 78.47.200.154
>
> Well, actually, I'd use DNAME (because it redirects what's underneath
> it -- you still have to deal with the record at the same RNAME.

I suppose DNAME would work too. I'm under the impression that DNAME is
newer than CNAME, and that CNAME therefore has better support. My
chief concern would be to use something that is likely to survive the
trip from the source to the destination (client). But maybe they are
both well-supported now, and DNAME has other advantages, such as
redirecting everything underneath it.

Anyway, it seems like CNAME and/or DNAME would be better than using NS
in the authority section. It seems like they would also be better than
reverse DNS, which would require two lookups, and would be slower.

> But
> modulo the new "xd--" prefix, you've just arrived at the "bundling"
> proposal that many people seem to think will have to be good enough
> for IDNA2008/IDNA2003 transition.  All you do is establish what other
> records would have matched under IDNA2003 that won't under 2008, and
> include them as a policy matter in the zone you're operating, making
> sure they all go to the same place.  No new prefix needed.

Yes, it's interesting how this discussion has almost arrived at the
bundling proposal being suggested for IDNA2008. There are a couple of
important differences, however. If people start putting names like
xn--strae-oqa in CNAME/DNAME records, they are bound to "leak" out of
the DNS system and find their way into HTML files, where they would
cause interoperability problems, as I have explained so many times.
(MSIE7 does not let users click through links containing xn-- names
that cannot be the result of an IDNA2003 transformation.) This is one
of the reasons why I would prefer a new prefix that does not cause
such problems. (The other reason is that xd-- is a clear signal to the
client that it should try converting the underlying Unicode string via
a careful subset of the IDNA2003 rules and then comparing that with
the name on the left-hand side of the CNAME/DNAME.)

The other important difference is that since ZWJ and ZWNJ are "mapped
to nothing" (deleted), we no longer need to come up with complicated
contextual rules for them.

This does not mean that IDN display software would be simple. Far from
it. We'd still have to deal with all of the spoofing issues
(look-alikes).

>> xd-- tells the client to do something special at display time. So does
>> xn--. If xn-- gets to have special treatment, why can't xd--?
>
> Briefly, the NS record has a well-defined semantics, and anything that
> fiddles with that is, in my opinion, pretty dangerous.

Yes, I have given up on the authority section idea.

Erik