Draft: draft-ietf-doh-dns-over-https-latest

Commentary: The media type has been the subject of some debate . The above might be the best I 've seen .
Paragraph (version A):
The DNS API client SHOULD include an HTTP "Accept" request header to
indicate what type of content can be understood in response.
Irrespective of the value of the Accept request header, the client
MUST be prepared to process "application/dns-udpwireformat" (See
dnswire) responses but MAY also process any other type it receives.
Paragraph (version A):
In order to maximize cache friendliness, DNS API clients using media
formats that include DNS ID, such as application/dns-udpwireformat,
SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the
request and response, thus eliminating the need for the ID in a media
type such as application/dns-udpwireformat.  The use of a varying DNS
ID can cause semantically equivalent DNS queries to be cached
separately.
Paragraph (version B):
The DNS API client SHOULD include an HTTP "Accept" request header to
indicate what type of content can be understood in response.
Irrespective of the value of the Accept request header, the client
MUST be prepared to process "message/dns" (as described in dnswire)
responses but MAY also process any other type it receives.
Paragraph (version B):
In order to maximize cache friendliness, DNS API clients using media
formats that include DNS ID, such as message/dns, SHOULD use a DNS ID
of 0 in every DNS request.  HTTP correlates the request and response,
thus eliminating the need for the ID in a media type such as message/
dns.  The use of a varying DNS ID can cause semantically equivalent
DNS queries to be cached separately.
Paragraph (version A):
The requests are represented as application/dns-udpwirefomat typed
bodies.
Paragraph (version B):
The requests are represented as message/dns typed bodies.
Paragraph (version A):
At the time this is published, the response types are works in
progress.  The only response type defined in this document is
"application/dns-udpwireformat", but it is possible that other
response formats will be defined in the future.
Paragraph (version A):
The DNS response for "application/dns-udpwireformat" in dnswire MAY
have one or more EDNS options, depending on the extension definition
of the extensions given in the DNS request.
Paragraph (version B):
At the time this is published, the response types are works in
progress.  The only response type defined in this document is
"message/dns", but it is possible that other response formats will be
defined in the future.
Paragraph (version B):
The DNS response for "message/dns" in dnswire MAY have one or more
EDNS options, depending on the extension definition of the extensions
given in the DNS request.
Paragraph (version A):
A DNS API server MUST be able to process application/dns-
udpwireformat request messages.
Paragraph (version B):
A DNS API server MUST be able to process message/dns request
messages.
Paragraph (version A):
In order to maximize interoperability, DNS API clients and DNS API
servers MUST support the "application/dns-udpwireformat" media type.
Other media types MAY be used as defined by HTTP Content Negotiation
(RFC7231 Section 3.4).
Paragraph (version B):
In order to maximize interoperability, DNS API clients and DNS API
servers MUST support the "message/dns" media type.  Other media types
MAY be used as defined by HTTP Content Negotiation (RFC7231
Section 3.4).
Paragraph (version A):
The media type is "application/dns-udpwireformat".
Paragraph (version B):
The media type is "message/dns".