[This message contains responses to D. J. Bernstein and Eric A. Hall regarding related issues.]
"D. J. Bernstein" <[EMAIL PROTECTED]> wrote: > > the man page does not specify the output format of dig > > Actually, the dig manual page clearly states that dig prints answers > from name servers. There is only one printed DNS record format in > BIND, namely BIND's zone-file format, which is documented in detail > and meant to be machine-parsed. I don't see any mention of RFC 1035 or "master file" or "zone file" in the dig man page, but let's go ahead and suppose that the output format of dig is indeed the RFC 1035 master file format. In that case, IDNA section 3 requirement 1 *prohibits* dig from outputing the non-ASCII form of domain names. So there's no problem, mail does not bounce, the sky does not fall. "Eric A. Hall" <[EMAIL PROTECTED]> wrote: > As we can see, a Message-ID header field that includes decoded output > from an ACE-encoded IDN is not a valid Message-ID. Exactly right. Therefore RFC-822 compliant mail programs will not put non-ASCII domain names in a Message-ID field. An RFC-822 compliant program faced with the task of putting a non-ASCII domain name into a Message-ID field will call ToASCII if it's IDNA-aware, otherwise it will have no option left but to return an error to whatever handed it the non-ASCII domain name. It was the calling program's error for passing a non-ASCII domain name to a non-IDNA-aware program, or it was a human error for piping data into a program that doesn't understand the data format. As in the dig example, any program with a well-defined pre-existing output format that includes domain names is prohibited by IDNA from outputting the non-ASCII form (unless it redefines the output format). But if the program does not define its output format, then making assumptions about the output format (like assuming that it won't change in the next version) is an inherently risky business, and people who write scripts that pipe such output into other programs are deliberately choosing to take that risk. (I'm not saying they shouldn't write such scripts, just that they should accept responsibility for the consequences of their unfounded assumptions.) AMC
