Re: [DNSOP] DNS-in-JSON draft

[Shane Kerr <[e-mail]>]

Paul,

At 2016-09-05 10:21:40 -0700
"Paul Hoffman" <[e-mail]> 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