search

ietf-wg-httpapi / ratelimit-headers

Repository for IETF WG draft ratelimit-headers
Other
45 stars 5 forks source link

Describe RateLimit-Remaining using structured-field-values #22

Closed ucarion closed 3 years ago

ucarion commented 3 years ago

From the discussion here:

https://github.com/ietf-wg-httpapi/ratelimit-headers/issues/6#issuecomment-750279717

This PR specifies the RateLimit-Remaining field using some of the language recommended here:

https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#name-defining-new-structured-fie

To me, the big open question remaining is what this document's stance is on parameters for RateLimit-Remaining. Shall we prohibit them? I'd prefer to say that they are always permitted, and that clients should ignore parameters they don't understand. This is in line with the recommendations in the structured fields document:

Both Items and Inner Lists allow parameters as an extensibility mechanism; this means that values can later be extended to accommodate more information, if need be. To preserve forward compatibility, field specifications are discouraged from defining the presence of an unrecognized parameter as an error condition.

If we say that parameters are strictly prohibited, then we're cutting ourselves off from having a forward compatibility option, and we're preventing users from coming up with their own extension points.

ioggstream commented 3 years ago

@ucarion I just added SF in the normative references and reused it.

ucarion commented 3 years ago

@ioggstream The spec we're working off of isn't called "structured headers" any more. It's called "structured field values": https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html (take note of the title of the document and the language within it, not the I-D's name, which is irrelevant) -- is changing back to calling it "headers" intentional?

unleashed commented 3 years ago

Regarding https://github.com/ietf-wg-httpapi/ratelimit-headers/issues/45#issuecomment-800454303 I agree we should add a note documenting the expectation that implementors need SFV parsing to "upgrade" to this document (even if it is obvious by going through the document, it still helps to keep this information explicit on its own).

ioggstream commented 3 years ago

Closed in favor of #58 . Thanks @ucarion for starting this work!