> On 9 May 2017, at 2:29 pm, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > > On Tue, May 09, 2017 at 11:20:30AM +1000, Mark Nottingham wrote: >> Hey DKG, >> >> Throwing my .02 in, although it's similar to what you've heard from >> others upthread -- >> >> I wouldn't do this for h1; it'll be an interop nightmare. H2 gives >> you the properties you want and the implementation / testing burden >> is much more realistic. >> >> For H2, I wouldn't use an ALPN token; define a new frame type or two >> that you can send optimistically before SETTINGS sync, stopping them >> if you don't get the right SETTING from your peer. Realistically, >> this is going to need to be configured into the client anyway, so >> there's some amount of pre-arrangement. > > I don't think what you are saying is workable. > > From what I can gather, the intention for this thing DKG gave is to > be pure TLS-wrapped DNS from the client side. Any SETTINGS or otherwise > from the server breaks this. And it can not use any odd ALPN values > either. > > This impiles this thing can't be used with HTTP/2, as it is both- > sides-send-first, instead of client-sends-first. > > Yes, if you try this with random HTTP server, it will choke. The > intention is that the client knows via configuration that the HTTP > server is capable of DNS demux. > > > The schemes for riding DNS on top of HTTP or HTTP/2 framing structure > are totally different thing. Those are obviously more compatible with > HTTP/2. Sorry if it wasn't clear -- what I was saying was "don't do this (DKG's proposal); do that (DNS-over-HTTP)". -- Mark Nottingham https://www.mnot.net/Received on Tuesday, 9 May 2017 04:32:54 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC