Re: My prod at IDN requirements

[Harald Tveit Alvestrand <Harald@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxx