Re: [idn] call for comments for REORDERING

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

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" <duerst@w3.org>
To: "Soobok Lee" <lsb@postel.co.kr>; <idn@ops.ietf.org>
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
>
>