----- Original Message ----- From: "James Seng/Personal" <[EMAIL PROTECTED]> To: "Soobok Lee" <[EMAIL PROTECTED]>; "Mark Davis" <[EMAIL PROTECTED]>; "Erik Nordmark" <[EMAIL PROTECTED]> Cc: "Eric Brunner-Williams in Portland Maine" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, October 24, 2001 12:35 AM Subject: Re: [idn] Which lanuages/scripts to reorder?
> The problem is that there will be people who will request reordering (or > they complain unfair treatment). It is very hard to explain to X why > there is reordering for Y but not X. > I will try to include as many script as possible in the final REORDERINg I-D. But, Even without reordering, some tagalog people will come and say why ACE-Z favors latin with special literal mode supports. Do you think this timebomb invalidates ACE-Z literal mode ? No. cost/benefits-based trade-off can be the answer for this disputes on special treatment in ACE-Z as well as REORDERING. REORDERING's memory requirement is minimal while it give 30% boostup for hangul names. I don't recommend reordering supports for latin and runic script. You can find the rationale in my REORDERING I-D 2.0. Soobok Lee > Why create a potential timebomb for ourselves? > > -James Seng > > ----- Original Message ----- > From: "Soobok Lee" <[EMAIL PROTECTED]> > To: "Mark Davis" <[EMAIL PROTECTED]>; "Erik Nordmark" > <[EMAIL PROTECTED]> > Cc: "Eric Brunner-Williams in Portland Maine" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Tuesday, October 23, 2001 11:17 PM > Subject: Re: [idn] Which lanuages/scripts to reorder? > > > > ----- Original Message ----- > From: "Mark Davis" <[EMAIL PROTECTED]> > To: "Soobok Lee" <[EMAIL PROTECTED]>; "Erik Nordmark" > <[EMAIL PROTECTED]> > Cc: "Eric Brunner-Williams in Portland Maine" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Tuesday, October 23, 2001 11:59 PM > Subject: Re: [idn] Which lanuages/scripts to reorder? > > > > >Therefore, your concerns about long path of reordering revisioning is > NOT > > new >problem,but rather just one of never-terminaing nameprep/ACE > > revisioning >problem. > > > > I disagree completely. Nameprep is designed so that it will work even > if a > > server and a client are on different versions, and without any version > > number involved. That would absolutely fail if reordering were changed > in > > any future version. > > Reordering won't be changed and remains as sub-optimal frequency tables > forever without new prefix, as i repeated many time in this list. > > What i mean is adding NEW reordering tables for *NEW SCRIPTS* > in accordance with new SCRIPT support in newer nameprep. > I agree with you that reordering table for old existing scripts should > not be changed . > > each Nameprep version defines unassigned code points which reordering > should > not touch at all. That enforce reordering upgrade path strictly to > follow that of nameprep. > > Soobok Lee > > > > > Introducing explicit version numbers (and it could not be limited to > 2) > > would not help -- it would just make things worse. > > > > 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 > > > > > > > > > > > > > > > > > > > >
