[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My prod at IDN requirements
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