The big problem lies in that such bad and loose versioning practice is *everywhere*. And precise and correct legacy-code versioning requires that "code-range&version" checking routines should be inserted in every application. And such checking routines themselves also should be versioned because legacy encodings are ever evolving. Both objectives requires upgrading all existing i18n applications, but that may be not feasible, by the same reason why IDNA is preferred over UTF8 approach in this WG.
For example, let's assume future Outlook Express 7.0 will fix the bug by introducing new mime charset name "KS_C_5601-1992" . The sender posts an email message in KS_C_5601-1992 to the recipient who uses Outlook Express 6.0 which knows only "KS_C_5601-1987". What will happen? maybe, fallback to iso8859-1 or default locale. direct-charset-negotiation between the sender/recipient's email clients are not possible. A XML application server receives a XML request encoded in new KS_C_5601_1992, but the server applications don't know the new charset. what happens if the transaction was in batch mode? There may be no immediate/interactive error report to the orginator. That explains how much difficult it would be to introduce new version or new legacy encoding into the IDN repertoires of supported encodings , if a certain version of IDN/IRI would have been widely deployed. Soobok Lee ----- Original Message ----- From: "Roozbeh Pournader" <[EMAIL PROTECTED]> > On Wed, 29 May 2002, Soobok Lee wrote: > > > you can find the errornous mime-charset name : "KS_C_5601-1987". > > Stupid and Wrong Versioning! > > Sure. But no protocol can fix broken software. Nag to developers of the > software to fix it. In this case, it is passing a character onto wire, > which is not in the character set it is claiming it to be in. > > If a piece of software wants to work with KSC 5601:1992, and use the > character you used, should know its mapping to Unicode. Simple. > > roozbeh > > >
