IETF RateLimit-Policy draft vs Sume's ratelimit-* headers

Sume's docs do not list the draft's RateLimit-Policy or RateLimit fields. They list separate numeric headers, ratelimit-limit, ratelimit-remaining and ratelimit-reset, plus retry-after on a 429. So a client written to the draft's structured syntax will not find those fields; read the plain numbers instead.

Draft facts are from the Internet-Draft page (it says it expires on 24 November 2026); Sume facts from Errors, read 2026-10-01.

What does the draft define?

Its abstract: it defines the RateLimit-Policy and RateLimit header fields so servers can advertise quota policies and current limits. Its examples look like RateLimit-Policy: "burst";q=100;w=60, a named policy with quota and window. If a response carries both RateLimit and Retry-After, Retry-After takes precedence.

What does Sume send today?

How should a client read both?

Use retry-after first on a 429, which matches the draft's precedence rule. Otherwise pace on ratelimit-remaining and ratelimit-reset. A 429 names its budget in error.details.scope, either read or write; see 429 scope.

What does a dual-format parser look like?

Draft-style quota strings carry q (quota) and w (window) parameters; Sume's headers are bare integers. A client can accept either by checking for the plain header first.

function readLimits(headers) {
  const remaining = Number(headers.get("ratelimit-remaining"));
  const reset = Number(headers.get("ratelimit-reset"));
  const retry = headers.get("retry-after");
  if (retry !== null) return { waitSeconds: Number(retry) };
  if (Number.isFinite(remaining) && remaining <= 0) {
    return { waitSeconds: Number.isFinite(reset) ? reset : 1 };
  }
  return { waitSeconds: 0 };
}

Is request rate the same as generation capacity?

No. The docs say how many generations run at once is governed by the plan's concurrency limit, a separate thing from these headers.