On Wed, Jan 06, 2021 at 06:10:58PM -0500, Viktor Dukhovni wrote:
This is a mistake that confuses input processing with output processing.
Not necessarily. I think the implementor could decide that you're either doing IDNA or you're not, and if you expect non-IDNA stuff to be returned you should turn off IDNA (which is presumably why it's off for non-TTYs). I can easily imagine an implementation of a tool that simply will not return things to you if it's not IDNA-conforming. (I can see an argument also why that might be surprising, but that's a different matter.) This is in some ways akin to the browser rule that it won't show you a U-label unless it happens to be "in your configured language" (which, FWIW, I think has its own surprises).
When converting the first label to presentation form, which does not since it does NOT start "xn--", applying IDNA rules makes no sense at all.
I don't think that's what 5890 says. It says 'For IDNA-aware applications, the three types of valid labels are "A-labels", "U-labels", and "NR-LDH labels",' so a label starting with - is just invalid, no matter what. You're arguing, I think, that for a tool like dig, taking a domain name off the wire and restricting that domain name to IDNA is wrong. I think it's an implementation choice regarding what one is supposed to do with invalid data coming from the wire, but it's pretty clear it's surprising to at least some people in this context. Note that IDNA2008 does expect implementations to do local processing on domain names, and it's an interesting question whether that includes things that come back from resolution: the entire thing is written as though there's user input that is then converted for lookup, but this particular case seemed originally to crop up in the context where IDNs are probably unexpected but where IDNA was turned on. The point of IDNA was supposed! to be not just "least surprise" but also "internationalize LDH", and non-LDH labels just automatically violate that. Another way to say it is, if there's no eyeballs who need to read the identifier then you shouldn't use IDNA at all.
The implementation is correct, but the context is wrong.
The implementation is still not correct in any case, because it takes some NON-LDH labels and not others when IDNA is turned on, and that's bound to be incorrect under IDNA2008. (It strikes me that there might be another possibility, which is that dig is also attempting to work for IDNA2003, in which case this might still a bug but not in the way I was arguing.) Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
