Re: Re: Fwd: Unicode letter ballot

On Thu, Nov 28, 2002 at 01:20:33AM +0100, Simon Josefsson wrote:
> Harald Tveit Alvestrand <[email protected]> writes:
> 
> > --On mandag, november 25, 2002 13:10:39 +0100 Simon Josefsson
> > <[email protected]> wrote:
> >
> >> This message seems important for IDN.
> >>
> >> Note that if option A win the vote, it seems that stringprep/nameprep
> >> will have to fork the Unicode standard to remain backwards compatible
> >> when stringprep/nameprep updates its Unicode reference.
> >>
> >
> > sigh.... all 5 are beyond-BMP characters added recently.
> > if we could go back in time, we could have implemented a policy of not
> > accepting characters as stable before 2 unicode versions had gone
> > by....
> >
> > proofreading takes time.
> 
> Even two Unicode releases doesn't guarantee that the tables are
> correct.  The only proper solution I can see is to stop modifying
> published decomposition tables.  When mistakes are discovered, new
> character codes with proper decompositions should be added and the old
> character codes declared obsolete -- which is option B in the vote,
> but unfortunately neither IDN nor IETF has any voting powers (which
> suggest a methodological problem).
> 

If option B  wins, a few issues may be raised easily:
 1) added characters does not preserve the original/ideal lexicographic
    radical-based order of those CJK glyphs.
 2) How does any obsoletion of characters work ? 
    compatiblity CJK characters are NFC-ed into other CJK characters
    in stringprep and so required obsoletion(mapping to newly added ones)
    should be done _before_ the stringprep operation is taken.
    
If option A wins, I see a chaos:
 1) NFKC_3.2_nameprep(NFKC_4.0_calling_application(IDN))  
       !=  NFKC_3.2_nameprep(IDN)  
    What if future HTML/canonical XML standards adopt NFKC_4.0 ?

Soobok Lee