On Aug 21, 2014, at 8:18 AM, Andreas Gustafsson <[email protected]> wrote:
> 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. On Aug 21, 2014, at 8:27 AM, Shane Kerr <[email protected]> wrote: > I think you're making it too hard. Control characters, ", and \ are > already required to be escaped. Just specify a similar requirement for > octets 127 to 255 also be escaped, and we're done. Andreas' and Shane's requests differ. And they both ignore the fact that JSON defines strings as Unicode characters, not as octets. The escaping "defined" in RFC 1035 does not say where it must be applied. Note that the definition of a string in JSON is: string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF Given this, and the likelihood that escaping is going to screw up NAME/QNAME exactly where it will be needed the most (to get the exact octets of an odd name), I think making NAME/QNAME only hold hostnames, and non-hostnames must be in a different field that is hex-encoded, will be the easiest to get right. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
