Original text:
the contents of the SVCB SvcParams.  This document provides the mapping for the "dns" service type, allowing DNS servers to offer alternative endpoints and transports, including encrypted transports <del> like DNS over TLS and DNS over HTTPS. </del>  2. "dohpath" is a single-valued SvcParamKey whose value (both in presentation and wire format) MUST be a URI Template RFC6570 encoded <del> in UTF-8 RFC3629.  If the "alpn" SvcParamKey indicates support for HTTP, "dohpath" MUST be present, and clients MAY construct a DNS over HTTPS URI Template as follows: Let "$HOST" be the authentication name encoded as a ""host"" value (Section 3.2.2 of RFC3986). Let "$PORT" be the port from the "port" key if present, otherwise 443.  (The binding authority's port number MUST NOT be used.) Let "$DOHPATH" be the "dohpath" value, decoded from UTF-8. The DNS over HTTPS URI Template is ""https://$HOST:$PORT$DOHPATH"". The "dohpath" value MUST be chosen such that the resulting URI Template is valid for use with DNS over HTTPS.  For example, DNS over HTTPS servers are required to support requests using GET and POST methods.  The GET method relies on the "dns" URI Template parameter, and the POST method does not use it.  Therefore, the URI Template is required to make use of a "dns" variable, and result in a valid URI whether or not "dns" is defined. Clients SHOULD NOT query for any "HTTPS" RRs when using the constructed URI Template.  Instead, the SvcParams and address records associated with this SVCB record SHOULD be used for the HTTPS connection, with the same semantics as an HTTPS RR.  However, for consistency, service operators SHOULD publish an equivalent HTTPS RR, especially if clients might learn this URI Template through a different channel. </del>  6. <del> A resolver at ""doh.example"" that supports only DNS over HTTPS (DNS over TLS is not supported): </del>  A resolver at ""resolver.example"" that supports: <del> DNS over TLS on ""resolver.example"" ports 853 (implicit in record 1) and 8530 (explicit in record 2), with ""resolver.example"" as the Authentication Domain Name, </del>  <del> DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and </del>  an experimental protocol on "fooexp.resolver.example:5353" (record 3):

Reviewer comments:
This wording avoids the complexity of a URI construction algorithm and is more direct and compact.
The DoH URI Template algorithm currently works like so: where $DOHPATH is "a URI Template ] encoded in UTF-8 ]." This seems not restrictive enough. For example, a valid $DOHPATH template could be "URL{?dns}," and following the algorithm above would yield "URL{?dns}," which obviously seems like not the intended result. There's text that says "The "dohpath" value MUST be chosen such that the resulting URI Template is valid for use with DNS over HTTPS," but note that the algorithm above is presented with the word MAY which, to me, implies that clients could construct the URI Template some other way. Unless there's a good reason to do so, we should be more restrictive with what $DOHPATH contains (it might be just a path component of a URI Template, or something), and how clients construct the Template.
Yes. Surely this normatively constrains the value in the way you're asking? Yes. People don't like it when you normatively require implementation of a specific algorithm, because it artificially constrains implementation. In this case, for example, a client could choose to omit the port number when it is unspecified, instead of setting it explicitly to 443. This would undeniably result in a different DoH URI Template, although the resulting calculated URIs for each request would be equivalent in some sense. A client could even skip computation of the full URI template, and instead perform substitution for each request directly on the string, plugging and and the path into their HTTP client library without ever constructing a URI.
Maybe it would be better to say that is a URI template that expands to the for each HTTP request, and remove the discussion about forming a full URL?

Revised text:
the contents of the SVCB SvcParams.  This document provides the mapping for the "dns" service type, allowing DNS servers to offer alternative endpoints and transports, including encrypted transports  <ins> like DNS over TLS (DoT) and DNS over HTTPS (DoH). </ins> 2. "dohpath" is a single-valued SvcParamKey whose value (both in presentation and wire format) MUST be a URI Template RFC6570 encoded  <ins> in UTF-8 RFC3629.  If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present.  The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of RFC8484) is always a valid and functional ":path" value (RFC7540, Section 8.1.2.3). When using this SVCB record, the client MUST send any DoH requests to the HTTP origin identified by the "https" scheme, the authentication name, and the port from the "port" SvcParam (if present).  HTTP requests MUST be directed to the resource resulting from DoH template expansion of the "dohpath" value. Clients SHOULD NOT query for any "HTTPS" RRs when using "dohpath". Instead, the SvcParams and address records associated with this SVCB record SHOULD be used for the HTTPS connection, with the same semantics as an HTTPS RR.  However, for consistency, service operators SHOULD publish an equivalent HTTPS RR, especially if clients might learn about this DoH service through a different channel. </ins> 6.  <ins> A DoH-only resolver at "https://doh.example/dns-query{?dns}". (DNS over TLS is not supported.): </ins> A resolver at ""resolver.example"" that supports:  <ins> DoT on ""resolver.example"" ports 853 (implicit in record 1) and 8530 (explicit in record 2), with ""resolver.example"" as the Authentication Domain Name, </ins>  <ins> DoH at "https://resolver.example/dns-query{?dns}" (record 1), and </ins> an experimental protocol on "fooexp.resolver.example:5353" (record 3):