Re: [dnsoverhttp] Fwd: New Version Notification for draft-hoffman-dns-over-https-00.txt

[Patrick McManus <[e-mail]>]

Thanks Martin.

On Wed, May 3, 2017 at 11:52 PM, Martin Thomson <[e-mail]>
wrote:

> On 4 May 2017 at 13:15, Patrick McManus <[e-mail]> wrote:
> > A new version of I-D, draft-hoffman-dns-over-https-00.txt
>
> A few nits only; I need to think more about how this fits into the
> ecosystem.  I am warming to the notion that you have flexibility in
> representation format, that's a key advantage of using HTTP.  You have
> neatly punted on the hard parts of that by choosing the dumb option to
> document, which means that you can bootstrap effectively.
>

ack - and I believe Paul has a JSON media-type document going on a separate
path that should dovetail nicely,  but not be a blocker. I certainly would
hope to see some JSON in the wild.


>
> The query string uses one of the worst encodings known to man.  Did
> you do any analysis here?  Is base64url bad for some reason.  For
> instance, I would believe that it increases the length of the string
> in the aggregate if you told me.
>

will open an issue for more analysis.. did one example by hand and it was a
~wash size wise.. and the hex made a clearer example :) more study would be
good, but its a micro opt given the existing bounds on the sizes involved.


>
> You should use a parameter name for the query string so that you at
> least have the chance to automatically discover a service and make
> requests in other forms using the query string without sniffing or
> other such horrors (conneg works fine for the POST variant, but you
> are pushing those uses to a method that isn't a great fit).  What you
> have consumes the entire usable space in the query string, so it would
> be hard to get in edgewise with an alternative query form.
>

so this is interesting. I started down that road, but couldn't really
figure out how to do any form of negotiation beyond the MTI with it so just
stuck with the simpler variant you see in -00. 415 seems to apply
specifically to content-type and bodies so wouldn't work as a signal. Or am
I being too pessimistic?

Strictly speaking we don't need the uglier GET variant at all - the POST is
absolutely cacheable. But realistically speaking that will not work with a
lot of existing caches.



> Do you really need to encode the ID?  I realize that might be
> construed as opening the floodgates, but it is going to make caching
> that much more fragmented.  Can you not just trim it off?
>
>
low friction of using an existing (albeit encoded) format traded off vs a
couple bytes... that is why the normalization of ID SHOULD is in there tho.