Re: [idn] call for comments for REORDERING

["James Seng/Personal" <jseng@pobox.org.sg>]

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" <lsb@postel.co.kr>
To: <idn@ops.ietf.org>; "Martin Duerst" <duerst@w3.org>
Sent: Monday, October 22, 2001 6:53 PM
Subject: Re: [idn] call for comments for REORDERING



----- Original Message -----
From: "Martin Duerst" <duerst@w3.org>
 > 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.
>