Comments on draft-ietf-idnabis-defs-10

[John C Klensin]

--On Tuesday, September 01, 2009 13:52 -0400 Andrew Sullivan
<ajs at shinkuro.com> wrote:

>> So an application doesn't _have_ to convert it to U-label,
>> and goes ahead to lookup the domain name. This would be true
>> of non IDNA-aware applications, as well as conforming
>> IDNA2008 applications that chooses the easy way out (it just
>> cannot display the label in native form.)
> 
> Yep.  This is also true, however, if it makes a DNS resolution
> attempt for (say) xn--bobsyeruncle, or anything that, when
> decoded back to Unicode, turned out to have some other
> DISALLOWED character in it. Generally speaking, it's a bad
> idea not to validate the labels.  Maybe that text needs to be
> more clear?  Perhaps the MAY ought to be a SHOULD?

Just as an explanation (not taking a position on this -- as far
as the documents are concerned, I'm waiting for instructions):

The reason for the MAY was to avoid seeming to impose
restrictions on non-IDNA-aware applications that received
A-labels and intended to look them up.  The reasons for not
going into that space are fairly clear --and you are one of the
ones who has argued for keeping a safe distance -- and have been
picked up again elsewhere in this thread.

We could impose a full validation requirement on IDNA-aware
applications, but it seems to me that involves a tradeoff: on
the one hand, we would really like to encourage the use of
A-labels in URLs and similar contexts, but a validation
requirement would make using A-labels more costly and
problematic than using U-labels.  So I'm not sure that is a good
idea.

On the other hand, requiring that IDNA-aware applications verify
that all characters are lower-case even if they don't do full
validation seems just about as plausible to me as recommending
lower-casing.   The IDNA-unaware applications would, of course,
remain at the mercy of registries.

     john