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

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

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.

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