Original text:
This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset fields for HTTP, thus allowing servers to publish <del> current request quotas and clients to shape their request policy and </del>  avoid being throttled out. Note to Readers 2.2. <del> The request-quota is a value associated to the maximum number of </del>  requests that the server is willing to accept from one or more clients on a given basis (originating IP, authenticated user, geographical, ..) during a "time-window" as defined in time-window. <del> The "request-quota" is expressed in "quota-units" and has the </del>  following syntax: <del> The "request-quota" SHOULD match the maximum number of acceptable </del>  requests. <del> The "request-quota" MAY differ from the total number of acceptable </del>  requests when weight mechanisms, bursts, or other server policies are implemented. <del> If the "request-quota" does not match the maximum number of </del>  acceptable requests the relation with that SHOULD be communicated out-of-band. 3.1. <del> The "RateLimit-Limit" response field indicates the "request-quota" </del>  associated to the client in the current "time-window". If the client exceeds that limit, it MAY not be served. The field value is <del> The "expiring-limit" value MUST be set to the "request-quota" that is </del>  closer to reach its limit. The "quota-policy" is defined in quota-policy, and its values are 3.2. The "RateLimit-Remaining" response field indicates the remaining <del> "quota-units" defined in request-quota associated to the client. </del>  The field value is An example of "RateLimit-Reset" use is below. <del> The client MUST NOT assume that all its "request-quota" will be </del>  restored after the moment referenced by "RateLimit-Reset".  The server MAY arbitrarily alter the "RateLimit-Reset" value between subsequent requests eg. in case of resource saturation or to does not guarantee that the next request will be successful.  Server metrics may be subject to other conditions like the one shown in the <del> example from request-quota. </del>  A server MAY return "RateLimit" response fields independently of the response status code.  This includes throttled responses. A client MUST validate the values received in the "RateLimit" fields before using them and check if there are significant discrepancies with the expected ones.  This includes a "RateLimit-Reset" moment too <del> far in the future or a "request-quota" too high. </del>  Malformed "RateLimit" fields MAY be ignored. 8.1.1. <del> The client exhausted its request-quota for the next 50 seconds.  The </del>  "time-window" is communicated out-of-band or inferred by the field values. 9.4. <del> Consider that "request-quota" may not be restored after the moment </del>  referenced by "RateLimit-Reset", and the "RateLimit-Reset" value should not be considered fixed nor constant.

Reviewer comments:
Improves terminology replacing with . cc: NAME NAME
It seems in the context of this design limit and quota terminology mean the same thing, however the header name to represent quota is RateLimit-Limit, which stutters. Would RateLimit-Quota not be better because it seems to mean the same thing and avoids stuttering?
Well, conveys the , which is expressed in terms of . The name makes me think more to a than to or . Since implementers already use , with NAME we decided not to change field names. WDYT to rename instead?
One potential issue with is that the quota can be not directly related to the amount of requests. For example it could be time based, just to name a simple criteria, but there are multiple other potential factors that could affect the units returned that could be confused when using that name. could arguably make for a better name.
Not sure this should be closed by the PR, so feel free to reopen if that's not the case.
NAME thanks for your feedback! You're welcome to provide more! NAME to me it's fine! Good merge and good idea about the new name is cool :)
Thanks both! I think this is more clear.
:+1:Thanks! I think this is more clear.

Revised text:
This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset fields for HTTP, thus allowing servers to publish  <ins> current service limits and clients to shape their request policy and </ins> avoid being throttled out. Note to Readers 2.2.  <ins> The service-limit is a value associated to the maximum number of </ins> requests that the server is willing to accept from one or more clients on a given basis (originating IP, authenticated user, geographical, ..) during a "time-window" as defined in time-window.  <ins> The "service-limit" is expressed in "quota-units" and has the </ins> following syntax:  <ins> The "service-limit" SHOULD match the maximum number of acceptable </ins> requests.  <ins> The "service-limit" MAY differ from the total number of acceptable </ins> requests when weight mechanisms, bursts, or other server policies are implemented.  <ins> If the "service-limit" does not match the maximum number of </ins> acceptable requests the relation with that SHOULD be communicated out-of-band. 3.1.  <ins> The "RateLimit-Limit" response field indicates the "service-limit" </ins> associated to the client in the current "time-window". If the client exceeds that limit, it MAY not be served. The field value is  <ins> The "expiring-limit" value MUST be set to the "service-limit" that is </ins> closer to reach its limit. The "quota-policy" is defined in quota-policy, and its values are 3.2. The "RateLimit-Remaining" response field indicates the remaining  <ins> "quota-units" defined in service-limit associated to the client. </ins> The field value is An example of "RateLimit-Reset" use is below.  <ins> The client MUST NOT assume that all its "service-limit" will be </ins> restored after the moment referenced by "RateLimit-Reset".  The server MAY arbitrarily alter the "RateLimit-Reset" value between subsequent requests eg. in case of resource saturation or to does not guarantee that the next request will be successful.  Server metrics may be subject to other conditions like the one shown in the  <ins> example from service-limit. </ins> A server MAY return "RateLimit" response fields independently of the response status code.  This includes throttled responses. A client MUST validate the values received in the "RateLimit" fields before using them and check if there are significant discrepancies with the expected ones.  This includes a "RateLimit-Reset" moment too  <ins> far in the future or a "service-limit" too high. </ins> Malformed "RateLimit" fields MAY be ignored. 8.1.1.  <ins> The client exhausted its service-limit for the next 50 seconds.  The </ins> "time-window" is communicated out-of-band or inferred by the field values. 9.4.  <ins> Consider that "service-limit" may not be restored after the moment </ins> referenced by "RateLimit-Reset", and the "RateLimit-Reset" value should not be considered fixed nor constant.