diff --git a/svcb-docpath/draft-ietf-core-dns-over-coap.html b/svcb-docpath/draft-ietf-core-dns-over-coap.html index 55329a9..c192fff 100644 --- a/svcb-docpath/draft-ietf-core-dns-over-coap.html +++ b/svcb-docpath/draft-ietf-core-dns-over-coap.html @@ -1155,7 +1155,12 @@
When discovering the DNS resource through a link mechanism that allows describing a resource type (e.g., the Resource Type Attribute in [RFC6690]), the resource type "core.dns" can be used to identify a generic DNS resolver that is available to the client.¶
-A DoC server can also be discovered using SVCB Resource Records (RR) [RFC9460], [RFC9461] or DNR +
While there is no path specified for the DoC resource, it is RECOMMENDED to use the root path "/" +to keep the CoAP requests small.¶
+A DoC server can also be discovered using SVCB Resource Records (RR) [RFC9460], [RFC9461] or DNR Service Parameters [RFC9463]. [TBD: draft-lenders-core-coap-dtls-svcb] provides solutions to discover CoAP over (D)TLS servers using the "alpn" SvcParam. This document specifies "docpath" as @@ -1457,8 +1469,8 @@
Note, that this specifically does not surround the text string sequence with a CBOR array or similar +of that CBOR sequence can be used.¶
+Note, that this specifically does not surround the text string sequence with a CBOR array or similar CBOR data item. This path format was chosen to coincide with the path representation in CRIs ([I-D.ietf-core-href]). Furthermore, it is easily transferable into a sequence of CoAP Uri-Path options by mapping the initial byte of any present CBOR text string (see [RFC8949], Section 3) into the Option @@ -1466,12 +1478,26 @@
To use the service binding from a SVCB RR, the DoC client MUST send any DoC request to the CoAP -resource identifier constructed from the SvcParams including "docpath" as described in [TBD: -draft-lenders-core-coap-dtls-svcb].¶
-While there is no path specified for the DoC resource, it is RECOMMENDED to use the root path "/" -to keep the CoAP requests small.¶
+octets.¶ +To use the service binding from a SVCB RR, the DoC client MUST send any DoC request to the CoAP +resource identifier constructed from the SvcParams including "docpath". A rough construction +algorithm could be as follows. +- If the "alpn" SvcParam value for the service is "coap", construct a CoAP request for CoAP over TCP, + if it is "co", construct one for CoAP over DTLS. +- The destination address for the request should be taken from additional information about the + target, e.g. from an AAAA record associated to the target or from am "ipv6hint" SvcParam value, + or, as a fallback, by querying an address for the queried host name of the SVCB record. +- The destination port for the address is taken from the "port" SvcParam value, if present. + Otherwise, take the default port of the CoAP transport. +- Set the queried host name of SVCB record in the URI-Host option. +- For each element in the CBOR sequence of the "docpath" SvcParam value, add a Uri-Path option to + the request. +- If a "port" SvcParam value is provided or if a port was queried, and if either differs from either + the default port of the transport or the destination port selected above, set that port in the + URI-Port option.¶
+A more generalized construction algorithm can be found in [I-D.ietf-core-transport-indication].¶
+