Describe features of and add vocabulary for RFC 9175

[ektrah]

→ Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing

[JKRhb]

Do you already have an idea of how to cover the features introduced in RFC 9175?

Would it be sufficient to introduce boolean vocabulary terms like requiresFreshness (for the Echo option) or supportsRequestTags (for the Request Tag option)? If I read the RFC correctly, the vocabulary referring to the Request Tags could probably be integrated into the BlockWiseTransferParameters, right?

[ektrah]

I haven't looked into any new vocabulary that might be needed, but at least there should be new subsections in Section 2 that describe the features.

[ektrah]

Regarding the Echo option, the flow looks like this:

1. Client makes a request without an Echo option
2. Server returns 4.01 (Unauthorized) with an Echo option
3. Client repeats the request with the received Echo option
4. Client may use the received Echo option for subsequent requests

From the perspective of the client I don't think there's much to say in a TD. If I'm not mistaken, there is nothing a client can do to avoid the first round-trip (e.g. by including something in its request). Also, I don't think the client needs a "heads-up" about the server possibly sending back 4.01; either the client implements the feature and understands this flow or it cannot perform the interaction. So I think that no new vocabulary is needed for this.

However, it might be helpful for implementers to see that they should use a CoAP client implementation that supports the feature / implement the API on the CoAP server in such a way that the feature is exercised. I'm not sure if this dual use of a TD (instructions selectively targeting either automated clients or implementers) isn't more confusing than helpful, though. ("I see this bit of information in the TD. Is this relevant to me right now or can I ignore it?")

Regarding requests tags, I agree that extending the BlockWiseTransferParameters to specify that the client should include a request tag in its block-wise transfer is probably the best solution.

[JKRhb]

However, it might be helpful for implementers to see that they should use a CoAP client implementation that supports the feature / implement the API on the CoAP server in such a way that the feature is exercised. I'm not sure if this dual use of a TD (instructions selectively targeting either automated clients or implementers) isn't more confusing than helpful, though. ("I see this bit of information in the TD. Is this relevant to me right now or can I ignore it?")

Hmm, maybe this information could be used primarily in Thing Models, which could then be used by implementers to create applications compliant with the API specification (something similar could apply to response codes, as mentioned in #254). When "instantiating" the TM, this information could then simply be omitted in the resulting TD.

From the perspective of the client I don't think there's much to say in a TD. If I'm not mistaken, there is nothing a client can do to avoid the first round-trip (e.g. by including something in its request). Also, I don't think the client needs a "heads-up" about the server possibly sending back 4.01; either the client implements the feature and understands this flow or it cannot perform the interaction. So I think that no new vocabulary is needed for this.

I guess the only benefit of including a hint for this feature in the TD would be that a Consumer could abstain from sending even the first request if it doesn't support the Echo option at all or choose a different form.

[JKRhb]

When "instantiating" the TM, this information could then simply be omitted in the resulting TD.

Hmm, nevermind, just got reminded by the WoT dev meeting that all parts of a TM need to be taken over into the resulting TD.