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

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".


> _______________________________________________
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
DNSOP mailing list

Reply via email to