Change:
A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods. <del> When using the POST method, the DNS query is included as the message </del> <ins> When using the POST method the DNS query is included as the message </ins> body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are smaller than their GET equivalents. <del> When using the GET method, the URI path MUST contain a query parameter of the form content-type=TTT and another of the form body=BBBB, where "TTT" is the media type of the format used for the body parameter, and "BBB" is the content of the body encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </del> <ins> When using the GET method the URI path MUST contain a query parameter 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=...). When using the GET method the URI path MUST contain a query parameter 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

Discussion:
closes issue
I could go either way on body. You're right that the actual mime type is a bit of a problem.. I'll try it with a ct name argument without a value having the default meaning. I think that's explicit enough, while I don't really like totally implicit things like the absence of ct (what if you mis-spell it?)
NAME Actually what was the reasoning behind passing Content-Type as a query parameter instead of as the Content-Type header? Presumably any DNS API server must be able to parse headers...
Content-Type as a header refers to the message payload which isn't what we're trying to describe here.. (its used on POST, where it matches..)
NAME referring back to pull , you wrote this: "I could go either way on body. You're right that the actual mime type is a bit of a problem.. I'll try it with a name argument without a value having the default meaning. I think that's explicit enough, while I don't really like totally implicit things like the absence of (what if you mis-spell it?)" I'm fine with having now named , but I'm concerned by the use of a the query parameter without a value at all... Whilst this is probably too unwieldy: /dns-query?ct=application/dns-udpwireformat&dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB the use of alone just URL /dns-query?ct&dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB Yes, I know it's valid according to RFC 3986, but I'm wondering whether, since it's very unlikely that a JSON format would be passed using a GET, we could treat the absence of as implying ? Alternatively we could allow a couple of special values for the parameter: - implies that the format is - implies that the format is
There's a potential different approach here, use a specific parameter name for each type of query. That is, has a value that is json=...application/dns-query+json` and so on. That way you can have multiple formats on the request (for backwards compatibility).

The only downside is that the backwardly compatible request will cause a hit on cache coherency, so the server might want to redirect to a canonical URL if it is concerned that the client won't consistently include both formats. (That redirect can be followed by a push if you are concerned about round trips.)
This feels cache-unfriendly to me. What is the problem with the default for ct?
It's a tiny hit to cache unfriendliness (you don't get coherency between clients that inconsistently construct requests, or you have to redirect-and-push), agreed. But it gets you the agility you wanted.
Oh, forgot to point out that this tends to be self-correcting. There are usually only a few different configurations of clients, so while those that support two request formats won't necessarily share cache hits with those that only support one, those two populations will probably happily share a cache.
NAME So to be clear, you'd allow requests like any of the following: Personally I like this - clear and neat. Maybe I'd change the parameter to (so the two options are and , but that's just me. It removes the necessity to specify the type separately and it's 'neat'. Plus extensible for future formats.
Yeah. Pick whatever colour you like for the shed, I'm not planning to live in it.
NAME describes a method that is more flexible again in . A better solution in my opinion (if you set the second half of that issue aside for the moment).
I think the color of the shed is fine for this document, and if discovery would like to do some fancy templating to enable rainbows that's fine for that separate effort.
could be much shorter. Bytes in requests matter and these are going to be used in critical conditions (early in the connection where the number of requests you can make depend on how big they are). These won't compress well enough with HPACK to get any real benefit. A short name would be an improvement. A default value for would be even better.
Could go the alt-svc approach (URL) and use two-letter combos, e.g.

"ct" for , but really there out to be a standard for that approach...
I like the change to 'ct' for Content-Type, but I think 'body' is important enough where reducing it by only two bytes to 'rb' isn't worth the change. Perhaps there could be an abbreviated 'ct' value - e.g. 'ct=du'? Or, if 'ct' is not specified, then 'application/dns-udpwireformat' iMUST be assumed by the DNS server?