Draft: draft-ietf-httpapi-ratelimit-headers

Commentary: clarifies that status code is independent from the values of  fields the example reflects the above statement . 
 Would there be scope to define standards for the 429 response or would that be more relevant to RFC6585 . Should RFC6585 be extended to mention this RFC ? 
 This I - D is independent from the status code of the response , so I 'd say there are no normative relations between this doc and RFC6585 . This is by design : we just want to standardize response fields without explicitly define a " ratelimit protocol " . Instead , we want implementers to be free to implement their throttling strategies . 
 See . 
 I noticed in the example in You return a 200 response with RateLimit - Remaining : 0 . It is not completely clear in the document that a remaining value of 0 should be returned to the caller as a success when the quota has been used exactly . In you present a case where the cost of a more expensive call deducts two from the remaining pool and results in a 429 . I am conflicted as to whether it should be a server decision whether the call is respected or whether the spec should strictly define this behaviour . I lean toward the former but some feel guidance is needed . 
 we should clarify that this is a server choice . The spec does not mandate any correlation between the RL values and the returned status code . The server can always decide to serve requests even when quota is over . We need to clarify this both in the text and in the example . 
 That is something that was not clear to me when reading the spec . The assumption being that when is exhausted , a user will be rate limited and an error response ( 429 ) will be issued . It would seem as per and that there is no specific intention to require a server implementation to deny further responses , but rather in some cases the expectation would be for the client to gracefully comply and back off . My feeling is though that this use case would be the exception rather than the rule , with most implementations opting to deny further requests . Should we not at least provide guidance that a 429 response should be issued in this scenario ?
Paragraph (version A):
The rate-limit fields may be returned in both Successful and non
Successful responses.  This specification does not cover whether
non Successful responses count on quota usage.
Paragraph (version B):
The rate-limit fields may be returned in both successful (see
Section 15.3 of SEMANTICS) and non-successful responses.  This
specification does not cover whether non Successful responses
count on quota usage, nor it mandates any correlation between the
RateLimit values and the returned status code.
Paragraph (version B):
This document does not mandate any correlation between the
"RateLimit" values and the returned status code.
Paragraph (version B):
Since the field values are not necessarily correlated with the
response status code, a subsequent request is not required to fail.
The example below shows that the server decided to serve the request
even if "RateLimit-Remaining" is 0.  Another server, or the same
server under other load conditions, could have decided to throttle
the request instead.