----- Original Message ----- From: "Soobok Lee" <[EMAIL PROTECTED]> To: "liana Ye" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 24, 2001 10:35 AM Subject: Re: [idn] Which lanuages/scripts to reorder?
> > ----- Original Message ----- > From: "liana Ye" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > > > > writes: > > > > > > > > > > ----- Original Message ----- > > > > > From: "Mark Davis" <[EMAIL PROTECTED]> > > > > > > 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" <[EMAIL PROTECTED]> > > > > > > To: "Erik Nordmark" <[EMAIL PROTECTED]> > > > > > > Cc: "Eric Brunner-Williams in Portland Maine" > > > > > <[EMAIL PROTECTED]>; > > > > > > <[EMAIL PROTECTED]> > > > > > > Sent: Tuesday, October 23, 2001 05:34 > > > > > > Subject: Re: [idn] Which lanuages/scripts to reorder? > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Erik Nordmark" <[EMAIL PROTECTED]> > > > > > > To: "Soobok Lee" <[EMAIL PROTECTED]> > > > > > > Cc: "Erik Nordmark" <[EMAIL PROTECTED]>; "Eric > > > > > Brunner-Williams in > > > > > > Portland Maine" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
