"James Seng" <[EMAIL PROTECTED]> writes: > > The .nu operator supports IDNA, among other things (you also > > can sent UTF-8 and various local encodings to their DNS servers). > > This sound bad. This is breaking the basic functionity of DNS.
Can you elaborate? How does this break anything? They respond to strictly erroneous requests, with erroneous responses. I can't see how this could cause failures of other participants of the DNS. > RFC 2616 is silent. But IDNA did specify that for any other protocols, > unless it is updated to handle IDN, we will default the encoding to be > Punycode. So yes, Punycode should be used in Host:. That is not convincing. RFC 3490 says In protocols and document formats that define how to handle specification or negotiation of charsets, labels can be encoded in any charset allowed by the protocol or document format. If a protocol or document format only allows one charset, the labels MUST be given in that charset. So, I *could* interpret RFC 2616 as defining how to handle specification of charsets, as it is "MIME-like". Therefore, I infer that sending MIME-Version: 1.0 Host: =?iso-8859-1?q?www=2Ebrav=E5=2Enu?= is conforming to both RFC 3490 and RFC 2616. Regards, Martin
