> The legacy encodings are ever evolving and ever *emerging*. Yes.
> That is not the implementation issue , rather protocol/architecture issues, IMO. No. The problem you describe, ie the improper handling of legacy encoding is an implementation issue, not protocol one. Don't confuse the two. -James Seng > Soobok Lee > > ----- Original Message ----- > From: "James Seng" <[EMAIL PROTECTED]> > To: "Soobok Lee" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Wednesday, May 29, 2002 8:57 AM > Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > If the problem is with the implementation, we fix the implementation, not > > the protocol. We have similar arguments before. > > > > -James Seng > > > > ----- Original Message ----- > > From: "Soobok Lee" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, May 29, 2002 1:14 AM > > Subject: Re: [idn] Re: Legacy charset conversion in > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > >
