Subject: RE: [idn] Report from the ACE design team

From: Marc Blanchet <[email-masked]>
Date: Mon, 25 Jun 2001 13:55:10 -0400

At/À 13:06 2001-06-25 -0400, Hollenbeck, Scott you wrote/vous écriviez:
> >-----Original Message-----
> >From: Makoto Ishisone [mailto:[email-masked]]
> >Sent: Monday, June 25, 2001 12:32 PM
> >To: [email-masked]
> >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/>

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 25 Jun 2001 15:52:10 -0400

Marc,

Scott didn't actually use the word "testbed".

Let's leave that term, used as a synonym for "propriatary product", for
others in the marketing realm, and use it properly within the IETF for
activities consistent with our history.

There isn't a lot in propriatary product(s) to motivate real interest,
as few can bother to "interoperate" with pp(s) without standards, with
the notable exception of Micro$oft, which Veri$ign isn't.

While we're on the subject of predisposition towards dubious solutions,
could we _please_ loose the recommendation (lines 52 and 53) from the
requirements. (draft-ietf-idn-requirements-every-week-now.txt)

In section 1.4 a _laborious_ discussion of characters in the DNS can be
simplified at line 240. The protocol is UDP, and the appropriate unit is
bytes (see rfc768).

I'll have to stop here. More later.
Eric
no mention

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 26 Jun 2001 10:55:43 +0800

I would like to echo Marc comments here. I think compression should be
first most important criteria over complexity.

-James Seng