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

["James Seng" <jseng@pobox.org.sg>]

> 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" <jseng@pobox.org.sg>
> To: "Soobok Lee" <lsb@postel.co.kr>; <idn@ops.ietf.org>
> 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" <lsb@postel.co.kr>
> > To: <idn@ops.ietf.org>
> > 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" <roozbeh@sharif.edu>
> > >
> > > > 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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>
>