In message <86mx8kqpy7....@seastrom.com>, "Robert E. Seastrom" writes: > > valdis.kletni...@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: ma...@isc.org
