RE: [idn] Report from the ACE design team

[Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>]

At/À 13:06 2001-06-25 -0400, Hollenbeck, Scott you wrote/vous écriviez:
> >-----Original Message-----
> >From: Makoto Ishisone [mailto:ishisone@sra.co.jp]
> >Sent: Monday, June 25, 2001 12:32 PM
> >To: idn@ops.ietf.org
> >Subject: Re: [idn] Report from the ACE design team
> >
>
>[snip]
>
> >2) Potential migration problem
> >   Many NICs has already begun registering internationalized domain
> >   names using RACE as the ACE.  In RACE, any names up to
> >   17-characters can be fit in 63-octet label.  So it is possible that
> >   some of the registered names suddenly become invalid when migration
> >   from RACE to DUDE take place.  Of course it is a risk that they
> >   have to take, but if choosing other ACE can prevent it, or lower
> >   the possibility, it might be a better choice.
>
>One data point WRT this concern: In at least one implementation that I'm
>familiar with, there is expected to be a _very_ small number of names
>(0.01%) that become invalid due to length restrictions when converting from
>RACE to DUDE.

and how many were not included at all in the testbeds because they were too 
long?  The fact that some cannot be converted doesn't mean that the current 
length is enough!

I think the testbed-need-to-convert-already-registered-names-to-new-ace 
argument (for both Makoto-san and Scott) is weak:
- we should not make our decisions based on early testbeds statistics, 
since they are early, incomplete.
- So I would suggest to not take into account both Makoto-san second 
argument and Scott argument.
- At the same time, the testbeds I think give us good input about the fact 
that, even on a very limited basis, names are already longer than the maximum.

My take on this is that there is a design trade-off between complexity and 
compression. If an ACE is chosen, it will be implemented everywhere  and 
open source code will be available as a reference code. So additional 
complexity can be managed (while a simpler design is always good).  But, to 
me, compression is much more important. Compression which is as fair as 
possible for the largest number of scripts.  With any ACE, any non-ascii 
script is already disadvantaged. We should minimize this as much as we can. 
Specially, since some scripts will be down to less than 20 chars.

My conclusion: put compression as the first most important criteria, and 
complexity down the list of importance.

My 2 cents.

Marc.


><Scott/>