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