Thanks for the comments! 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. I could reverse the logic and say QNAME/NAME are hostnames, and thus plain JSON strings in ASCII (which is by far the most common thing), and then have a different field for nonHostQNAME* and nonHostNAME* for when the QNAME/NAME. However, there would then need to be a way to indicate that the QNAME/NAME was not representable as a hostname. "" is OK, but then we would have to say that the root would always have to be represented as ".", which is not true now. To avoid that, I went with QNAME/NAME being as 1035 defined them, but I'm willing to think about other possibilities. > * In general I'm not super enthusiastic about the mixing of binary and > formatted data - I tend to think an application will want one or the > other. Perhaps it makes more sense to define two formats, one binary > and one formatted? Or... All fields are optional, so a profile could say "don't include these" or "always include those". Further, and more importantly, most RDATA are binary. I did not want to force implementations to use the presentation format for RDATA. > * Maybe it makes sense to define a meta-record so consumers can know > what to expect? Something that lists which names will (or may) appear. That would be a JSON schema. Just using that phrase will cause screaming in the Apps Area. Having said that, it's perfectly reasonable for a profile to insist that each record have a profile indicator such as "Profile": "Private DNS interchange v3.1". > I'd be mildly curious to see a comparison of the compressed sizes of > JSON-formatted data (without data duplicated as binary stuff) versus > non-JSON-formatted data. My intuition is that compression will remove > most of the horrible redundancy that is involved in JSON, but there's > only one way to be sure. ;) Sure. It's pretty trivial to do, for example, a CBOR format that follows this; there are now CBOR libraries for most popular modern languages (see http://cbor.io/). If folks here want that, I can add it as an appendix. To be clear, however, I haven't heard anyone saying they want compression so badly they are willing to lose readability of the data. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
