In message <86mx8kqpy7.fsf@seastrom.com>, "Robert E. Seastrom" writes:
Valdis.Kletnieks@vt.edu writes:
On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said:
Challenge taken.
RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY specify, in addition, how to use other charsets [something DNS does not do, so it must be UTF-8]"
(ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :)
That requires overlooking the minor detail that the DNS RFC predates that by quite some time, and there's no combination of RFCs 2119 and 2277 that mandates retrofitting grandfathered protocols by fiat.
It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and as such isn't itself binding, merely A Good Idea.
Nice try though. ;)
Valdis, re-read the original assertion and challenge.
Your attempt at RFC lawyering appears to be "Experimental" <grin>
The Internationalised DNS uses IDNA suite of RFC's to encode UTF into A-labels. Before deciding to go the IDNA route, treating DNS labels as UTF-8 was discussed, evaluated and rejected. DNS labels are length tagged binary blobs with case folding of the 7 bit ascii values 'a'-'z' when performing lookups. If a server is fully compliant (and I don't think any is) answers should be returned in a case preserving manner, including owner names. The intent of RFC 1035 was to be able to use the DNS to store and retrieve binary data using binary keys. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org