CNAME, DNAME, NS, A

[Erik van der Poel]

On Jan 31, 2008 12:53 PM, John C Klensin <klensin at jck.com> wrote:
> --On Thursday, 31 January, 2008 05:59 -0800 Erik van der Poel
> <erikv at google.com> wrote:
> > Since final sigma is mapped to sigma in the client software
> > *before* the name hits the DNS resolver, this mapping can be
> > done in pre-resolution client-side libraries. On the other
> > hand, letters with tonos are *not* mapped to their tonos-less
> > counterparts before DNS resolution, thereby forcing the
> > lower-level domains of the .GR TLD to deal with the issue,
> > either using DNAME or NS/A. This seems to me to essentially
> > push the problem from the pre-resolution library to the chain
> > of servers involved in an entire domain name lookup.
>
> Yes.  But as I explained in my note to Simon, and Patrik
> explained in his earlier note about where and how to do
> matching, unless we are going to do label comparison on the
> server at query time, a decision has to be made for each pair of
> characters as to whether they are "the same" or not and that
> decision has to be reflected in mappings that inherently lose
> information.  One has to choose somehow and live with the
> consequence of those choices.  As Simon points out, for these
> cases, the choices were made by a WG years ago.  We could, in
> principle, reverse them on a character-by-character basis now.
> But doing so would cause incompatibility and ambiguity (more
> difficult problems) unless we did a major protocol replacement
> and is hence very costly to think about.

So we are basically saying that once we start mapping one character to
another (as we did with final sigma in IDNA2003), we cannot stop
mapping that character to the other. Also, if a particular character
is permitted and we do not map it to another character (as we did with
letters with tonos in IDNA2003), then we cannot start mapping it to
another.

One solution for the sigma is to have the display software choose to
show the final sigma when it is at the end of a label (and perhaps
before a hyphen). Another solution is for IDNA200X to allow ZWNJ
(U+200C) after a sigma and before another Greek character. (I can hear
people groaning already.)

One solution for the tonos is to disallow letters with tonos in
IDNA200X. This may not be popular with all users of the Greek script.
I also don't know whether the participants of this mailing list feel
that this is one of those cases where we can move a character into the
NEVER category.

Erik