Original text:
available in that moment.  Nonetheless servers MAY decide to send the "RateLimit" fields in a trailer section.  5. This section documents the considerations advised in Section 16.3.3 with the expected ones.  This includes a "RateLimit-Reset" moment too far in the future or a "service-limit" too high.  Malformed "RateLimit" fields MAY be ignored. A client SHOULD NOT exceed the "quota-units" expressed in "RateLimit-

Reviewer comments:
servers are not forced to always return ratelimit fields clients must not assume the presence of ratelimit fields performance hints for providers
Waiting for NAME then :)
NAME PTAL :)
Looks great to me. The intent is nice and clear.
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, Remaining 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 Erik. In https://ietf-wg-URL 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 don'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: implementations use all 3 fields. Though theoretically one could just return and , I never found an implementation doing this :heavycheckmark: implementations don'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-URL I now think that we shouldn't mess with status codes. NAME if this sounds reasonable to you, I can provide a PR
Yes, it sounds good, thank you!
Looks good!

Revised text:
available in that moment.  Nonetheless servers MAY decide to send the "RateLimit" fields in a trailer section. <ins> 4.1. Servers are not required to return "RateLimit" fields in every response, and clients need to take this into account.  For example, an implementer concerned with performance might provide "RateLimit" fields only when a given quota is going to expire. Implementers concerned with response fields' size, might take into account their ratio with respect to the payload data, or use header- compression http features such as HPACK. </ins> 5. This section documents the considerations advised in Section 16.3.3 with the expected ones.  This includes a "RateLimit-Reset" moment too far in the future or a "service-limit" too high. <ins> A client receiving "RateLimit" fields MUST NOT assume that subsequent responses contain the same "RateLimit" fields, or any "RateLimit" fields at all. </ins> Malformed "RateLimit" fields MAY be ignored. A client SHOULD NOT exceed the "quota-units" expressed in "RateLimit-