Unicode 7.0.0, (combining) Hamza Above, and normalization
ajs at anvilwalrusden.com
Fri Aug 8 01:07:59 CEST 2014
Sorry for the iPhoney reply. I wasn't trying to say the result is wrong as such. I think it _may_ be wrong for IDNA and therefore possibly an indication that our approach in IDNA2008 (and therefore alas in precis) is inadequate.
Please excuse my clumbsy thums.
> On Aug 7, 2014, at 16:24, Paul Hoffman <paul.hoffman at cybersecurity.org> wrote:
>> On Aug 7, 2014, at 12:34 PM, Markus Scherer <markus.icu at gmail.com> wrote:
>> On Thu, Aug 7, 2014 at 9:58 AM, Paul Hoffman <paul.hoffman at cybersecurity.org> wrote:
>> A big +1 to what Andrew said. Vint may have been reacting viscerally, but the actual technical problem with this new character is (I believe) the normalization rules producing the wrong result. If I'm wrong, I'd be happy to be corrected.
>> That's roughly the opposite of what Andrew said.
> No, it's the same.
>> Andrew clarified Mark's statement that the new character is not the same as its apparent decomposition, and that's why it needed to be encoded separately and without a Decomposition_Mapping. Please read again Andrew's "The difference in this case, ..."
> Right. To me, the current processing under NFC is the wrong result. Andrew was a bit polite at the end of his message, but it sounds to me that he thinks the NFC processing for the new character leads to the wrong result when compared to earlier NFC processing.
> --Paul Hoffman
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update