I would like to add my comments to this: Reordering increases efficient of the encoding allowing longer labels. This allows us to go sometimes as much as 25% more. OTOH, as IDN as a form of identifiers, then practically, shorter labels are better. Aside, re-ordering also increases the complexity of the algorithm. This is an engineering trade-off we have to made should we consider re-ordering.
The bigger concern I have with re-ordering remains in the fact that tables mappings proves efficient with existing IDN names in some registries *BUT* it does not indicate what performance it would be like in the future. We do not know what happened when the names space get saturated and would other names which would have been useable without lsb become un-usuable due to lsb. And with the existing draft, it does not explain how it going to deal with new codepoints in ISO10646 in the future, nor does it explain the process to implementing them. The critia here is stablity - if new code is added and tables for re-ordering expand, then the algorithm should not make existing names invalided. Third, I would really prefer to reference a work from established expert group if possible. For example, ISO/IEC JTC1/SC22/WG20 publishes ISO 14651 on weighted sorting. I am not sure how ISO 14651 would perform for the IDN purpose but I thought it might be worthwhile to examine. Whatever the case, we should make a decision quickly on this. Lets not drag this further if possible. -James Seng ----- Original Message ----- From: "Martin Duerst" <[EMAIL PROTECTED]> To: "Soobok Lee" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, October 10, 2001 1:16 PM Subject: Re: [idn] call for comments for REORDERING > Hello Soobok, > > Here are my comments on reordering. Apologies if they are > too clear. > > The additional complexity introduced by reordering is a very > serious problem. It is true that this complexity is somewhat > similar to the complexity of e.g. nameprep or conversion from > a legacy encoding. However, on many platforms, both conversion > from a legacy encoding as well as many aspects of nameprep > are available as libraries, and are used for other purposes. > In particular on constrained devices (mobile phones,...), > most of nameprep can be simplified a lot if one knows what > kinds of characters can be input. > > On the other hand, the benefits for the users are actually > very small. Nobody wants to input domain names with 15 or > more Hanzi or Hangul. Nobody will be able to remember them. > Writing them down on a napkin will take a long time. > Every company or organization that has such a long label > in their domain name, and no shorter alternative, will > simply not get any contacts directly to their web site. > If they have a short alternative, why do they need a > long version? (please note that there is no danger of > spoofing by somebody else getting the long version :-). > > So this is a solution in search of a real problem, > not worth bothering the whole world with additional > complexity. > > > Regards, Martin. > > > At 13:11 01/10/10 +0900, Soobok Lee wrote: > >Hi, all > > > >I am ready to receive any criticisms on REORDERING. > >Any suggestions of improvements or downsides of REORDERING are all welcome. > > > >I expect many feedbacks from non-US and non-European participants and > >observers. > > > >Thanks. > > > >Soobok Lee > >
