External Standards Reference List

The platform does not invent protocol semantics: the HTTP failure contract, the query predicate, the OAuth token family, the TOTP algorithm, and CSV escaping are all anchored to public standards. This page consolidates the external-standard references scattered across source comments, architecture documents, and this manual into one lookup — each entry carries the document name, authoritative link, source-code locations, and the adoption mode. Document numbers and titles follow the IETF / NIST / W3C official publication pages; every revision of this page must re-verify the links — never cite a number or clause from memory.

Citation discipline

Three hard rules, applying to code comments, architecture documents, and this manual:

1. Cite as “link + clause number + one-sentence accurate paraphrase”. “RFC 7009 §2.1: the revocation endpoint returns 200 even for unknown tokens, preventing enumeration” is a valid citation; “handle it as the RFC requires” is not.
2. Strictly separate “what the standard requires” from “this platform’s engineering choice”. Anything a standard does not specify (such as a 300-second re-authentication window) must be stated as a factory default or platform convention, never dressed up as a standard clause. A long-standing counterexample is “NIST SP 800-63B requires sensitive-operation re-authentication within 15 minutes” — SP 800-63B (Authentication and Lifecycle Management) only grades assurance as AAL1–AAL3 in §4.3; re-authentication cadence is a deployer risk decision, and the platform’s factory values are unrelated to that standard.
3. Distinguish four adoption modes: implemented (standard semantics implemented as written), extended (standard semantics plus platform extension fields), intentional deviation (the deviation and its rationale are stated), and contextual citation (the standard’s terminology or gradings express design intent without claiming conformance). The tables below tag each entry.

HTTP semantics and API contract

RFC 9457 is the unified shape of every failure response: beyond type/title/status/detail, the platform adds five extension members — errorCode, errorType, traceId, correlationId, requestId. Those extensions are platform increments, not standard requirements (the long-term decision is ADR 0108 in the BitzOrcasVNext repository). The actual shape:

// RFC 9457 ProblemDetails with platform extension members (errorCode/errorType/
// traceId flattened onto the root).
HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{
  "type": "https://docs.bitzsoft.com/problems/business-rule-violation",
  "title": "Business rule",
  "status": 422,
  "detail": "再认证策略行已被他人修改，请刷新后重试。",
  "errorCode": "Identity.StepUp.PolicyVersionConflict",
  "errorType": "Failure"
}

# RFC 10008 QUERY: filters travel in the JSON body, not the URL; proxies without
# custom-method support forward as POST /api/announcements/_query per the
# platform fallback convention.
curl -s -X QUERY https://localhost:5001/api/announcements \
  -H "Content-Type: application/json" \
  -d '{"pageIndex":1,"pageSize":20,"searchText":"条件"}'

RFC 10008 unifies pagination, listing, and search reads as QUERY requests with a JSON body; the POST {path}/_query fallback is a platform engineering choice for proxies and runtimes that lack custom-method support — the standard itself defines no such fallback. RFC 10008 also requires cache keys to include the request content, which is why the platform blocks plain Output Cache on QUERY endpoints via BZEP005.

Authentication, authorization, and tokens

RFC 9470 §3 defines the resource-server challenge as 401 + WWW-Authenticate: Bearer error="insufficient_user_authentication" (optionally with acr_values/max_age). This platform serves first-party SPAs with no redirect loop and intentionally deviates to 403 + RFC 9457 ProblemDetails extension fields (purpose/factors/windowSeconds) — the deviation, rationale, and interop boundary are detailed in Step-Up re-authentication. Integrators implement the platform’s 403 contract, not RFC 9470 client logic. NIST SP 800-63B is used contextually via the §4.3 AAL gradings; its text contains no clause such as “re-authenticate within 15 minutes”, and the platform’s 300/900-second windows are factory defaults.

Multi-factor authentication factors

TOTP algorithm parameters and drift handling follow the MFA connector implementation; HOTP (RFC 4226) is mentioned in the manual alongside RFC 6238 as the underlying algorithm.

Data formats and interoperability

Draft tracking and implicit conformance

The following are kept out of the main table, with the reason and watch policy for each:

• Idempotency-Key header: the idempotency pipeline carries its key in the Idempotency-Key request header. The corresponding draft (draft-ietf-httpapi-idempotency-key-header-07) expired in October 2025 without becoming an RFC, but the header name is the de-facto industry standard (Stripe and others). Policy: keep as is; align on parameter details if the draft revives.
• RateLimit response header fields: draft-ietf-httpapi-ratelimit-headers-11 is still an active draft (May 2026), not an RFC. Platform 429 responses express backoff via the standard Retry-After header (RFC 9110 semantics) plus the ProblemDetails retryAfterSeconds extension. Policy: evaluate adoption once it becomes an RFC.
• JWT (RFC 7519) / HMAC (RFC 2104): token issuance and API-client signing go through standard libraries; the source code does not cite the numbers explicitly — implicit conformance.

Deliberately not adopted

The following standards were evaluated and explicitly rejected; the rationale is registered here so future sessions do not re-raise them as gaps:

• JSON Patch (RFC 6902): the coding red lines forbid generic patches on core aggregates — state changes must go through explicit Commands to keep authorization, validation, and audit pipeline coverage. Partial updates are expressed as explicit partial commands.
• Hypermedia controls (HAL / JSON:API / Link-header pagination, RFC 8288 / RFC 9652): the platform carries navigation via self-describing pagination envelopes (PagedResult + page-level Meta companion injection) consumed by contract; API responses do not adopt hypermedia semantics.

Manual cross-reference index

Convention for new citations

When introducing a new external-standard reference into code or the manual: open the official publication page and verify the number, title, and clause text first; in source comments write “standard name + clause number + semantics”, never a bare number; decisions that are platform engineering choices belong in an adjacent ADR or manual page stating the deviation; finally, register the entry on this page — this page is the single authoritative list, and scattered citations reconcile against it.