CNAME, DNAME, NS, A

Kenneth Whistler kenw at sybase.com
Fri Feb 1 01:25:47 CET 2008


Erik,

> 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.

That is a guaranteed attribute of Unicode case folding. See:

http://www.unicode.org/policies/stability_policy.html

and scroll down to Case Folding Stability.

If we want to base IDN stability on case folding, and build
that case folding on the formal definition of Unicode case folding,
then yes, that also follows for IDNA.

> 
> 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).

Correct.

> Another solution is for IDNA200X to allow ZWNJ
> (U+200C) after a sigma and before another Greek character. (I can hear
> people groaning already.)

ZWNJ is a *cursive* joining control. When used in cursive
scripts, such as Arabic or Mongolian, it can break the
context required for joining a character to another, so
can be used to select presentation glyphs that would otherwise
be contextually inappropriate.

Greek is not a cursive script, and ZWNJ has never had anything
to do with selection of final or non-final forms for Greek
sigma. ZWNJ is *not* a final form variation selector.

ZWNJ can also be used to hint for break of ligature connections
in display. But, again, choice of final or non-final sigmas
in Greek has nothing to do with ligatures.

> 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.

Nor is it even a "solution" for the tonos. All that would
accomplish would be to disallow accented letters for Greek
in IDNs, which would put it at odds with all the other
scripts using diacritics.

> 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.

Nope.

The problem for Greek is the moral equivalent of the
following for French:

école.fr should (and will) match ÉCOLE.fr as IDNs.

But someone could come forward and say that for French
we leave off the accents on uppercase vowels. And
because of that:

école.fr should (but won't) match ECOLE.fr as IDNs.

Now this practice is no longer widespread for French,
but it used to be typical casing behavior in some
locales for some implementations.

Now ask yourself, would the "solution" for that problem
be to remove accented vowels from French domain names
in IDN? I don't think so. That's the quick road back
to ASCII.

--Ken




More information about the Idna-update mailing list