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

[<lsb@postel3.postel.co.kr>]

What if  proper and stable implementation of legacy encodings in IDNA
 is not a tangilbe object due to their frequent updates/additions ? 
stringprep/nameprep added some code prohibiting rules wrt UCS versioning. 
 And IDNA mentioned about legacy-2-unicode conversions necessary in major
 user environments. legacy versioning and UCS versioning is similar and
 interdependant issues that affect IDN security.

Soobok Lee


On Wed, 29 May 2002, James Seng wrote:

> Lee,
> 
> I repeat:
> 
> legacy encoding evolves -- yes; but each one is tagged properly.
> 
> Implementation which does not handle legacy encoding properly is an
> implementation problem, not a protocol one. Evolving encoding standards is
> not an issue.
> 
> By all means twist the arguments round in circle, in your usual style. This
> will be my last email on this thread.
> 
> -James Seng
> 
> > ----- 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >
>