Paul, At 2016-09-05 10:21:40 -0700 "Paul Hoffman" <paul.hoff...@vpnc.org> wrote:
> On 5 Sep 2016, at 0:47, 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?
> > 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.
> > 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...
> > It occurs to me that maybe we want an option to have arrays of RRset
> > instead of arrays of RRs?
> >
> > "answerRRsets": [ { "NAME": "example.com",
> > "TYPE": 1, "CLASS": 1, "TTL": 3600,
> > "RR": [ { "RDLENGTH": 4, "RDATA*": "C0000201"
> > },
> > { "RDLENGTH": 4, "RDATA*": "CB007181"
> > }
> > ]
> > }
> > ]
> >
> > It's not super important, but it would save me having to build RRset
> > in
> > my applications. (With the RRs only I have to loop through the entire
> > section and only when done can I know that I have gotten a complete
> > RRset.)
>
> Instead of a new "answerRRsets", how about if I invent an "RRset" object
> and the change the definitions of the various sections to "answerRRs --
> Array of zero or more resource records or RRset objects in the Answer
> section"? That way you can mix and match records and RRsets.
Sounds good!
--
Shane
pgp1KrGeLNJCg.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
