Draft: draft-ietf-add-svcb-dns

Commentary: 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 $  is " a URI Template ] encoded in UTF-8 ] . " This seems not restrictive enough . For example , a valid $  template could be " { ? dns } , " and following the algorithm above would yield " { ? 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 $  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 do n'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 ?
Paragraph (version A):
Use of the SVCB record type requires a mapping document for each
service type, indicating how a client for that service can interpret
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
like DNS over TLS and DNS over HTTPS.
Paragraph (version B):
Use of the SVCB record type requires a mapping document for each
service type, indicating how a client for that service can interpret
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
like DNS over TLS (DoT) and DNS over HTTPS (DoH).
Paragraph (version A):
Let "$HOST" be the authentication name encoded as a ""host"" value
(Section 3.2.2 of RFC3986).
Paragraph (version A):
Let "$DOHPATH" be the "dohpath" value, decoded from UTF-8.
Paragraph (version A):
The DNS over HTTPS URI Template is
""https://$HOST:$PORT$DOHPATH"".
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
"dohpath" is a single-valued SvcParamKey whose value (both in
presentation and wire format) MUST be a URI Template RFC6570 encoded
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).
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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,
Paragraph (version B):
DoT on ""resolver.example"" ports 853 (implicit in record 1)
and 8530 (explicit in record 2), with ""resolver.example"" as
the Authentication Domain Name,