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

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

----- 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: Wednesday, October 24, 2001 2:09 AM
Subject: Re: [idn] Which lanuages/scripts to reorder? 


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

No problem.

REORDERING  is defined  on  single contiguous block of  assigned characters
within a script block for one version of nameprep.

If  a part of contiguous block of  UNassigned characters of a script block was
 changed into  ASSIGNED in the new nameprep, REORDERING for new nameprep
might contain the REORDERING defined on the changed block part.

REORDERING can be  defined NOT across script blocks, nor,  across
unassigned sub-block and assignedsub-block in a script block at any time.
Since assigned and unassigned code points , in most cases, would not much orrelations
between their character usages, that is very natural consequence,too.

Soobok Lee

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