RE: [idn] some comments about draft-ietf-idn-idna-08.txt

["Codogno Maurizio (Rozzano)" <m.codogno@saritel.it>]

Adam:
Well, I hope I did not cause too much of a feud!

Actually I followed closely the first year of activity in the 
group, so at least I had a starting point. Some of the comments
I made tried to be from the side of the casual implementor.

[Sect. 4.1., para 4.]  

IMHO, adding the sentence "ToASCII fails if any step of it fails" 
is enough to clarify the algorithm.

> > Sect 3, req. 2). "An equivalent domain name".  It is a *unique*
> > equivalent domain name, right?
> 
> Not necessarily.  Punycode and ToASCII don't say whether uppercase
> or lowercase ASCII letters will be used in ACE labels. 

oops... I forgot that mixed case may happen. You are quite right,
of course. I only wanted to point out (again, since the concept is
stated elsewhere) that up to upper/lowercase the conversion is unique.

> By the way, an editing error in this paragraph was fixed 
> between idna-08
> and idna-09.

I just found it in the site for the group. Was it already officially
issued?

[ACE labels]
> We make one general recommendation regarding user interfaces: 
> try not to
> show ACE to users unless they ask for it.  I don't think it's 
> our place
> to get into the specifics of how the user asks or how the ACE 
> is shown.

Ok, I think I understand it. My concerns were on the line of 
"if a Unicode character may not be displayed, it could be useful
to show the original string so that the user could notice the 
difference", but you are right: it is an application issue and it
does not belong here.

> > Sect. 8. Why EDNS has not been included in the specifications?
> 
> The whole point of IDNA is that it doesn't depend on any changes to
> the infrastructure, neither the DNS infrastructure nor any other
> infrastructure (like mail relays and web caches).  The STD-13 DNS
> service is entirely sufficient for IDNA; EDNS is not needed.

Of course it is not *needed*, but I was thinking at something a bit
different. EDNS could have been shown as an *example* of a possible
solution to the lengthening of labels, without any endorsing. 

> > As a side issue, I'd like to be pointed at some heuristic 
> data about 
> > Punycode.
> 
> I compared Punycode (back when it was called AMC-ACE-Z) against some
> other algorithms:
> 
> http://www.cs.berkeley.edu/~amc/idn/ace-eval.gz

got it, thanks.

Thank you again, .mau.