Draft: draft-ietf-httpapi-ratelimit-headers

Commentary: uses structured fields based on 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 before merging . 
 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 :  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 ca n't think of a good example off the top of my head that would n't be using a separate registry or document to manage that . What 's your thinking about where to keep this registry ? 
 registries are usually maintained by IANA : we can check with if that 's possible ... 
 We can pretty easily define a registry . You include a section in the RFC . See 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 
 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 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 : 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 . " 
 we just merged structured fields in RateLimit Headers ! 
 Thanks for the ping , I saw :) I 'll propose a PR soon . 
 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 ?
Paragraph (version A):
The "delay-seconds" rule is defined in Section 10.2.3 of SEMANTICS.
Paragraph (version B):
This specification uses Structured Fields SF to specify syntax.
Paragraph (version B):
The terms sf-list, sf-item, sf-string, sf-token, sf-integer, bare-
item and key refer to the structured types defined therein.
Paragraph (version B):
Where "delay-seconds" is a non-negative sf-integer compatible with
the "delay-seconds" rule defined in Section 10.2.3 of SEMANTICS.
Paragraph (version B):
where quota-units is a non-negative sf-integer.
Paragraph (version A):
quota-policy parameters like "w" and quota-comment tokens MUST NOT
occur multiple times within the same quota-policy.
Paragraph (version A):
The definition of a quota-policy does not imply any specific
distribution of quota-units over time.  Such service specific details
can be conveyed in the "quota-comments".
Paragraph (version A):
Two examples of providing further details via custom parameters in
"quota-comments".
Paragraph (version B):
where the associated bare-item is a service-limit and parameters are
supported.
Paragraph (version B):
The "w" parameter specifies a time window.  Its syntax is a "time-
window" defined in time-window.
Paragraph (version B):
Other parameters are allowed and can be regarded as comments.
Paragraph (version B):
The definition of a quota-policy does not imply any specific
distribution of quota-units over time.  Such service specific details
can be conveyed as parameters.