From: Simon Josefsson (email@example.com)
Date: Wed Jan 26 2005 - 17:31:51 CST
"Michael \(michka\) Kaplan" <firstname.lastname@example.org> writes:
> The problem was that the test implementation matched the intention and was
> clear (being an implementation!) but the spec was ambiguous on a particular
> Punishing people who looked at the test implementation, and changing the
> intention of the UAX, just to satisfy the people who read the spec but not
> the code and came to the "wrong conclusion" (50/50 chasnce!) is not a good
> plan -- which is why there was a corrigendum.
There is deployed code and standards that use the old interpretation.
StringPrep, and IDN, will continue to use the old interpretation,
until they are updated to reference this update. There are no draft
documents on that, as far as I know.
I would say that pushing this change forward will punish StringPrep
and IDN, since then those specifications, and consequently an
implementation, which is my concern, will have to deal with this
I'd wish that this was only about punishing people that came to the
"wrong conclusion". I believe the previous situation was perfectly
clear, even if that situation is problematic, in that the introduction
text and example code were buggy. It seems to me that one problematic
situation is solved by creating other problems.
> Coming along now when the corrigendum is being made part of the UAX, and
> proposing to back out of the plan already agreed upon seems like n even less
> good idea.
> This was extensively debated with people from the W3C and the IETF at the
> time of the corrigendum. Probably we should not revisit it again, given the
Perhaps it is too late, but the current public review issue is about
modifying TR15, and it is that modification that I comment.
Perhaps my delusion is that having a public review period imply a
possibility of revisiting the proposal.
> MichKa [MS]
> NLS Collation/Locale/Keyboard Technical Lead
> Globalization Infrastructure, Fonts, and Tools
> Microsoft Windows International Division
> ----- Original Message -----
> From: "Simon Josefsson" <email@example.com>
> To: "Michael (michka) Kaplan" <firstname.lastname@example.org>
> Cc: "Unicode Mailing List" <email@example.com>; "Paul Hoffman / IMC"
> <firstname.lastname@example.org>; "Martin Duerst" <email@example.com>; "Mark Davis"
> Sent: Wednesday, January 26, 2005 2:27 PM
> Subject: Re: Open Issue #61: Proposed Update UAX #15 Unicode Normalization
>> "Michael \(michka\) Kaplan" <firstname.lastname@example.org> writes:
>> > From: "Simon Josefsson" <email@example.com>
>> >> However, by making the change, normalization over time become
>> >> instable, and lead to similar consistency issues. If one application
>> >> use Unicode 3.2 (or 4.0) and normalize the string, and another
>> >> application use 4.1, you also get a different answer.
>> > A problem that happens in all standards, like XML, which is why they
> have as
>> > line ast the top of the XML standard that says:
>> > "Please refer to the errata for this document, which may include some
>> > normative corrections.Please refer to the errata for this document,
>> > may include some normative corrections."
>> > With a link to errata.
>> > This is how standards work. Given how many errata exist in some
>> > it is amazing the standard to which Unicode is held BY THE SAME PEOPLE
>> > appove errata elsewhere that make normative corrections.
>> I must have been terribly unclear.
>> I'm not saying there isn't a problem that should be fixed.
>> I'm saying that maybe there is more than one way to solve the
>> identified problem.
>> I don't claim that my proposal is better, but I'd like to understand
>> why the current proposal is better than any other possible solution.
>> I believe the current proposal lead to some problems. Consequently, I
>> think it would be worth discussing alternatives before accepting it.
This archive was generated by hypermail 2.1.5 : Wed Jan 26 2005 - 17:33:57 CST