Add "docpath" SVCB ParamKey definition

[miri64]

During the IETF 119 core WG meeting we were asked to split draft-lenders-core-dnr into two documents: One specifying what is already there, Service Bindings and Parameter Specifications for CoAP over (D)TLS (started here https://github.com/anr-bmbf-pivot/draft-lenders-core-coap-dtls-svcb) and a document that starts the work on Service Bindings and Parameter Specification for OSCORE/EDHOC/ACE (what will remain of https://github.com/anr-bmbf-pivot/draft-lenders-core-dnr).

However, this leaves the docpath SvcParamKey somewhat hanging. We can put it in draft-lenders-core-coap-dtls-svcb, but that one seems to become a somewhat more general CoAP over (D)TLS discovery document. So we (@chrysn and I) came to the conclusion that the DoC draft might be the best place for it after all, given that draft-lenders-core-coap-dtls-svcb is supposed to be clustered with the DoC draft for WGLC.

[cabo]

I'm wondering whether we can't offer an array of Uri-Path option values in some form.

[miri64]

Doing an array with SvcParams would, to my understanding, mean that one needs to provide the "docpath" SvcParamKey multiple times (at least if we don't want to fiddle around with including yet even more data types here). This raises several questions to me: What to do in an absence of a Uri-Path option (i.e. root path)? Not having a docpath key provided? Having it empty? Not providing it at all? Would, for the latter, a client be able to distinguish SvcParams for a DoC server from any other CoAP server?

[chrysn]

We've discussed briefly whether there would be CRIs or URIs in here; going with URIs removed the ambiguity of earlier versions, but is indeed possibly not ideal.

If multiple values are a thing in SvcParamKey, that would neatly make the default case very efficient, and only become a "burden" if multi-segment paths are used.

The natural thing from a CoAP PoV would be to not provide any at all, bringing us back to the "can we just not set any" discussion we had in a previous iteration, and maybe shied away from too fast: After all, this does not occur in an arbitrary service parameters set (I think it'd make little sense in a hypothetical _coap SVCB record, such a record would be used by discovering .well-known/core and then maybe finding a DNS server there), but it is found in a response to a _dns SVCB request or the equivalent response from one of the DNRs -- and there, we infer that DoC is present not from the docpath, but from the presence of a CoAP transport in DNS, and then docpath is treated as a plain list, which may be empty.

[miri64]

Doing an array with SvcParams would, to my understanding, mean that one needs to provide the "docpath" SvcParamKey multiple times

Sorry, must have misremembered this from a different spec. Reading RFC 9460 again, it specifically states that duplicate SvcParams are NOT allowed in a SVCB record:

Clients MUST consider an RR malformed if:

• the end of the RDATA occurs within a SvcParam.

• SvcParamKeys are not in strictly increasing numeric order.

• the SvcParamValue for a SvcParamKey does not have the expected
  format.

Note that the second condition implies that there are no duplicate
SvcParamKeys.

[miri64]

So this raises the question: How would an array of URI-Path options be provided?

[miri64]

After all, this does not occur in an arbitrary service parameters set (I think it'd make little sense in a hypothetical _coap SVCB record, such a record would be used by discovering .well-known/core and then maybe finding a DNS server there), but it is found in a response to a _dns SVCB request or the equivalent response from one of the DNRs -- and there, we infer that DoC is present not from the docpath, but from the presence of a CoAP transport in DNS, and then docpath is treated as a plain list, which may be empty.

I'm still not convinced that an operator might just be allowed to register e.g.

coap.example.com.  7200  IN SVCB 3 coap.example.com. (
    alpn="co" port="5684" docpath="/" )

with no intention to serve anything else but DoC at this endpoint. So the context clues that this is a DoC server would be missing when an empty docpath could be elided if the SVCB record alone is looked up (of course, they then can use .well-known/core to look it up, but that's just one query more). Likewise, it gives an easy hint where to find the DoC server in case any other services are provided at the coaps://coap.example.com endpoint.

[miri64]

@chrysn and I discussed this and we decided to encode this as a sequence of CBOR text strings. See e08242c. The reasoning can also be found there.

[chrysn]

Do we want to specify a text format for that? (Could be diagnostic notation).

[chrysn]

(Could also be value-list because that's what zone files already use)

[miri64]

See https://github.com/core-wg/draft-dns-over-coap/pull/28/files#diff-3447d898853b49b9d631406ac996197ef45750f12dbd2bc394787a3ac56933bbR196-R197 for now. We can also use the value list route, but need to look into that format first.

[chrysn]

value-list is described at https://www.rfc-editor.org/rfc/rfc9460.html#name-decoding-a-comma-separated -- not sure where that comes from originally or how that language works as a whole.

[miri64]

Mh... I think I prefer CBOR-diag, if that is how the value-list format works. Your [off-line] worries about commas seem to me to be unjustified when looking at the value-list format.

[moonshiner]

"docpath" sounds a bit vague - could it be "coappath" or "coapath" ?

[miri64]

"docpath" sounds a bit vague - could it be "coappath" or "coapath" ?

Just for clarification: How is "coappath" less vague (referring to the transport protocol) than "docpath" (referring to DoC, DNS over CoAP, the application protocol used over said transport)? The name was chosen in line with "dohpath" which uses an URI template which we don't need for DoC. There a simple path suffices.

[moonshiner]

oh - thinking about it more you are more than correct. I do not know what came over me.

[miri64]

No worries. We were actually wondering off-line, if there was some insight with the history of "dohpath" in that and if generalization would indeed make sense.

Would it have made sense if e.g. "dohpath" would have been called "httppath", too? The fact that we are asking for a DNS resource can be inferred from the query or just the fact that they are in a DNR-related message. As such, having the information DNS+path encoded in this codepoint might be redundant and just having the path information would suffice and even re-usable for other use cases in the future.

Moreover, as pointed out, differing from "dohpath" we only encode a path in the value (not a URI template). So it is already more generalized.

[chrysn]

Summarizing my original question: Seems to be OK, https://www.rfc-editor.org/rfc/rfc9460.html#name-decoding-a-comma-separated- has an example of a quoted / escaped SVCB parame value, so that part is fine. (and IIUC, dohpath is also fine from the last posts)

[miri64]

During the interim in May we discussed to add at least a rough outline of a request construction algorithm from a SVCB record. c130a87 provides that now.

PR received some updates, please re-review.