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

Commentary: Fixes issue 
 The message/ tree requires that the sub - types contain other MIME messages , which DOH does not . Maybe use application / dns - message instead .
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 "message/dns" (as described in 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 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 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 "application/dns-message" (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 application/dns-message, 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-message.  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 message/dns typed bodies.
Paragraph (version B):
The requests are represented as application/dns-message 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
"message/dns", but it is possible that other response formats will be
defined in the future.
Paragraph (version A):
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 B):
At the time this is published, the response types are works in
progress.  The only response type defined in this document is
"application/dns-message", but it is possible that other response
formats will be defined in the future.
Paragraph (version B):
The DNS response for "application/dns-message" 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 message/dns request
messages.
Paragraph (version B):
A DNS API server MUST be able to process application/dns-message
request messages.
Paragraph (version A):
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 B):
In order to maximize interoperability, DNS API clients and DNS API
servers MUST support the "application/dns-message" 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 "message/dns".
Paragraph (version B):
The media type is "application/dns-message".