Change:
clarifies interaxtions with 3xx
Note that here we clash with the scope of these fields. Do they refer to the current request which for whatever reason ends up in a redirection or do they refer to the request that will follow up to the target location? We have been careful to always talk about the current request and leave the scope undefined but one way or another contained in this request (ie. the same service, the same path prefix, the same domain, the same hour, or any other criteria that can emerge from the fact we are performing this particular request). With the fields applied to the follow up redirection this could change, because the target location could be any URL. So what would happen if we really wanted to limit the endpoint that causes the redirection instead of the target location? A point can be made about these values being of no use when an endpoint is redirected, but if the redirection was conditional or temporary, we'd lose the ability to convey these limits. In addition, a redirect might target a different service altogether, potentially with its own policies this service might know nothing about. I think giving a different meaning to these values in the case of redirection creates an exception that does not carry enough weight. In the general case where a redirection is permanent, you can simply assume as a client that you need to call at least once the target location in order to obtain rate limiting information. After all, your request was serviced, not refused, so if the target was under the control of this service and it determined that you have no quota, it could just as well refuse to respond with the redirect and instead send back a 429 or some other client error status rather than waiting for you to perform another request only to then refuse to service it.
I tried to be non-normative, and just warn implementers - both client and server - to be carefull when 3xx and I avoided providing details (eg. whether is on the same service or not). But I think you can provide a better wording: if you think this should be placed elsewhere (eg. Security considerations) feel free to do it! :rocket:
NAME PTAL :)
I think providing a reminder to the server implementer that if you are going to return a redirect and you know it is to the same API, then it would unwise to return a 0 in the RateLimit-Remaining. This feels like a valuable reminder to me.
No Correct Probably we should warn that returning a with 30x could refrain clients to make a request, but I won't be normative on that cc: NAME
See We need to provide guidance in redirection cases, probably.

Discussion:
A server MAY return "RateLimit" response fields independently of the response status code.  This includes throttled responses. <ins> Servers should be careful in returning "RateLimit" fields in redirection responses (eg. 3xx status codes) because a low "RateLimit-Remaining" value could limit the client from issuing requests.  For example, given the rate limiting fields below, a client could decide to wait 10 seconds before following the "Location" header, because "RateLimit-Remaining" is 0. </ins> If a response contains both the "Retry-After" and the "RateLimit- Reset" fields, the value of "RateLimit-Reset" SHOULD reference the same point in time as "Retry-After".