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

["Soobok Lee" <lsb@postel.co.kr>]

----- Original Message ----- 
From: "James Seng" <jseng@pobox.org.sg>
  
> No. The problem you describe, ie the improper handling of legacy encoding is
> an implementation issue, not protocol one.

If legacy encodings are incorporated into any IDNA libraries,
 There arise  legacy encoding versioning problems, regardles of whether
   the legacy encoding implementations were correct or not  at that time of first deployment.

In summary, the issue is that: How can we build IDNA tower on the ground
of moving legacy encodings ? Is it still  implementation issue?
In Sanfrancisco and Tokyo, every building should be well architectured
against any earthquakes and  'soften' land.

Soobok Lee

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