Draft: draft-ietf-httpapi-ratelimit-headers

Commentary: clarify fields dependencies according to the discussion in the issue - 
 It seems that it is not required to return all these 3 fields together . However , I was wondering if certain combinations would cause confusion . For example , if a server return RateLimit - Limit , RateLimit - Remaining but not RateLimit - Reset , such as : RateLimit - Limit : , ;     : 900 How would clients interpret the RateLimit - Remaining field without the RateLimit - Reset ? 
 Already fixed in and are REQUIRED ; is RECOMMENDED . Can you please close if that fixes ? 
 sorry for missing the previous conversation . My take is -Limit alone can be useful for clients . It tells the complete rate - quota in a time window . And clients can control its rate based on this field . RateLimit - Reset helps align the time window between the client and the server , but I think it can be optional . As long as client spread the load evenly , it does not need to know the reset . For example , if a server return RateLimit - Limit : , ;  , that is about 33.3 RPS or 2,000 requests per min(assuming the quota unit is a request ) , clients can adopt it and stay below the limit . , the problem is when RateLimit - Remaining appears without RateLimit - Reset , because it is technically not a rate number due to missing time window . To summarize my opinion - RateLimit - Reset is required when RateLimit - Remaining is specified ; otherwise , RateLimit - Reset is optional . Thoughts ? 
 By design , RateLimit - Limit quota - policies are OPTIONAL and not actionable . The only actionable value of RateLimit - Limit is that is the first value .     , you can not identify the current time - window because quota - policy are not actionable . In the above case , the correct response is This is the reason why RateLimit - Reset is REQUIRED 
 Thanks for closing ! Feel free to provide further feedback since it 's useful to double check the specs ! 
 wdyt on ? Do you think it could better clarify that quota - policies are optional ? Thx++ , R 
 I do agree that having both limit number and policies in the same field is a bit confusing . That is the reason I thought RateLimit - Limit could be actionable , but now I get that the policy is optional . Just look at this example you provided : RateLimit - Limit : , ;     : 300 It seems to have duplicated information . I do understand the benefit of the extensibility in the Limit field , but it could get too complex too soon for clients to consume . 
 The spec to define header inter - dependencies and returning policies [ x ] Limit -Reset [ x ] Limit , Remaining , Reset Do I have to always return all headers ? No Do I have to expose all headers or I can only expose a subset ? Limit , Reset are REQUIRED ,  is OPTIONAL Do we need to add some considerations on client implementation ? Already present . 
 clarifies that clients MUST NOT assume a server always returns fields 
 Comment by  . In https://ietf - wg- You state ‘ A server MAY use one or more " RateLimit " response fields defined in this document to communicate its quota policies . ’ but it does not clearly define how they would be used in isolation or how a client should respond to a limited set of headers ( other than discussed earlier above ) My feeling is RateLimit - Limit can be optional and RateLimit - Remaining and RateLimit - Reset can be used as a pair . RateLimit - Reset would only have value in isolation if sent with a 429 response code , on other responses it would be meaningless . 
 It could also make sense to return Reset with other status codes such as and , so I think we do n't really want to mandate a specific relation other than , at most , saying that unsuccessful requests ( for a broad definition of those , possibly including and at a minimum ) with this field are expected to be unsuccessful until that time elapses . 
 After a couple of years of adoption , my experience is the following : use all 3 fields . Though theoretically one could just return and , I never found an implementation doing this : heavycheckmark : do n't know Remaining , and just return Limit and Reset with a fixed window ( eg . 1 second ) . We can then recommend the following : Limit , Reset : MUST Remaining : SHOULD Since https://ietf - wg- I now think that we should n't mess with status codes . if this sounds reasonable to you , I can provide a PR 
 Yes , it sounds good , thank you !
Paragraph (version A):
A server MAY use one or more "RateLimit" response fields defined in
this document to communicate its quota policies.
Paragraph (version B):
"RateLimit-Remaining" is RECOMMENDED.