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

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

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