Re: [dnsoverhttp] DNS wireformat in JSON draft

[Paul Hoffman <[e-mail]>]

On Sep 21, 2016, at 10:56 PM, Martin Thomson <[e-mail]> wrote:
> 
> (Starting a new thread for this stuff)
> 
>>> Frankly, I don't think that the JSON spec is anywhere near as ready as
>>> your proposed protocol spec, so I'm surprised to hear you want to push
>>> it out with an RFC number on it.
>> 
>> As I keep saying, I'm quite open to comments on it. I've gotten plenty from the DNS community over the past few years, but we could have missed stuff you're seeing.
> 
> Here you go then:
> 
> What draft-hoffman-dns-in-json describes is worse than having to parse
> the DNS wire protocol.

Yes and no. Yes because the receiver has more ways to do things and has to specify to the sender what it wants to receive. No because (1) name compression turns out to have ugly edge cases, (2) escaping, and (3) parsing badly-formated responses is really really hard. The original use case for the JSON format was a receiver who wanted to know just a few common values for a huge amount of traffic.

> This is because it assumes that you have name compression, and all the
> crap that the DNS wire protocol includes

Yes, of course.

> , PLUS the added complicates
> of JSON and base64 (and base16).  

True. I am open to getting rid of one of the optional encodings.

> If the goal here is to make this
> format accessible in a way that DNS never has been, you can't just do
> a mechanical translation of the wire format.  

That was never my goal, but I hear it is a goal for you and others here.

> That does no one a
> service - application developers find the format unusable and the DNS
> people want their wire format back.  With what you have, you might as
> well go with the binary format and leave people to mess with
> ArrayBuffers and the like.  That would be a shame.
> 
> On the other hand, if you want to make this usable, then make it
> usable. Ditch the name compression.  

... you didn't read the revised draft I put out yesterday...

> Translate the contents of the
> common RRtypes into usable forms, don't just dump RDATA on people.

Define "common" for you. Seriously, that's easily done. However, for the DNS folks, uncommon is just as important as common.

> Don't use "*" or "!" in your names.  

... you didn't read the revised draft I put out yesterday...

> Don't use both base64 and base16.

Noted; can do.

> Don't use \DDD encoding.  

That requirement means "when encoding from a zone file to this format, you MUST do a conversion". You are just trading unfriendly to the recipient with unfriendly to the sender. It's fine for a profile to say "values with \DDD encoding will be rejected", but I think it is wrong to put that in the protocol itself.

> Don't use 0/1 for boolean fields.  

Noted; can do. (Well, *should* do. This was me being lazy.)

> All of
> these things are very hostile to application developers.

They are hostile to developers of *receiving* applications. Some of what you ask is hostile to the sending applications.

Having said that, I'm open to making the format less balanced between the two, picking one side over the other, and picking the receiving side. I just want you to be clear that is what you are asking for.

> Then you can include defaults for fields and look at other usability
> improvements.  

Quite true.

> Then you might have something that an application
> developer will want to look at.
> 
> In the end, you are making the server do more work to produce a usable
> format, but do it right and it's fairly easy.  There are a lot more
> producers than consumers in this space and the consumers will thank
> you for it.

My view was that if there are more producers than consumers, you should make the producers' life easier. I hear that might be inverted.

Other folks: please chime in!

--Paul Hoffman