[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Which lanuages/scripts to reorder?
----- Original Message -----
From: "liana Ye" <liana.ydisg@juno.com>
To: <lsb@postel.co.kr>
Cc: <mark@macchiato.com>; <Erik.Nordmark@eng.sun.com>; <brunner@nic-naa.net>; <idn@ops.ietf.org>
Sent: Wednesday, October 24, 2001 2:35 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.
>
> 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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
>