Re: [DNSOP] DNS-in-JSON draft

["Paul Hoffman" <[e-mail]>]

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