Re: My prod at IDN requirements

[Harald Tveit Alvestrand <Harald@Alvestrand.no>]

At 12:05 04.01.00 +0900, Martin J. Duerst wrote:

> >    i18c Cyrillic A must compare not equal to Latin A
>
>Follows from consistent server behaviour and the fact that
>we don't want to require it to compare equal.
>May look like a serious practical problem, but won't, because
>DNS label components are words, not letters.

Is there then a requirement that all characters in a DNS label must relate 
to each other in some fashion?
How could we express this requirement?
Yes, I'm worried that someone will register <ASCII C> <Greek Omicron> 
<ASCII M>.

> >    i18c A with Ring Above must compare equal to a with ring above
> >    i18c A with Ring Above must compare not equal to a with ring above
>
>'must compare' is not clear enough. Is this for the user, or for
>a DNS server? I would say that for the user, it indeed must, but
>that that should be worded carefully so that it doesn't imply
>that it does on the server. Also, mention that case behaviour
>should be user-dependent (Turkish dotless i).

I was thinking of the server's deciding whether 2 names match or not in 
this case. And that (by the requirement for consistency) should not be 
locale dependent.

> >    i18c ASCII A must compare equal to a
>
>It already does :-(.

if explicit labelling of i18c names is chosen, we have the chance to 
revisit the question. So it's best to say what our requirements are....but 
I think the answer is obvious.



> >    i18c A + COMBINING RING ABOVE must compare equal to A with Ring Above
> >    i18c A + COMBINING RING ABOVE must not compare equal to A with Ring 
> Above
>
> >From the user perspective, there should be no difference anyway.
>On the server side, I wouldn't want to have to do all the work.
>The solution to this is probably early normalization, see e.g.
>http://www.w3.org/TR/WD-charreq#3 and 
>http://www.unicode.org/unicode/reports/tr15/.

this translates to a requirement for early normalization, based on 
considering implementation complexity.

We're moving!

                       Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no