Draft: draft-ietf-httpapi-ratelimit-headers

Commentary: Fix typos 
 I 'm really sorry for the poor Camilleri :)    " Q " is really worth reading though ( novel ) 
 What , no  ? :) 
 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 ;) 
 Can this be closed now ? 
 Looks good - thanks for the literary recommendations ; I already followed inspector  's deeds , but Q looks an interesting addition ... if / whenever my son gives me some time to read ! : smile :
Paragraph (version A):
Servers use quota mechanisms to avoid systems overload, to ensure an
equitable distribution of computational resources or to enforce other
policies - eg. monetization.
Paragraph (version A):
A basic quota mechanism limits the number of acceptable requests in a
given time window, eg. 10 requests per second.
Paragraph (version A):
When quota is exceeded, servers usually do not serve the request
replying instead with a "4xx" HTTP status code (eg. 429 or 403) or
adopt more aggressive policies like dropping connections.
Paragraph (version B):
Servers use quota mechanisms to avoid systems overload, to ensure an
equitable distribution of computational resources or to enforce other
policies - e.g. monetization.
Paragraph (version B):
A basic quota mechanism limits the number of acceptable requests in a
given time window, e.g. 10 requests per second.
Paragraph (version B):
When quota is exceeded, servers usually do not serve the request
replying instead with a "4xx" HTTP status code (e.g. 429 or 403) or
adopt more aggressive policies like dropping connections.
Paragraph (version A):
communicated out-of-band (eg. in the documentation).
Paragraph (version B):
communicated out-of-band (e.g. in the documentation).
Paragraph (version A):
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
subsequent requests eg. in case of resource saturation or to
implement sliding window policies.
Paragraph (version B):
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
subsequent requests e.g. in case of resource saturation or to
implement sliding window policies.
Paragraph (version A):
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.
Paragraph (version B):
Servers should be careful in returning "RateLimit" fields in
redirection responses (e.g. 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.
Paragraph (version A):
Under certain conditions, a server MAY artificially lower "RateLimit"
field values between subsequent requests, eg. to respond to Denial of
Service attacks or in case of resource saturation.
Paragraph (version B):
Under certain conditions, a server MAY artificially lower "RateLimit"
field values between subsequent requests, e.g. to respond to Denial
of Service attacks or in case of resource saturation.
Paragraph (version A):
The value of "RateLimit-Reset" is generated at response time: a
client aware of a significant network latency MAY behave accordingly
and use other information (eg. the "Date" response header field, or
otherwise gathered metrics) to better estimate the "RateLimit-Reset"
moment intended by the server.
Paragraph (version B):
The value of "RateLimit-Reset" is generated at response time: a
client aware of a significant network latency MAY behave accordingly
and use other information (e.g. the "Date" response header field, or
otherwise gathered metrics) to better estimate the "RateLimit-Reset"
moment intended by the server.
Paragraph (version A):
Alternatively, given the same context where the previous example
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,
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
window.
Paragraph (version B):
Alternatively, given the same context where the previous example
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,
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
window.