Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

["Eric A. Hall" <ehall@ehsco.com>]

"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <ehall@ehsco.com> wrote:
> 
> > > Now I finally see an argument for why DNS servers in practice do
> > > comparisons that way.
> >
> > Great.  Can we make IDNA a dumb codec now?
> 
> I can't tell if that's a deliberate non sequitur (meaning "Okay, can we
> drop this topic and get back to a more important one?"), or if you see a
> connection between my statement and your suggestion (I don't).

I forgot the smiley, but I am serious.

Now that we are all a big happy family and agree that all labels are
treated the same, we need to agree that all i18n labels will *ALSO* be
treated this way. IOW, IDNA applies to any domain name defined as a
profile of stringprep, and is not dependant on nameprep.

This means that IDNA takes i18n labels as input and gives ACE as output
(and vice-versa). IE, just one codec. No new codecs for localpart or for
NetBIOS or for KERBEROS or anything else.

This is required for IDNA to be useful, but it is also necessary for
coordinating EDNS and IDNA. A system faced with an i18n domain name on
input shouldn't have to say "well I can send it straight through in EDNS,
but I'm afraid you'll have to do something else with it if you want STD13
because it isn't nameprep".

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/