Original text:
7.2.3. <del> Request methods can be defined as " " to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see Caching.  In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD. </del>  7.3.

Reviewer comments:
HTTP Methods have 3 boolean properties, all of which says a registration needs to define, but only "Safe" and "Idempotent" were included in the registry while "Cacheable" was omitted. I filed this as URL, but it probably makes more sense as a change for ter.
I think the only concern I have here is that people often misinterpret "cacheable" - e.g., see .
FWIW, that's because it isn't a boolean property of the method, but rather a capability inherent in the system in which one aspect is the method semantics. I'd prefer to remove that from the registration table. We could still require that the registration describe how and under what conditions the method semantics might be cacheable.
It's not in the registration table, and I tend to agree it should be kept out for the reasons above.
This was discussed regarding Variants, and I think the answer will be the same; we should record this sort of thing in documentation elsewhere, e.g., the .
URL says but then the method definitions themselves seem to consistently say After this discussion, I think the method definitions ("The response is cacheable") are more correct, and that therefore my initial suggestion in this erratum is incorrect. URL repeats the less-correct form by listing "cacheable" along with "safe" and "idempotent" as properties of the method. I think removing "cacheable" from that list, and changing "If the new method is cacheable, ..." to something like would have prevented me from getting confused enough to file this issue. Do the experts here like that direction?
Note that RFC7540 Section 8.2 relies on that distinction by saying that pushed requests MUST be cacheable in order to be pushed, but conditionally defines what happens if the delivered response does turn out to be cacheable. Eliminating the distinction entirely would leave 7540 slightly unmoored.
I think the proposed edit to considerations for new methods is helpful; we could address the 7540 concern by parenthetically adding "also known as cacheable methods" or similar. Note also the first bullet of . If we can come up with a better phrase than "defined as cacheable" that's great, but it needs to be distinct from response cacheability.
ietf104: mark needs to research the 7540 question to determine if this can be made editorial based on jyasskin's above comment
7540 points directly to 723x for this, so we have some leeway. I think we can address this by parenthetically stating that a method that does not define the conditions under which it can be used by a cache is by definition not cacheable. Will do a PR.
Looks good to me.

Revised text:
7.2.3.  <ins> For a cache to store and use a response, the associated method needs to explicitly allow caching, and detail under what conditions a response can be used to satisfy subsequent requests; a method definition which does not do so cannot be cached.  For additional requirements see Caching. This specification defines caching semantics for GET, HEAD, and POST, although the overwhelming majority of cache implementations only support GET and HEAD. </ins> 7.3.