[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.
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).
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
> > >
> > >
> > >
> >
> >
> >
> >
>
>