Re: 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
> >
> >
> >
>
>
>