Original text:
The source code and issues list for this draft can be found at https://github.com/ietf-wg-httpapi/ratelimit-headers [2].  1. The widespreading of HTTP as a distributed computation protocol The "w" parameter specifies a time window.  Its syntax is a "time- window" defined in time-window. <del> Other parameters are allowed and can be regarded as comments. </del>  An example policy of 100 quota-units per minute. 10. <del> 10.1. This section registers the "RateLimit-Limit" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (SEMANTICS). Field name: "RateLimit-Limit" </del>  <del> Status: permanent </del>  <del> Specification document(s): ratelimit-limit-field of this document 10.2. This section registers the "RateLimit-Remaining" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (SEMANTICS). </del>  <del> Field name: "RateLimit-Remaining" </del>  <del> Status: permanent </del>  <del> Specification document(s): ratelimit-remaining-field of this document </del>  <del> 10.3. </del>  <del> This section registers the "RateLimit-Reset" field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (SEMANTICS). </del>  <del> Field name: "RateLimit-Reset" </del>  <del> Status: permanent </del>  <del> Specification document(s): ratelimit-reset-field of this document </del>  11.  References [1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ietf-wg-httpapi/ratelimit-headers 

Reviewer comments:
Merge three "add to table" into one request to "add these to the table" Create a new registry for quota fields.
looks good!
NAME NAME I made some edits: ad an addressable subsection for iana-ratelimit-parameters add , to iana table reference specification sections in IANA registries removed normative parts from IANA mention IANA table in {{quota-policy}} Could you please PTAL?
ooops I missed your comment :) Ok, let's merge.
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?

Revised text:
The source code and issues list for this draft can be found at https://github.com/ietf-wg-httpapi/ratelimit-headers [2]. <ins> References to "ThisRFC" in the IANA Considerations section would be replaced with the RFC number when assigned. </ins> 1. The widespreading of HTTP as a distributed computation protocol The "w" parameter specifies a time window.  Its syntax is a "time- window" defined in time-window.  <ins> Other parameters are allowed and can be regarded as comments.  They ought to be registered within the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters Registry", as described in iana-ratelimit- parameters. </ins> An example policy of 100 quota-units per minute. 10.  <ins> IANA is requested to update one registry and create one new registry. </ins>  <ins> Please add the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (SEMANTICS): </ins>  <ins> 10.1. </ins>  <ins> IANA is requested to create a new registry to be called "Hypertext Transfer Protocol (HTTP) RateLimit Parameters Registry", to be located at https://www.iana.org/assignments/http-ratelimit-parameters [3].  Registration is done on the advice of a Designated Expert, appointed by the IESG or their delegate.  All entries are Specification Required (IANA, Section 4.6). </ins>  <ins> Registration requests consist of the following information: </ins>  <ins> Parameter name: The parameter name, conforming to SF. </ins>  <ins> Field name: The RateLimit field for which the parameter is registered.  If a parameter is intended to be used with multiple fields, it has to be registered for each one. </ins>  <ins> Description: A brief description of the parameter. </ins>  <ins> Specification document: A reference to the document that specifies the parameter, preferably including a URI that can be used to retrieve a copy of the document. </ins>  <ins> Comments (optional): Any additional information that can be useful. </ins>  <ins> The initial contents of this registry should be: </ins> 11.  References [1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ietf-wg-httpapi/ratelimit-headers <ins> [3] https://www.iana.org/assignments/http-ratelimit-parameters </ins>