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

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

----- Original Message ----- 
From: "Mark Davis" <mark@macchiato.com>
 > Introducing explicit version numbers (and it could not be limited to 2)
> would not help -- it would just make things worse.
> 

Mark, 
You may missed my point.
two prefix uq-- and zq-- does *not*  limit  the versioning into 2 times, but infinite times.

zq-- is for valid ACE labels  for the all version of nameprep and
uq-- is for invalid ACE labels including at least one unassigned code points for all versions of 
nameprep.

This differentiating ace prefixing scheme works  in all version of nameprep from 1 to infinity.

newly supported script in nameprep/ACE version 5 will be
encoded using  uq--????  with old nameprep/ACE version 4  and below.
But with namepre/ACE version 5 or above, it will be encoded zq--???? .

Likewise,
labels contain newly supported script in nameprep/ACE version 6 will be
encoded using  uq--????  with old nameprep/ACE version 5 and below.
But with namepre/ACE version 6 or above, it will be encoded zq--???? .

And so on.

There is no need for version numbered prefix  for each of version 2,3,4,5,6, .....

Current nameprep does not encode unassigned code points into ACE for
"saved strings", but my two prefix scheme allow it with "uq--" prefix  which
provide with  rooms for incorporating  some useful fallback mechanims.
Even with dealing with ACE foor lookup "query", it provide some clues
about the version of nameprep which encode the ACE lables by the
distintion of "uq--" and "zq--".
I am proposing new nameprep behavior for unassigned code points for 
"saved string" and "query" through out  nameprep versioning path. 
Not about  versioning nameprep itself!

Soobok Lee


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