Change:
uses structured fields based on NAME preliminary work: thanks!!!referencing the RFC distinguishing sf-item and sf-integer, since sf-integer do not support parameters whereas sf-item does retaining the intermediate syntaxes (quota-policy, quota-units, service-limit, ...)
LGTM, waiting on ack from NAME before merging.
NAME thanks for reviewing! Can we merge?
It's your draft :)
I take it for a YES :D
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review. That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?

Discussion:
The term Origin is to be interpreted as described in Section 7 of RFC6454. <del> The "delay-seconds" rule is defined in Section 10.2.3 of SEMANTICS. </del> <ins> This specification uses Structured Fields SF to specify syntax. The terms sf-list, sf-item, sf-string, sf-token, sf-integer, bare- item and key refer to the structured types defined therein. </ins> 2.

A time window is expressed in seconds, using the following syntax: <ins> Where "delay-seconds" is a non-negative sf-integer compatible with the "delay-seconds" rule defined in Section 10.2.3 of SEMANTICS. </ins> Subsecond precision is not supported. 2.2.

The "service-limit" is expressed in "quota-units" and has the following syntax: <ins> where quota-units is a non-negative sf-integer. </ins> The "service-limit" SHOULD match the maximum number of acceptable requests.

This specification allows describing a quota policy with the following syntax: <del> quota-policy parameters like "w" and quota-comment tokens MUST NOT occur multiple times within the same quota-policy. </del> <ins> where the associated bare-item is a service-limit and parameters are supported. The following parameters are defined: The "w" parameter specifies a time window.  Its syntax is a "time- window" defined in time-window. Other parameters are allowed and can be regarded as comments. </ins> An example policy of 100 quota-units per minute. The definition of a quota-policy does not imply any specific distribution of quota-units over time.  Such service specific details <del> can be conveyed in the "quota-comments". </del> <ins> can be conveyed as parameters. </ins> <del> Two examples of providing further details via custom parameters in "quota-comments". </del> <ins> Two examples of providing further details via custom parameters </ins> 3.

If the client exceeds that limit, it MAY not be served. <del> The field value is </del> <ins> The field is a List Structured Field of positive length.  The first member is named "expiring-limit" and its syntax is "service-limit", while the syntax of the other optional members is "quota-policy" </ins> The "expiring-limit" value MUST be set to the "service-limit" that is closer to reach its limit.

The "RateLimit-Remaining" response field indicates the remaining "quota-units" defined in service-limit associated to the client. <del> The field value is </del> <ins> The field is an Integer Structured Field and its value is </ins> This field MUST NOT occur multiple times and can be sent in a trailer section.

the number of seconds until the quota resets. <del> The field value is </del> <ins> The field is an Integer Structured Field and its value is </ins> The delay-seconds format is used because: