[idn] RE: China

[Andrew Draper <ADRAPER@altera.com>]

Sorry for the delay in replying, I've been on holiday.

On 28 Jan 00 Harald Tveit Alvestrand wrote:
>
> At 10:04 27.01.00 -0800, Andrew Draper wrote:
> > >    UTF-8-based solution implies a need for extensive testing of
> > >    implementations to make sure that they accomplish the necessary
goals.
> >
> >Does this imply a requirement that the protocol shouldn't send non-ASCII
DNS
> >labels to servers which aren't expecting them?  To resolvers which aren't
> >expecting them?
> 
> Possibly. A label type combined with an EDNS0-like version scheme would 
> make that easy.

Yes, that was what I was expecting to specify in order to prevent resolvers
from getting characters they don't expect.  I'm not sure how that can be
made to work for servers without generating extra traffic, hence the
discussion below.
 
> >However, who knows how many resolvers are out there built into printers
and
> >the like.  I expect that some of these will be quite fragile.  So I would
> >suggest adding "Should not send non-ASCII names to resolvers which don't
> >support IDNs" to the requirements.
> 
> There are 2 classes of failure:
> 
> - Fall-over-and-die failures; those are arguments for the SHOULD NOT
>    (or rather a MUST NOT) requirement.
> - Doesn't-look-nice failures; those I would place far less weight on.
> 
> The current (NU, IDN) tests should give us SOME idea.....if anyone's 
> measuring....

My guess (and I have no data to back it up) is that some clients might have
fall-over-and-die type failures when presented with certain types of DNS
label.  Hence the suggested (weak) requirement that these sort of failures
be minimised, whether by using UTF-5 or EDNS options or whatever.

Regards,

    Andy