When defining new header fields or methods or any other extensions to HTTP, it can be the case that those elements make statements where the scope is unclear. For instance, in #99 we learned that Retry-After often states something that applies to an entire server (or server instance), or maybe a subset of resources, or maybe just the request itself. HTTP generally assumes that the scope of applicability is a request, but it might also be the specific representation or the resource.
New protocol extensions need to consider carefully what the scope of applicability is for new protocol elements and the information they carry. Adding text about this to the document (to expand #50) would be good.
When defining new header fields or methods or any other extensions to HTTP, it can be the case that those elements make statements where the scope is unclear. For instance, in #99 we learned that
Retry-Afteroften states something that applies to an entire server (or server instance), or maybe a subset of resources, or maybe just the request itself. HTTP generally assumes that the scope of applicability is a request, but it might also be the specific representation or the resource.New protocol extensions need to consider carefully what the scope of applicability is for new protocol elements and the information they carry. Adding text about this to the document (to expand #50) would be good.