On 7 April 2018 at 07:29, Paul Vixie <p...@redbarn.org> wrote: > > > i am generally supportive of this approach; in fact i wish i'd thought of > it. the specifics will be different, as in: > > /proxy_dns?proto=tcp > /proxy_dns?proto=udp > > but i agree that encoding the original transport in the URI is better than > either extending the content-type or adding another http header. >
It sounds a better approch. We can define the variables "proto" in dnsop-dns-wireformat-http instead of adding a parameter of content-type. There is a sentence in DOH draft support new variables in URI. Future specifications for new media types MUST define the variables used for URI Template processing with this protocol. I think it should edited a little bit : s/ new media/ new media types and new use cases i object, as before, to "dns-udpwireformat" as a name. these are dns > messages, which when carried by udp are raw, and when carried in tcp are > preceded by a two-octet length indicator for framing of multiple messages > sharing the same stream. so, the string to be registered should be > "dns-message". > > +1 Davey > > _______________________________________________ > 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
