Re: Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987)

By "additions", i mean the required new tag for new version of legacy encoding, like "ks_c_5601-1992"
which should have been used, but never have been, as far as i know. Is there any central
registry that maintain the correct tag values for vaiour versions of numorous legacy encodings ??
If not, how to ensure stable and interoperable legacy-2-unicode conversion among myriads of applications ?

Soobok Lee

----- Original Message ----- 
From: "Doug Ewell" <[email protected]>
To: <[email protected]>; "James Seng" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, May 29, 2002 2:32 PM
Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987)


> Soobok Lee <lsb at postel3 dot postel dot co dot kr> wrote:
> 
> > What if  proper and stable implementation of legacy encodings in
> > IDNA is not a tangilbe object due to their frequent updates/
> > additions ?
> 
> How "frequent" are updates to legacy encodings, or updates to the
> mapping tables between legacy encodings and Unicode?
> 
> As for additions, they shouldn't cause a problem anyway, because they
> don't break existing legacy-to-Unicode mappings.  An often-mentioned
> case of adding to a legacy encoding was when Microsoft retrofitted
> U+20AC EURO SIGN onto their Windows code pages (mostly at previously
> unassigned code position 0x80).  The only people who suffered at all
> were the ones who thought "unassigned" somehow meant that they should
> map 0x80 to U+0080.  Everyone else made it just fine.
> 
> -Doug Ewell
>  Fullerton, California
>  (would prefer to receive only one copy of these messages)
>