[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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. 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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>