Original text:
Servers use quota mechanisms to avoid systems overload, to ensure an equitable distribution of computational resources or to enforce other <del> policies - eg. monetization. </del>  A basic quota mechanism limits the number of acceptable requests in a <del> given time window, eg. 10 requests per second. </del>  When quota is exceeded, servers usually do not serve the request <del> replying instead with a "4xx" HTTP status code (eg. 429 or 403) or </del>  adopt more aggressive policies like dropping connections. <del> Quotas may be enforced on different basis (eg. per user, per IP, per </del>  geographic area, ..) and at different levels.  For example, an user may be allowed to issue: count once requests like "/books/{id}" <del> count twice search requests like "/books?author=Camilleri" </del>  so that we have the following counters inferred by the value of "RateLimit-Reset" at the moment of the reset, or <del> communicated out-of-band (eg. in the documentation). </del>  Policies using multiple quota limits MAY be returned using multiple "quota-policy" items, like shown in the following two examples: The client MUST NOT assume that all its "service-limit" will be restored after the moment referenced by "RateLimit-Reset".  The server MAY arbitrarily alter the "RateLimit-Reset" value between <del> subsequent requests eg. in case of resource saturation or to </del>  implement sliding window policies. 4. "RateLimit" values and the returned status code. Servers should be careful in returning "RateLimit" fields in <del> redirection responses (eg. 3xx status codes) because a low </del>  "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 important when quota-policies use a large "time-window". Under certain conditions, a server MAY artificially lower "RateLimit" <del> field values between subsequent requests, eg. to respond to Denial of Service attacks or in case of resource saturation. </del>  Servers usually establish whether the request is in-quota before creating a response, so the RateLimit field values should be already The value of "RateLimit-Reset" is generated at response time: a client aware of a significant network latency MAY behave accordingly <del> and use other information (eg. the "Date" response header field, or </del>  otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server. This specification does not mandate a specific throttling behavior and implementers can adopt their preferred policies, including: <del> slowing down or preemptively backoff their request rate when </del>  approaching quota limits; consuming all the quota according to the exposed limits and then starts, we can convey the same information to the client via "Retry- After", with the advantage that the server can now specify the policy's nominal limit and window that will apply after the reset, <del> ie. assuming the resource exhaustion is likely to be gone by then, so the advertised policy does not need to be adjusted, yet we managed to stop requests for a while and slow down the rest of the current </del>  window. Request:

Reviewer comments:
Fix typos
I'm really sorry for the poor Camilleri :) Wu Ming's "Q" is really worth reading though URL(novel)
What, no Eco? :)
No warnings
There are six lines that are marked as too long.: It might make sense to break these into two lines: and add text saying "Shown on two lines for clarity" or something.
3 fixed ;)
NAME Can this be closed now?
Looks good - thanks for the literary recommendations; I already followed inspector Montalbano's deeds, but Q looks an interesting addition... if/whenever my son gives me some time to read! :smile:

Revised text:
Servers use quota mechanisms to avoid systems overload, to ensure an equitable distribution of computational resources or to enforce other  <ins> policies - e.g. monetization. </ins> A basic quota mechanism limits the number of acceptable requests in a  <ins> given time window, e.g. 10 requests per second. </ins> When quota is exceeded, servers usually do not serve the request  <ins> replying instead with a "4xx" HTTP status code (e.g. 429 or 403) or </ins> adopt more aggressive policies like dropping connections.  <ins> Quotas may be enforced on different basis (e.g. per user, per IP, per </ins> geographic area, ..) and at different levels.  For example, an user may be allowed to issue: count once requests like "/books/{id}"  <ins> count twice search requests like "/books?author=WuMing" </ins> so that we have the following counters inferred by the value of "RateLimit-Reset" at the moment of the reset, or  <ins> communicated out-of-band (e.g. in the documentation). </ins> Policies using multiple quota limits MAY be returned using multiple "quota-policy" items, like shown in the following two examples: The client MUST NOT assume that all its "service-limit" will be restored after the moment referenced by "RateLimit-Reset".  The server MAY arbitrarily alter the "RateLimit-Reset" value between  <ins> subsequent requests e.g. in case of resource saturation or to </ins> implement sliding window policies. 4. "RateLimit" values and the returned status code. Servers should be careful in returning "RateLimit" fields in  <ins> redirection responses (e.g. 3xx status codes) because a low </ins> "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 important when quota-policies use a large "time-window". Under certain conditions, a server MAY artificially lower "RateLimit"  <ins> field values between subsequent requests, e.g. to respond to Denial of Service attacks or in case of resource saturation. </ins> Servers usually establish whether the request is in-quota before creating a response, so the RateLimit field values should be already The value of "RateLimit-Reset" is generated at response time: a client aware of a significant network latency MAY behave accordingly  <ins> and use other information (e.g. the "Date" response header field, or </ins> otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server. This specification does not mandate a specific throttling behavior and implementers can adopt their preferred policies, including:  <ins> slowing down or preemptively back-off their request rate when </ins> approaching quota limits; consuming all the quota according to the exposed limits and then starts, we can convey the same information to the client via "Retry- After", with the advantage that the server can now specify the policy's nominal limit and window that will apply after the reset,  <ins> e.g. assuming the resource exhaustion is likely to be gone by then, so the advertised policy does not need to be adjusted, yet we managed to stop requests for a while and slow down the rest of the current </ins> window. Request: