On Wed, May 3, 2017 at 7:17 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > Hi Patrick-- > > On Wed 2017-05-03 14:57:24 -0400, Patrick McManus wrote: > > > My initial response is that legacy HTTP/1 implementations will sink you > by > > scanning for stuff that looks like HTTP in your stream - even if the > > leading bytes don't match the production those RFCs required (and > HTTP/1.0 > > is only informational anyhow). You can look at the websockets masking > > madness to see the lengths the community went to to avoid that kind of > > detection in rfc 6455. > > Are you talking about an existing HTTP/1 server implementation? > the whole ecosystem - so lbs, av, firewalls, etc.. roy makes a similar point. > > > Coincidentally I have a draft with Paul Hoffman that we're close to > > publishing, that describes how to do DNS over https:// in a way that I > > think will play better with both the http and dns ecosystems than > previous > > work in that area. It wouldn't be a http-wg item though, we don't > normally > > take FOO-over-HTTP drafts here. That might be a better option - if you > want > > to use the https port, and the https alpn token, perhaps the https > protocol > > (without constraining its future) is the right choice :) > > is the draft you and Paul are working on different than > ietf-dnsop-dns-wireformat-http ? Can they be reconciled? See my > its a superset of that -more aligned with HTTP than that draft, but it can also carry wireformat. your work doesn't break it anymore than it breaks h2 generally :) > response to Roy T. Fielding (upthread) for why the demux approach seems > cleaner and safer for clients as long as we're using stream-based > transport. > > I totally support the end goal here of dns looking like https.. but honestly I didn't hear anything about cleaner and safer. I heard that you wanted to use the https port, the https alpn token, and constrain the http protocol, but found the requirement to implement http burdening :) The most straightforward way seems to make dns look like https is to actually carry it in https. perhaps we could work together on making a dns client more capable in this regard? > I certainly wouldn't want this work to get in the way of > ietf-dnsop-dns-wireformat-http (or any similar proposal), but i don't > think it does. does it? > > --dkg >Received on Thursday, 4 May 2017 00:37:57 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC