On Sep 21, 2016, at 3:15 PM, George Michaelson <g...@algebras.org> wrote:
> I really like this document. I particularly like that it explicitly
> addresses how the JSON format it uses can represent *malformed* DNS
> state, as seen on the wire. This is very important, because some
> canonicalize-and-map-the-DNS efforts I've seen have focussed on
> well-formed packets, and this one stands out as saying "no, we have to
> be able to represent incorrect state, because that exists on the wire,
> and we need to show it sometimes"
> It has multiple encoding possibilities for the DNS RR. I'm a little
> confused what difference it makes, that you'd want 'all the things'
> here. If the argument is 'long crypto hashes are better done as
> base64' then why do we have the hex at all?

Hex is easier to type for short blobs.

> Is that to preserve
> bit-field legibility for instance? Or, to encode unintelligible
> off-the-wire sequences which present as a valid RR but you can't
> decompose into their constituents? Maybe its just a little guidance
> when you saw the hex being used? rather than B64.

Really, it's just there because some people prefer one way over the other for 
some fields.

> Do you need to be explicit that transform through this JSON would
> permit re-emission of the wire content onto a network, and have the
> packets function? Is that even a goal?

Not a goal. (Particularly for badly-formed DNS responses :-) )

> The streaming reference sort-of
> made me think this might be a goal, but it wasn't explicit to me in a
> cursory reading.
> I think this is a good document. I think its close to baked for me.

Thanks! And thanks to the many folks who have suggested (and will hopefully 
continue to suggest) changes. It's way better than the -00.

--Paul Hoffman
DNSOP mailing list

Reply via email to