Change:
minor editoral changes
thanks for these. The only one that's a little iffy is the inclusion of the reason phrase for 415... but I think here its giving more explanatory value than an impression that particular phrase needs to be used (which wouldn't jibe with http details).

Discussion:
This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its <del> content), but standardisation might make this easier to accomplish. </del> <ins> content), but standardization might make this easier to accomplish. </ins> Note that in this second use, the browser does not consult the DOH server or use its responses for any DNS lookups outside the scope of

defined. The protocol must use a secure transport that meets the <del> requirements for modern HTTPS. </del> <ins> requirements for HTTPS. </ins> 4.1.

smaller than their GET equivalents. When using the GET method the URI path MUST contain a query parameter <del> with the name of ct and a value indicating the media-format used for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be empty. An empty value indicates the default application/dns-udpwireformat type (e.g. ct&body=...). </del> <ins> with the name of "ct" and a value indicating the media-format used for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be empty.  An empty value indicates the default application/dns- udpwireformat type (e.g. ct&body=...). </ins> When using the GET method the URI path MUST contain a query parameter <del> with the name of body.  The value of the parameter is the content of the request encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </del> <ins> with the name of "body".  The value of the parameter is the content of the request encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </ins> The DNS API Client SHOULD include an HTTP "Accept:" request header to say what type of content can be understood in response.  The client

solely up to the format, and not defined in this protocol. At the time this is published, the response types are works in <del> progress.  The only known response type is "application/dns- udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </del> <ins> progress.  The only response type defined in this document is "application/dns-udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </ins> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS(0) extensions, depending on the extension

A DNS API Server MUST be able to process application/dns- udpwireformat request messages. <del> A DNS API Server SHOULD respond with HTTP status code 415 upon receiving a media type it is unable to process. </del> <ins> A DNS API Server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to process. </ins> This document does not change the definition of any HTTP response codes or otherwise proscribe their use.