This is intended to do what? Indicate where the response came from? Why does the client care? I assume that it doesn't apply to requests, or that would get into draft-bellis-dnsop-xpf territory.
BTW, you really need to drop UDP from the media type name now. application/dns-udpwireformat;original_transport=tcp is a bit of a contradiction. On Mon, Mar 26, 2018 at 4:48 PM, Paul Hoffman <paul.hoff...@icann.org> wrote: > Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a new > media type seems like overkill, particularly given that it will be > transporting *the exact same* data as an existing media type. Instead, an > optional parameter could be added to the application/dns-udpwireformat > registration in the DOH document. > > Proposal: > > ===== > > In the media type definition, change "Optional parameters" to: > > Optional parameters: original_transport > original_transport has two defined values, "udp" and "tcp". > This is only expected to be used by servers. > > Also in the the DOH document, under Operational Considerations, we would add: > > This protocol does not define any use for the original_transport optional > parameter of the application/dns-udpwireformat media type. > > ===== > > Then draft-ietf-dnsop-dns-wireformat-http could define the use of that > optional parameter as it sees fit. > > --Paul Hoffman > > _______________________________________________ > 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