The consortium does not encourage the development of further general-purpose UTFs. Endlessly multiplying such formats just leads to confusion.
As to compression formats, once ACE is already defined by an RFC it is better to simply reference that in any Unicode documentation that needs to. Keeping the definition in one place is easier than having two definitions that require synchronization. Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "David Leung (Neteka Inc.)" <[EMAIL PROTECTED]> To: "Bruce Thomson" <[EMAIL PROTECTED]>; "IETF idn working group" <[EMAIL PROTECTED]> Sent: Thursday, March 28, 2002 23:25 Subject: Re: [idn] URL encoding in html page > > > The question is really why 8/16/32 bit Unicode is better than 5bit > (ACE)? > > > > ACE and UTF-8 are just compression algorithms that squeeze larger > > Unicode characters. ACE is more efficient than UTF, although more > > complex. > > > > But the claim to fame that UTF-8 has is that it is a standard that > > idn can reference, and it is coming into widespread use elsewhere. > > > > So moving to UTF-8 long term seems like such an obvious choice > > is surprises me that it even gets debated. > > > > Of course, Punycode is a nice compression method... Maybe we should > > take it to the Unicode forum and suggest that it be the next version of > > UTF-8? > > > > But if that doesn't happen, it should logically be phased out. > > That's right if ACE is such a good "compression and encoding" scheme for > Unicode, I think Unicode consortium should adopts it as the new UTF-P or > UTF:-P, if they already have UTF8 that is widely use nowadays and also will > be more use in the future, why not use UTF8 as a long term, and re-inventing > the wheel now. > > > > >
