Paul Hoffman wrote: > On Aug 21, 2014, at 1:22 AM, Shane Kerr <[email protected]> wrote: > > > * I don't like the treatment of QNAME*/hostQNAME, NAME*/hostNAME, and > > so on. Since JSON includes encoded strings, wouldn't it make more > > sense just to always put the QNAME in there? (Especially since you'll > > end up with SRV queries always being encoded as they have underscore > > characters...) > > JSON requires its strings to be encoded in a particular character > set. Given that the labels in a QNAME/NAME can be an binary cruft, > you can't assume that every QNAME will be representable.
There already exists a standard mechanism for representing this binary cruft in the JSON-safe subset of ASCII, namely the \DDD notation of RFC1035 section 5.1. If you simply require the use of this notation for any non-printable characters in a label, the resulting string will be representable in JSON, and there is no need for separate NAME and hostNAME encodings. One potentially confusing aspect of this is that the backslashes will then be subject to a second level of escaping by JSON. But there's no escaping (pun not intended) the fact that we are doing two layers of translation: first from wire format binary data to human-readable dotted names, and then from human-readable names to JSON syntax. An implementation that uses existing, correctly implemented libraries for each layer of translation will automatically do the right thing: the DNS library will translate the length-prefixed wire format strings to dot-delimited ones *and* do \DDD escaping, and the JSON library will add a set quotes around the string to make it a JSON string *and* double any backslashes. -- Andreas Gustafsson, [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
