Re: [Doh] re original_transport indicator

[Martin Thomson <[e-mail]>]

On Sat, Apr 7, 2018 at 9:29 AM, Paul Vixie <[e-mail]> wrote:
> my original design added an http header, which was seen as even worse.
> someone suggested adding to the content-type, and i went along with it even
> though there is no difference in actual type of actual content.

A header field isn't all bad.  At least from my perspective, anyway.
That said, it is true that adding to the content is a better choice.
I appreciate that this isn't a great fit in this case.

> 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

.../request{?dns}{?proto} is the way you would write that.

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

I agree with this principle, and have expressed similar concerns with
the name.  However, I just checked the media type registry [1] and I
think that a better choice is message/dns.  Just like message/http and
message/sip.

[1] https://www.iana.org/assignments/media-types/media-types.xhtml#message