[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Which lanuages/scripts to reorder?
----- Original Message -----
From: "Soobok Lee" <lsb@postel.co.kr>
To: "liana Ye" <liana.ydisg@juno.com>
Cc: <idn@ops.ietf.org>
Sent: Wednesday, October 24, 2001 10:35 AM
Subject: Re: [idn] Which lanuages/scripts to reorder?
>
> ----- Original Message -----
> From: "liana Ye" <liana.ydisg@juno.com>
> To: <lsb@postel.co.kr>
> Cc: <idn@ops.ietf.org>
> Sent: Wednesday, October 24, 2001 3:51 AM
> Subject: Re: [idn] Which lanuages/scripts to reorder?
>
>
> >
> >
> > >
> > > > Soobok,
> > > > I think the versioning in nameprep/stringprep can handle one
> > > > type of change - addition to Unicode table . To add another
> > > change
> > > > such as recodering a Unicode code table, the complexity
> > > > increases and it is dangerous to ask for.
> > >
> > > It is hidden in ACE, not reveal to outer world.
> > > no complexity to childrens and elders.. but only for implementors..
> > > :-)
> > > the complexity of reordereing is exaggerated. look into the minimal
> > > reodering requirement
> > > deescribed in my I-D.
> > >
> >
> > But you do change the order of codepoints in UCS, and others
> > are depending on the order to do other things too.
>
> Never. reordering is done and reversed in ACE. so a kinf of huge lists of
> tuning parameters.
> A kind of atomic operatoin. that does hinder any other UCS mappings.
Oops.. that does NOT hinder any other mappings.
Sorry.
>
> Soobok Lee
>
>
> > That is my
> > point, not how much is done to it in one procedure or it is hitten
> > or not.
> >
> > Liana
> >
> > > >
> > > > In addition, the reordering envolves individual code blocks of
> > > > treatment, which is based on frequency of usage. It is good
> > > > for individual input, it is good for applications of particular
> > > user
> > > > group, for example a steel industry, a transportation industry or
> > > > even news reporters, but it is not good when we're trying to find
> > > > a common denominator to cross various scripts. If you believe
> > > > there is a common denominating use of the frequency based
> > > > treatment, that should be a topic in Unicode group when forming
> > > > such a table and providing guide in using these tables, such
> > > > as advice like "no TC/SC in nameprep" (as IDN is the group
> > > > in making that decision).
> > > >
> > >
> > > You missed that frequency tables are always sub-optimal
> > > even with UTC's research.
> > > Elders and chiledrens and teachers and programmers have different
> > > set of frequent everyday vocabularies.
> > > Who can decide the weights for their words usages to get word
> > > statistics?
> > >
> > > Some good working registrations samples serve best for our
> > > reordering need.
> > >
> > > your concerns are not wrong but not relevant to validity of
> > > reordering.
> > >
> > > Soobok Lee
> > >
> > > > Liana
> > > >
> > > > On Wed, 24 Oct 2001 00:35:08 +0900 "Soobok Lee" <lsb@postel.co.kr>
> > > > writes:
> > > > >
> > > > > ----- 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>