On Sat, Apr 7, 2018 at 9:29 AM, Paul Vixie <p...@redbarn.org> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
