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

["Mark Davis" <mark@macchiato.com>]

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

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