Tonus (was: Re: Casefolding Sigma (was: Re: IDNAbis
vint at google.com
Thu Jan 31 13:32:45 CET 2008
Patrik is correct, Michael. The matching process IS destructive
because of the Unicode normalization rules that are applied to allow
for matching of the two kinds of sigma. If it were not for the fact
that the two kinds of sigma are supposed to match in the domain name
context, I suppose the difference could have been preserved.
Patrik, in the LDH world, the upper and lower case forms are kept in
the DNS database and are casefolded at matching time. In the IDN
world, in part because of the complexity of the normalization
process, is it correct that the design does a lot of the normalizing
at registration, storing the normalized form in the database rather
than the unnormalized form?
On Jan 31, 2008, at 6:57 AM, Patrik Fältström wrote:
> On 31 jan 2008, at 12.37, Michael Everson wrote:
>> Aren't we all in this together, Patrik?
> Of course we are!
>> Your answer here seems dismissive and aggressive. Whatever may be
>> stored in the DNS, an implementation of IDN may well need to
>> display Greek correctly and in a manner which meets reasonable
>> user expectations. None of us may put our heads in the sand over
>> this issue.
> And it is displayed correctly. IDNA2003 makes it perfectly possible
> to have a URI to a webpage that have the final sigma as part of the
> domain name, and with a preprocessing document that I thought we
> would see one day (based on the last couple of days of discussion)
> will make that same solution possible in the IDNA200x as well.
> What is NOT possible is to have something that contain final sigma,
> is normalized and casefolded according to the Unicode Consortium
> spec, keep the final sigma. This because the normalization
> +casefolding mechanism that is needed because of the matching on
> the server side is a destructive transformation.
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update