On 2/23/15, 2:52, "Patrik Fältström" <p...@frobbit.se> wrote:
> >> On 22 feb 2015, at 20:58, Paul Hoffman <paul.hoff...@vpnc.org> wrote: >> >> As for Måns original question: converting wire-format IDNA to some >>encoding of Unicode characters is unstable because some registries use >>IDNA2003 rules, others use IDNA2008 rules, and some labels in the former >>can't be represented in the latter. Yes, IDNA2008 obsoleted IDNA2003; >>that is irrelevant to the a good chunk of the operator community. > >It is correct that the policy for what Unicode Characters are allowed >have changed over time (even for IDNA2008 it changes when the Unicode >version changes). > >But the _encoding_ of the characters is the same. > >So maybe some of the "maybe disagreements" are not disagreements after >all? Okay, before getting too silly on this, IDNA is a convention for representing identifiers in non-ascii/latin scripts into DNS labels, for the purpose of restricting what can be registered to prevent confusion. (Okay, okay, for providing a unique and reversible way to transliterate between the printed and on-wire forms.) But there’s nothing stopping me in the DNS protocol from putting arbitrary binary garbage in a label even if it wouldn’t be very useful to a human if I did. I.e., the domain internet groper tool (version 9.10), distributed by the Internet Software Consortium, can report this in an AXFR reply: \000\001\002\003.example. 600 IN TXT "binary label” I put that into a zone file using \DDD format, loaded it into a name server and it served it up. Not IDNA, but very DNS. (Side note - don’t let top-level domain operational considerations blind us to how the underlying protocol works. E.g., IDNA is a convention, not a protocol change, in how one reads labels outside of the DNS arena, such as business cards. I say this because a lot of the operational input to the DNS document set is from TLD operators - who have a lot of real good experience and see a lot of the packets - but is not entirely representative of the way the DNS eco-system is run.) Zone files are a way to represent what is meant to be in-memory for a zone in a “file.” While it makes sense to, one doesn’t have to convert labels the same way for zone files as is done under IDNA. In the example above, I used the STD 13 convention of \DDD. One could put in UTF-8 or UTF-16 or whatever suits them in files. As I said, this is silly talk and perhaps I’ve been bit too loose with language. If someone feels the need to fix what I’ve said, go ahead, please. What I have in mind (to solve) was seeing some zone master files with UTF-8 entries. There’s nothing inherently wrong with that except that my parser assumed letter-digit-hyphen only. The producer of the zone files had been asked to submit them in LDH but made a mistake, probably because it was early in the reporting and the request wasn’t clear enough. My goal is just to clearly define and put a name in the desired format in a definitive reference document. BTW, thanks to the participants in the thread. I am aware of “all of this” (as someone who’s written the code before) but the refreshers on references is very helpful. Consider this a desire to bring up the written word to the state of the code, which is what the IETF documents are about.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
