Yes, I think so. In HTTP, the cacheability of a response depends on the request method and 200 OK is used for practically all methods. In CoAP, the cacheability of a response depends on the response code (so that, for example, a 4.29 Too Many Requests response can be reused even for a POST request) and we separated the success cases into 2.05 for GET, 2.01/2.04 for PUT/POST, and 2.02 for DELETE.

In PR #74 , I rewrote the text, as the main message is probably that in CoAP the response code ALONE decides cacheability, while HTTP has complex rules.

During this, I stumbled over the question how 4.01 Unauthorized and 4.03 Forbidden can be cacheable..
@ektrah ?

According to the Stateless constraint, all requests must be self-containing. So, if you’re not authorized to access a resource when making a request the first time, you’re also not authorized when making the same request again. (Of course, the server should set an appropriate Max-Age so that you’re not stuck with the cached response forever.)

For some error response codes, the CoAP Max-Age Option is actually closer to the HTTP Retry-After header field.

The issue I see is, how could the request and its fields that are evaluated by the cache carry any authorization or authentication information? I would say there is none and auth* information always comes from from something else, so returning a cached response just breaks the application, no?

If “auth* information always comes from something else” then “something else” must be part of the cache key (or like a change in DTLS epoch that keeps cache entries apart).

• What could be NOT "something else" to authenticate/authorize?
• Could anyone other than the origin server know what else to put into the cache key?

I am not sure we are heading to something useful here, but it also feels related to #65.

• For example, a query string or some new CoAP option with a bearer token
• I’d say everyone (including the origin server) must know (and agree) what to put in the cache key. For example an intermediary with a cache can serve a fresh, cached response to a new client. If the intermediary doesn’t include authorizations in the cache key, it might leak information meant for an authorized client when acting on behalf of another, unauthorized client.