Original text:
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 <del> for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be </del>  empty.  An empty value indicates the default application/dns- <del> udpwireformat type (e.g. ct&body=...). </del>  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 potentially encoded with base64url RFC4648. </del>  Specifications that define media types for use with DOH, such as DNS Wire Format dnswire of this document, MUST indicate if the body parameter uses base64url encoding. The body is the DNS on-the-wire format defined in RFC1035. When using the GET method, the body MUST be encoded with base64url <del> RFC4648. Padding characters for base64url MUST NOT be included. </del>  When using the POST method, the body MUST NOT be encoded.

Reviewer comments:
partially addresses martin is right - the naming of this query parameter was just asking for pain. new coat of paint is in order.
:+1:
I've seen an implementation report that confused base64 and base64url; they noted that the examples didn't include one where the distinction was important
NAME yes, there is also the bit about not having the sign paddings that caught me at first. During the DOH proxy implementation, I missed the padding part. I have it implemented in URL and I think it is correct :) Would an example implementation in a language be worth adding to the examples? It may be more straightforward to read than examples. URL documentation says: This may be worth highlighting as what base64url is too.
This is complicated by the fact that some people want the encoding of responses to GET to be media-type-specific.
I think you mean GET request body parameters (not responses - which are always in bodies and not encoded)
Yes, I meant body parameters.
Please stop calling the parameter . It's really confusing. (I just read this and thought to myself "GET doesn't have a body").
note that the current encoded url in the github copy is wrong as it wasn't updated when the dns id changed to 0. I'll fix that as part of making a base 64 example.

Revised text:
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  <ins> for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&dns=...) or it may be </ins> empty.  An empty value indicates the default application/dns-  <ins> udpwireformat type (e.g. ct&dns=...). </ins> When using the GET method the URI path MUST contain a query parameter  <ins> with the name of "dns".  The value of the parameter is the content of the request potentially encoded with base64url RFC4648. </ins> Specifications that define media types for use with DOH, such as DNS Wire Format dnswire of this document, MUST indicate if the body parameter uses base64url encoding. The body is the DNS on-the-wire format defined in RFC1035. When using the GET method, the body MUST be encoded with base64url  <ins> RFC4648 and then placed as a name value pair in the query portion of the URI with name "dns".  Padding characters for base64url MUST NOT be included. </ins> When using the POST method, the body MUST NOT be encoded.