On 1 Nov 2016, at 10:54, Philip Homburg wrote:
I find it hard to believe that after compression, the BSON encoded
version of the DNS data would be a lot smaller than just the
raw DNS data.
Please note the use case in the draft: they don't want to burden the CPU
of the box with compressing with gzip, bzip, and so on.
A good, tuned compressor will end up making a jump table similar to what
this design has in order to make the output small.
The downside of CBOR, certainly as used here is that uses integers to
identify fields in what JSON calls objects.
So anybody who writes a local extension is likely to just continue
numbering
fields, which leads to mutually incompatible extensions.
This may be a misunderstanding of CBOR. A single CBOR object can have
keys of multiple types. This draft uses the smallest size keys (the
small integers), but that does not mean extensions need to use integers
at all. In fact, the spec should probably say "pick a key that is
unlikely to be used by anyone else" or "here's a trivial-to-get-into
IANA registry" (but not both).
In contrast, formats like XML, JSON, but also BSON where fields have
names
make it less likely that people will pick the same identifier for
completely different purposes.
I disagree on that point. I think that if a spec says "the defined keys
are 'a', 'n', 'x', and 'y'", and you have an extension you want that is
about security, you're likely to choose "s", which is also likely to be
chosen by someone else doing an extension on stability. You gotta have a
registry or much longer names in order to prevent name collision.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
