Wait wait..new prefix?? You are going down a path whereby a *single* domain name may have *X* number of ACE, each one with a different prefix, depending on the version number of re-ordering & nameprep. Great, please explain how the client going to do matching with different version, or client & server without some form of communication?
No, going to multiple prefix is a BAD *BAD* **BAD** *B*A*D* idea. Lets not even go there. -James Seng ----- Original Message ----- From: "Soobok Lee" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Martin Duerst" <[EMAIL PROTECTED]> Sent: Monday, October 22, 2001 6:53 PM Subject: Re: [idn] call for comments for REORDERING ----- Original Message ----- From: "Martin Duerst" <[EMAIL PROTECTED]> > What I meant is that e.g. somebody goes ahead and > implements reordering based on one of your tables. > Then e.g. the IETF includes reordering in IDN > (Don't misunderstand me, this is only an example, > of course I think this should never happen.), but > with a different table based on newer statistics. > The original implementer doesn't catch that he has > a different table, and as a result, we have total > chaos, nothing matches. But newer reordering table with newer statistics cannot be deployed without new ACE PREFIX, as i said many times. But current nameprep rules out the possibility of newer PREFIX. Therefore, newer reordering table would not occur until this objection to future new prefix is un-freezed and lifted up by IETF. With new prefix, there won't occur any confusion problems you raised regarding to REORDERING. Soobok Lee > > In comparison, if somebody by chance gets an old > NFC/KC table, a few labels won't match, but it won't > be a whole script or more that gets ruined. > > Regards, Martin. >
