Summary

  • On 31 August, the IESG opened an IETF-wide Last Call on advancing RFC 7405 to Internet Standard and adding it to STD 68. Comments close on 28 September; no decision has been announced.
  • RFC 7405 added readable case-sensitive and explicit case-insensitive string literals to ABNF in 2014. It remains a Proposed Standard even though important specifications now reference it.
  • The status-change request cites 20 normative RFC references as of the second quarter of 2026, HTTP/1.1, YANG, broad tool support and no known interoperability problems.
  • RFC 6410 asks a different set of questions: are there at least two independent interoperating implementations, widespread deployment and successful operational experience? The request does not publicly crosswalk its aggregate claims to named examples.
  • A compact maturity-evidence receipt could close that gap without restoring the formal interoperability report that RFC 6410 deliberately removed.

The label is changing, not the grammar

ABNF is the compact notation that many Internet specifications use to define syntax. RFC 5234 made its base form STD 68. In that base form, a quoted literal without a prefix is matched without regard to case. Writers who needed an exact lowercase or uppercase sequence traditionally encoded each character as decimal or hexadecimal octets.

RFC 7405 replaced that inconvenience with two readable prefixes. %s"false" is case-sensitive. %i"aBc" is explicitly case-insensitive. An unprefixed string keeps the older case-insensitive behaviour. The extension was published in December 2014 as a Proposed Standard and updates two parts of RFC 5234.

The new Last Call proposes no replacement text. Under RFC 6410, the IESG can reclassify the existing RFC after at least four weeks of IETF-wide review. The 31 August notice says the request came from an individual participant, that a decision is planned in the following weeks and that substantive comments are due by 28 September. The Datatracker still showed AD Review at the evidence cutoff.

That state matters. A Last Call is an invitation to test the case, not a finding that the case has passed. A status-change request is evidence submitted to the deciding body, not the decision itself.

The request makes a credible aggregate case

The promotion request is not empty. It says 20 RFCs normatively referenced RFC 7405 in the second quarter of 2026. It points to HTTP/1.1 and YANG as important users and says ABNF tools now widely implement the extension. It reports no known interoperability problem, no divergent interpretation and no controversy over the technical choice.

The public dependency page reinforces the direction of travel. It lists RFCs across HTTP, YANG, mail, media, CDDL, DNS and other areas, as well as active drafts. RFC 7950 makes the feature visible: its YANG 1.1 grammar uses %s repeatedly for case-sensitive keywords such as module, container, leaf and rpc.

The request also gives a useful counterexample. RFC 9535, published in 2024, still spells lowercase true, false and null as hexadecimal byte sequences. That does not show a parser failure. It shows that even recent authors may hesitate to assume the extension. Adding RFC 7405 to STD 68 could make the combined grammar authority easier to read.

The remaining RFC 6410 criteria look straightforward. RFC 7405 is four pages and has one narrow feature. The cited erratum proposing single quotes was rejected. The request reports no erratum that would cause a new implementation to fail against deployed ones, no materially unused complexity and no patent or controlled-technology issue.

Those are substantial reasons to consider promotion. None should be weakened by pretending that a citation count says more than it does.

Five propositions are compressed into one paragraph

RFC 6410 characterizes an Internet Standard as technically mature and beneficial, then states the first advancement criterion precisely: at least two independent interoperating implementations with widespread deployment and successful operational experience.

The status-change request answers that criterion with specification references, two consequential specifications, a broad statement about tools and the absence of known problems. It does not publicly name two implementations, their versions or maintainers. It does not explain how code-base independence was assessed, which grammar corpus crossed between them, where the feature was deployed, how broad that deployment was, how long it was observed or what counted as successful operation.

This is an observation about the submitted public record, not an allegation of failure. The implementations may be obvious to specialists. Evidence may exist in private operational experience, project repositories or mailing-list memory. HTTP and YANG have enormous deployed footprints, but a normative reference inside a specification is not automatically proof that deployed software exercises the referenced syntax. The Datatracker itself warns that its dependency extraction is heuristic.

Nor does “no known problem” reveal the observation surface. It may be strong evidence when several independent maintainers have parsed real grammars for years. It is weaker when nobody has recorded which implementations, inputs and deployment contexts would have exposed divergence.

Do not rebuild the old test ceremony

The strongest answer to this critique sits in RFC 6410 itself. The IETF deliberately removed the requirement for a formal interoperability report. Deployment and use can demonstrate interoperability. A small grammar feature that has circulated for twelve years should not need an artificial laboratory event merely to produce paperwork.

That design is sensible. A complete census would be expensive, would become stale quickly and could mistake documentation volume for technical quality. The Last Call is also the proper public place for participants to add examples, dispute the threshold or say that the explanation is sufficient.

The remedy is therefore not a new gate. It is a thin receipt attached to the existing case. For at least two examples, the record could name an implementation and version, the basis for code-base independence, the RFC 7405 construct exercised, a common grammar corpus or counterpart, the deployment class, an observation interval, the successful result, known exclusions and a stable source. A bounded description can protect proprietary or security-sensitive operations.

The IESG could then state separately why those examples together count as widespread deployment and successful operational experience. Significant Last Call objections could receive dispositions without turning the discussion into a vote tally. The final announcement would remain the institutional act that changes the status.

Running code needs an attributable path

Heng Lu’s running-code principle is most useful here as an evidentiary discipline. Code checks whether a technical claim survives implementation. But the phrase “running code” becomes rhetoric if the record cannot identify what ran, independently from what, on which input and with what result.

The distinction also protects authority. Implementers provide evidence; normative references show uptake; Last Call participants provide objections and experience; the IESG decides under the published process. None of those roles alone manufactures the others’ mandate.

RFC 7405 may well deserve promotion. This Article does not decide that question. It asks that an Internet Standard label carry the small public bridge between a plausible aggregate story and the concrete operational propositions the label is meant to certify.

Sources

  1. IETF — Last Call: Advance RFC 7405 to Internet Standard
  2. IETF Datatracker — RFC 7405 status-change request
  3. RFC 6410 — Reducing the Standards Track to Two Maturity Levels
  4. RFC 7405 — Case-Sensitive String Support in ABNF
  5. IETF Datatracker — References to RFC 7405
  6. RFC 5234 — Augmented BNF for Syntax Specifications
  7. RFC 7950 — The YANG 1.1 Data Modeling Language
  8. RFC 9535 — JSONPath: Query Expressions for JSON
  9. RFC Editor — Errata for RFC 7405
  10. Heng Lu — Running-Code Primacy