Re: [DNSOP] New draft on representing DNS messages in JSON

[Paul Hoffman <[e-mail]>]

Thanks for the comments!

On Aug 21, 2014, at 1:22 AM, Shane Kerr <[e-mail]> 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