> 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
