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

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

That may work. However, I believe that it implies some limitiations on
reordering to preserve compatibility across versions.

Example: Suppose that at some time in the future there are 4 versions: A, B,
C, D.

I send you zq--XXX. It contains a character UA that is unassigned in A (but
not B), a character UB that is unassigned in B (but not C), and a character
UC that is unassigned in C (but not D). With normal nameprep this doesn't
matter. You should use version D of nameprep to read the IDN. If you use a
back-rev'd version, you will simply recognize that it has an unassigned
character, and reject the name.

Now suppose that we have reordering, and you are back-rev'ed, and support C
but not D. When you get UC, you have to be able to recognize that it is an
unassigned character to know to reject it. That means that within any
version (I think after the first), isUnassigned(x) if and only if
isUnassigned(reordered(x)). Thus any future changes in reordering have to
preserve the "unassigned" status: so the future reorderings have to be, in
some sense, "in place".

Mark
—————

Δός μοι ποῦ στῶ, καὶ κινῶ τὴν γῆν — Ἀρχιμήδης
[http://www.macchiato.com]

----- 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 08:35
Subject: Re: [idn] Which lanuages/scripts to reorder?



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