Re: [idn] Which lanuages/scripts to reorder?

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

----- Original Message ----- 
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Soobok Lee" <lsb@postel.co.kr>; "Mark Davis" <mark@macchiato.com>; "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
Cc: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>; <idn@ops.ietf.org>
Sent: Wednesday, October 24, 2001 12:35 AM
Subject: Re: [idn] Which lanuages/scripts to reorder? 


> The problem is that there will be people who will request reordering (or
> they complain unfair treatment). It is very hard to explain to X why
> there is reordering for Y but not X.
> 
I will try to include as many script as possible in the final REORDERINg I-D.

But, Even without reordering,
some tagalog people will come and say  why ACE-Z  favors latin  with special
 literal mode supports.
Do you think this timebomb invalidates ACE-Z literal mode ?  No.

cost/benefits-based trade-off  can be the answer for this disputes on
special treatment in ACE-Z as well as REORDERING.

REORDERING's memory requirement is minimal  while it give 30% boostup
for hangul names. I don't recommend  reordering supports for latin and runic script.
You can find the rationale in my REORDERING I-D 2.0.


Soobok Lee


> Why create a potential timebomb for ourselves?
> 
> -James Seng
> 
> ----- Original Message -----
> From: "Soobok Lee" <lsb@postel.co.kr>
> To: "Mark Davis" <mark@macchiato.com>; "Erik Nordmark"
> <Erik.Nordmark@eng.sun.com>
> Cc: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>;
> <idn@ops.ietf.org>
> Sent: Tuesday, October 23, 2001 11:17 PM
> Subject: Re: [idn] Which lanuages/scripts to reorder?
> 
> 
> 
> ----- Original Message -----
> From: "Mark Davis" <mark@macchiato.com>
> To: "Soobok Lee" <lsb@postel.co.kr>; "Erik Nordmark"
> <Erik.Nordmark@eng.sun.com>
> Cc: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>;
> <idn@ops.ietf.org>
> Sent: Tuesday, October 23, 2001 11:59 PM
> Subject: Re: [idn] Which lanuages/scripts to reorder?
> 
> 
> > >Therefore, your concerns about long path of reordering revisioning is
> NOT
> > new >problem,but rather just one of never-terminaing nameprep/ACE
> > revisioning >problem.
> >
> > I disagree completely. Nameprep is designed so that it will work even
> if a
> > server and a client are on different versions, and without any version
> > number involved. That would absolutely fail if reordering were changed
> in
> > any future version.
> 
> Reordering won't be changed and  remains as sub-optimal frequency tables
> forever without new prefix, as i repeated many time in this list.
> 
> What i mean is adding NEW reordering tables for *NEW SCRIPTS*
> in accordance with new SCRIPT support in newer nameprep.
> I agree with you that reordering table for old existing scripts should
> not be changed .
> 
> each Nameprep version defines unassigned code points which reordering
> should
> not touch at all. That enforce  reordering  upgrade path strictly to
> follow  that of nameprep.
> 
> Soobok Lee
> 
> >
> > Introducing explicit version numbers (and it could not be limited to
> 2)
> > would not help -- it would just make things worse.
> >
> > Mark
> > —————
> >
> > Δός μοι ποῦ στῶ, καὶ κινῶ τὴν γῆν — Ἀρχιμήδης
> > [http://www.macchiato.com]
> >
> > ----- Original Message -----
> > From: "Soobok Lee" <lsb@postel.co.kr>
> > To: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
> > Cc: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>;
> > <idn@ops.ietf.org>
> > Sent: Tuesday, October 23, 2001 05:34
> > Subject: Re: [idn] Which lanuages/scripts to reorder?
> >
> >
> >
> > ----- Original Message -----
> > From: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
> > To: "Soobok Lee" <lsb@postel.co.kr>
> > Cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>; "Eric
> Brunner-Williams in
> > Portland Maine" <brunner@nic-naa.net>; <idn@ops.ietf.org>
> > Sent: Tuesday, October 23, 2001 7:25 PM
> > Subject: Re: [idn] Which lanuages/scripts to reorder?
> >
> >
> > >
> > > > seamless upgrade idea for adding new script reordering tables and
> new
> > > > nameprep rules (NF/casemappings) are described in the posting
> titled
> > with
> > > > "suggestion : two prefices ....". No newer prefix other than (zq--
> and
> > uq--)
> > > > will be needed forever. I recommend you to comment on the
> suggestion
> > first
> > > > before you go further.
> > >
> > > Soobok,
> > >
> > > We seem to have a failure to communicate.
> > > I've placed one new concern on the table which does not have
> anything to
> > > do with how you could technically upgrade to new reordering tables.
> > >
> > > My concern is about that the process of definition reordering tables
> > > might never terminate (or might take a decade or so) since there
> might
> > very
> > > well be a request to add more and more languages/scripts to the
> tables
> > before
> > > we ever get to produce a single RFC.
> > >
> >
> > Erik,
> >
> > new reordering tables can be added only when there comes new nameprep
> > revision for newly added scripts, because reordering tables is
> proposed as
> > one candidate of nameprep/ACE components. that is, reordering tables
> are
> > bound by the versioning of nameprep.
> >
> > nameprep (as one profile of stringprep) upgrade paths also never
> terminate
> > because there will be more and more scripts pending for approval over
> time.
> >
> > If you look into nameprep/stringprep document, each version of
> nameprep
> > should specify  the used unicode version and the list of unassigned
> code
> > points in
> > in that version. If new versions of unicode accumulate enough set of
> new
> > scripts for justifying major nameprep revision, then IETF IDN WG
> should work
> > again to give birth to new nameprep profile with new list (maybe
> reduced by
> > the amount of new assigned code points) of unassgined code points and
> new
> > version number of unicode.
> >
> > Therefore, your concerns about long path of reordering revisioning is
> NOT
> > new problem,but rather just one of never-terminaing nameprep/ACE
> revisioning
> > problem.
> >
> > if we finalize IDN  before TAGALOG is assigned and added, current
> nameprep's
> > architecture for unassigned code points, does not allow us to register
> > tagalog domains   until new nameprep version come out by IETF
> activities in
> > the undefined time in the future.
> >
> > My two prefix(uq-- and zq--) scheme proposal tries to solve this
> inherenet
> > problem of user inconveniences in treatment of unassigned code points,
> even
> > before distributions of new version of nameprep which often take *too
> much
> > time* to serve the TAGALOG users' need.
> >
> >
> >
> > Soobok Lee
> >
> > > I do not have anything to add to the techical issue of how upgrade
> > > to new reordering tables as that was not the issue over which
> > > I expressed concern. Thus it makes no sense to me to comment on that
> > issue.
> > >
> > >
> > > Sincerely,
> > >   Erik
> > >
> > >
> > >
> >
> >
> >
> >
> 
> 
>