Re: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https

[Mark Nottingham <[e-mail]>]

> On 28 Jun 2017, at 1:50 am, Patrick McManus <[e-mail]> wrote:

>> The GET-style request in your example (which I think is pretty representative) uses 44 octets to encode the body; the POST serialisation is 33 octets. However, with HPACK's huffman encoding (remember, you're requiring HTTP/2), that goes down to 34 bytes.
>> 
>> Are we really that sensitive to on-the-wire size? To me, the cache efficiency gains as well as simplicity more than make up for a 3% difference. The statement that "POST-ed requests are smaller" isn't going to be true, in pathological cases.
> 
> So size is one concern that motivates the POST definition but there are others that should probably be articulated. Most significantly request header mechanisms that apply to the request message body don't apply well to GET other than the content-type encoded into the GET URI (which is a rather unfortunate wart without adding more such warts on). From a size perspective obviously compression might be a win for POST but not for GET but I'm also trying to be a pragmatist when thinking about whether 415 applies naturally to the GET mode.
> 
> If we were to have only one, and that is a reasonable thing to at least discuss about a standard (the current situation is definitely a tradeoff, though one I support), I'd actually be inclined to go POST only to more naturally delineate the messages in each direction. That of course leads to the cache discussion - and we know as spec-heads that there's nothing wrong with caching POST in this model - but we also know that it won't happen. Thus this flavor of  pragmatism while acknowledging there are 30 other flavors available on the menu.

If it's just Content-Type, I think putting it in the URL is fine, and would prefer a GET-only solution.

If it's going to be more complex than that, I'd recommend that the well-known resource actually be a "directory" / "map" / "home page" document that explains how to interact with the DNS API server, rather than baking everything into the URI. It'll give you far more flexibility for future changes, and AIUI in the use cases for this, it's not onerous to do a single up-front discovery RT.

BTW - If I were to nit-pick here, I'd say that you don't need a well-known URI for this; there's no reason that a DNS API server couldn't be configured with a full URI, instead of a hostname / port pair. 


>>  Why shouldn't DNS API servers be able to generate ETags based upon their internal state, to reduce outbound bandwidth?
> 
> we should give it a full airing wherever this gets dispatched to, but 2 thoughts:
> 1 - iirc this boils down to an interaction between the DNS TTL embedded in the response and the 304.. you really do conceptually need a new DNS entry, but if its byte-for-byte the same I agree the server could 304 that with appropriate cache controls. we should figure out the right language to thread that needle.
> 
> 2 - these responses are good candidates for immutable

Fair enough. Just didn't want to discount validation out of the gate.


--
Mark Nottingham   https://www.mnot.net/