Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)

[Erik Nordmark <Erik.Nordmark@sun.com>]

> I'd like to give those future designers the
> opportunity to make choices about whether to use IDNA (or ACE
> generally) to handle internationalization, the ability to think
> through whether more of the normalization or matching processes
> should be moved to the server, rather than being handled
> exclusively in the client, etc.  I don't want (or need) to
> predict what they will conclude, but I think it is unnecessary
> and dangerous for us, at this stage, to write what seems to be
> an "all internationalization uses IDNA, now and forever,
> including in RRs and Classes and uses of the DNS we have no way
> to anticipate" rule.

John,

I'm trying to understand why, if e.g. the community goes down
the path of doing a new class, why such a specification can't update the
IDNA RFC to e.g. say that IDNA now only applies to class=IN
(or whatever is approiate). That specification will need to also
specify how QCLASS=ANY is handled, etc, etc.

If we declare that IDNA needs to restrict itself (e.g. to class=IN)
then it seems like we need to solve the QCLASS=ANY issue now.
This seems suboptimal both because the work might be wasted (if a new
class protocol isn't pursued) but worse, the solution might be broken 
since we have no way of predicting what the new class proposal might need
with respect to QCLASS=ANY.

I think there is a separate issue whether the rules for QNAME and RDATA
domain name slots should be the same, or e.g. whether the RDATA slots
in SOA, CNAME(?), etc should use different nameprep (e.g. to allow
different case, or to allow any codepoints). I think that issue can
be decided without having to be able to predict the future.

> I am suggesting that (i) it should still be possible to use
> IDNA, but with a different profile and (ii) we should not, as a
> side effect of the way we specify IDNA today, prevent that RR
> from being defined, regardless of whether it can use
> IDNA+different profile or whether it needs to use an entirely
> different protocol to set up, compare, and map names.

I don't think there is anything that prevents this, but it might be a bit
cumbersom. For instance, a new definition could say "apply ToAscii with
step 2 replaced by foo" where "foo" is something different
than nameprep. (And  similarely for ToUnicode).

As part of my review I explored if there could be a better separation between
nameprep and the other parts of IDNA, but that seems to result in different
handling of case for all-ASCII labels.
If nameprep was separable from ToASCII it would need to be the first step.
This would mean that all-ASCII labels would be case-folded, which they
are not as ToASCII is specified. Hence an application using IDNA
would potentially display different case for non-IDNs to users.

  Erik