I'm sorry to hear that. I would like to provide some information as a background if it's useful.
dns-wireformat-http draft was originally proposed in DNSOP WG as a experimental draft in early 2016. We focus on the requirement of enhancing DNS availability bypassing the middlebox on the path via HTTP tunnel. It was later adopted in DNSOP WG as WG document. I think it was an original and sound work deserving us to work on at that time. However, it was postponed in 2017 and we are told that HTTP people has concern on it. At that time, draft-hoffman-dispatch-dns-over-https was proposed as a standards track aiming to defined HTTPS as substrate transport for DNS which is different from the DNS over HTTP tunnel case. Later DOH was created forcusing on HTTPS as DNS transport protocol. We were told that the proxy and tunnel case is not in the scope of DOH but we are suggested use the technology developed in DOH. At that time I still think it is valuable to introduce a use case of DNS over HTTP tunnel and define necessary protocol. The compromise is that we drop the free use of HTTP(without TLS) and HTTP 1.x because DOH has mandatory requirement on HTTPS and HTT /2. When I submited dnsop-dns-wireformat-http-02 weeks ago, I asked if we could introduce a optional parameter which is bettern than a new media type "application/dns-tcpwireformat". I suppose that optional parameter should defined in dnsop-dns-wireformat-http-02 instead of DOH draft. However, after original_transport optional parameter was defined in 05 version of doh draft, I'm afraid it was enlarged its scope to contain the proxy/tunnel case which make people think dns-wireformat-http is useless. I'm confused. So I would like to ask folks in the two WGs how to proceed: 1) Should dns-wireformat-http draft insists on the original defination of DNS over HTTP(s) tunnel with new HTTP header as a experimental document? Because that is the original experiment we have done to show the capacity of DNS over HTTP(s). 2) If the answer is no, how should dns-wireformat-http draft align itself with DOH document. My suggestion is to define the original_transport optional parameter in dns-wireformat-http draft. Or Is there any other way out not abandoning our work? As the co-author I still want to rescue it. -Davey On 4 April 2018 at 10:35, Martin Thomson <martin.thom...@gmail.com> wrote: > On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman <paul.hoff...@icann.org> > wrote: > > Martin: Are you saying that you want DOH to remove the optional > parameter from the application/dns-udpwireformat registration? If so, what > do you propose for the DNSOP WG? > > Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'll > concede that I'm probably missing something. > > By my current understanding, draft-ietf-dnsop-dns-wireformat-http is > indistinguishable from a specific implementation of > draft-ietf-doh-dns-over-https. That is, if a DOH server wanted to > service all its queries by forwarding requests to a resolver [1], I > can't see how that would be disallowed by DOH, and that's exactly what > draft-ietf-dnsop-dns-wireformat-http appears to describe. > > Convince me that this isn't the case (or not, and I'll be in the rough on > this). > > --Martin > > [1] ...after randomizing the ID. > > _______________________________________________ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
