[idn] Re: stringprep comment 5: hangul conjoining sequence

["Mark Davis" <mark@macchiato.com>]

Syllable breaks are different than character boundaries. Please see
http://www.unicode.org/versions/beta.html, where that is clarified.

Now, of course, it would be possible to choose a different
normalization. That has, however, been debated at great length on this
list; see the archives. I see no pressing need for change.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Soobok Lee" <lsb@postel.co.kr>
To: <idn@ops.ietf.org>
Cc: "Martin Duerst" <duerst@w3.org>; "Mark Davis"
<mark.davis@macchiato.com>
Sent: Monday, February 11, 2002 08:12
Subject: stringprep comment 5: hangul conjoining sequence


> Two issues briefed in hangulchars drafts and in this mailling list,
but not mentions in
>   the latest nameprep and stringprep drafts:
>
>  1. When  old trailing hangul jamos are included in conjoining jamo
sequences, UAX15(NFC)
>      performs  partial combinations to produce  "a modern hangul
syllable(LV) + a standalone
>       old hangul jamo(oT)" and that form satify a ridiculous
syllable break condition (X.T) .
>
>
>  2. UAX15 also tries ridiculous partial combinations when it met a
combining sequence if
>       two or more leading hangul jamos followed by hangul vowel
jamos, and produce
>       a syllable break condition (L.LV)
>
>  3. Compatibility hangul jamos are mapped into conjoining jamos
without any fillers.
>
>  Errors briefed in 1,2 and 3 came from  past poor cooperations
between UAX15 authors and Korean UTC participants, and NFC routines
> was already widely distributed.
>
>  Now I propose UTC make new normalizations (call it NFN)to correct
such errors and faults and
>     let stringprep include it after casefolding : that is
NFKC(NFN(casefold(x)).
>
>  We dont need to modify NFC and NFKC. Just add new correcting
normalizations as soon as possible.
>
>  Stringprep efforts should be in sync with further UTC's works. No
hastes!
>
>  Soobok Lee
>
>