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

Reply via email to