Original text:
quotas. This was partially addressed by the "Retry-After" header field <del> defined in SEMANTICS to be returned in "429 Too Many Requests" (see STATUS429) or "503 Service Unavailable" responses. </del>  Widely deployed quota mechanisms limit the number of acceptable requests in a given time window, e.g. 10 requests per second;

Reviewer comments:
moves quota-policies from RateLimit-Limit -> RateLimit-Policyrequires WG discussion -
Given this hint from Mark URL I think it's fine to merge this PR (separate Policy from Limit) since there seems to be agreement to use different fields at least in this case.
Perhaps best to continue discussion in that issue before merging this? While the change will happen in a similar vein, we might want to wait to flesh out further details.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in
The draft today suggests putting quota policies, a list, into the header. But that's a sort of breaking change, because that header's equivalent is strictly a number (not a list) in most existing implementations. Could be kept as a plain number (like and ), and instead a new header like or some such can contain supplementary information? That way, the story for upgrading to this draft is simpler. Sorry if this is asked and answered.
iirc we considered this but we initially had some requests of conflating as much as possible in fewer fields. Probably it's a more interoperable choice. I am open in re-considering the idea, provided we get in touch with the current implementers including 3scale, kong and envoy cc: 3scale: NAME , kong: NAME , envoyproxy: NAME
There's no inherent problem in using a specific header for policies, and no issue in moving to use them from the 3scale side. The only downside is we're adding yet another header for rate limiting, currently 4 of them, which might raise a few eyebrows.
NAME thanks :) do you think that splitting is a more interoperable choice wrt to the parsing implementation / usability? Do you see other practical drawbacks? if we don't get feedback on this issue, can you ping the other implementers you know?
Yes, it's easier for people to pick up a new header for this to apply a policy, since as it stands they might break when seeing extra stuff in the limit one by expecting a single value rather than multiple, as NAME mentions above. No, just dealing with people (maybe) opposing too-many-headers - I don't know if this is something that we can predictably foresee happening in the HTTPAPI WG or in the HTTP WG, but my intuition says "likely" given how we were asked to "condense" this information, so I think we might want to spend some time making a good case out of it. NAME other than potential breakages in pre-existing implementations, is there any additional point we could make to justify the additional header? I think they are all currently listed - that being said I think porting to a new header should be an easy task, so hopefully not a problem.
if almost everyone is implementing just the minimal specification, probably this could even simplify the addition of ...
The primary motivation is breakage, as you suggest, NAME The secondary motivation is ease of "upgrading" to adoption of quota policies, as NAME suggests. The flipside of "easy to adopt, easy to upgrade" is that the spec would also make it easy to never upgrade at all. This is a good thing, supposing that most services can operate perfectly fine without quota policies. A third, much weaker argument, is that the current approach of putting the "limit" and "quota policy" in the same header is that it's confusing. I would need more time to really state this argument more clearly, but what rubs me the wrong way here is that the current design basically puts two different kinds of data in the same list. As it stands, is a list of a numbers, but the first number (the "limit") is not like the rest of the numbers (the policy). The first number cannot have SFV parameters, but the others can (and typically will). It's an accident of SFV's syntax that this is even conceivable as an approach. For implementors, this means that does not simply deserialize as some sort of . It deserializes into a list, where the first element is an and the tail is a . I fear this will at minimum confuse folks, and perhaps even lead to incorrect implementations, such as people not realizing the first element of the list is not a quota policy at all.
Given URL it seems there's some consensus in providing quota policy in a separate field.

Revised text:
quotas. This was partially addressed by the "Retry-After" header field  <ins> defined in SEMANTICS to be returned in 429 (Too Many Request) (see STATUS429) or 503 (Service Unavailable) responses. </ins> Widely deployed quota mechanisms limit the number of acceptable requests in a given time window, e.g. 10 requests per second;