On 5 Sep 2016, at 21:44, Shane Kerr wrote:
First, it seems like it might be nice to have a way to express RDATA
in
DNS presentation format. The document is very clear that no way is
provided for this, but it seems like it would be really, really
useful.
If it useful for a particular application for particular RDATA, that
application could easily specify a format in its profile. If that
catches on, I could update this document with a collection of those.
But
I don't want to start now by specifying the formats I would want
myself.
Hm... I guess I don't see why the DNS-in-JSON draft can't simply say
that the formats are those documented in the RFC for any particular
RTYPE? Each RTYPE has a defined format, right?
Sure, but some of those types don't have definitions of names for the
presentation format, and some of the early ones have less-than-clear
names. Also, for RTYPEs that have multiple parts to the RDATA, what
would it mean to get an answer that had only some of them?
Next, is compressedNAME likely to be useful? I'm not arguing
strongly
against it, but since it involves pointers and those are not going
to
be useful with a JSON object, I don't really see much point.
I doubt they will be that useful, but a receiver might want to know
which names in a message were compressed and which were not. I admit
that it would be clearer for that receiver to just look through the
message or section binary fields.
Maybe it could be a value that describes something like this:
"compressedNAME": { "isCompressed": "yes", "length": 7 }
The "length" would be the compressed length. The uncompressed length
can be found by looking at the name.
Good suggestion!
I don't see any mention of whether things like TYPEname and
CLASSname
are case-sensitive and if they are not which case they should be. My
recommendation would be to make them case-insensitive, although not
every field can be so having to tag each might be a bit much?
Well, this brought up an ugly problem. The name in the IANA registry
for
class 1 is "Internet (IN)". Chaos and Hesiod are similarly bad. I'm
going to change the definition of the class names to be 'String whose
value is "IN", "CH", "HS", or has the format in {{RFC3597}}'. I don't
think I really need to add to TYPEs that the name is case-sensitive,
since it says "from the IANA RR TYPEs registry".
Makes sense. Stupid DNS classes. :)
Can you explicitly say that TYPEs are case-INsensitive then? It might
save some poor coder at some point, since programming languages
generally default to case-sensitive comparisons...
No, but I will say the opposite, which is more deterministic for
receivers.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
