Summary

  • Revision 10 of draft-ietf-mediaman-6838bis became available on 9 September 2026 UTC. It is an active Media Type Maintenance working-group draft, not an RFC or a completed IANA action.
  • The revision replaces fragment-identifier precedence based on runtime success with a static compatibility rule: a media type must respect syntax required by its structured suffix; otherwise the media type controls fragment handling.
  • It names thirteen IANA suffix records whose three-case rule cannot be exercised because those same records say the suffix defines no fragment syntax. The live registry still carried both statements when checked.
  • One approved correction will have thirteen execution targets. I propose a fan-out correction manifest joining the governing text to each before-and-after registry row. This is Daniel Kade’s editorial proposal, not draft policy.

The defect multiplied when it entered the registry

Revision 09 described a first-match sequence. A processor would first ask whether the structured syntax suffix defined fragment handling and whether the fragment successfully resolved under those rules. If it did, the suffix won. Otherwise, the specific media type decided. Working-group issue 93 pointed out the circularity: the governing rule was selected partly by the result of trying to apply it.

Revision 10 removes that runtime switch. Where a suffix registration actually specifies fragment syntax and semantics, a media type using it must be consistent with the suffix and may not forbid syntax the suffix requires. Where the suffix does not specify such handling, the media type decides. The 09-to-10 diff makes this a substantive change rather than a new explanation of the old algorithm.

That would already be a useful standards edit. The more important governance change appears in the new IANA instructions. They identify +json, +ber, +cbor, +der, +fastinfoset, +wbxml, +zip, +tlv, +json-seq, +sqlite3, +jwt, +gzip and +cbor-seq. Each record contains three cases inherited from the pattern in RFC 6839. Each also records that no fragment syntax is defined for the suffix. The draft’s conclusion is narrow: the cases cannot arise, so IANA should remove that text while retaining the rest of each record.

A live row is not changed by a draft sentence

The IANA registry was last marked updated on 25 June 2026 when checked for this article. It listed 24 records, an Expert Review policy and two designated experts. A direct inspection found the named thirteen rows still carried the three case clauses and their no-syntax statement. That is the expected pre-change state. It does not mean IANA ignored revision 10: the document remains work in progress and tells IANA what to do if the text advances.

The roles should stay separate. The Media Type Maintenance working group develops the replacement for RFC 6838. IANA maintains the registry. Designated experts review under the registry’s policy, whose general model is described in RFC 8126. The IESG manages experts for IETF-created registries and may be involved where appropriate. A working-group revision is evidence of proposed rule text; it is not evidence that thirteen registry mutations have been executed.

The current record also contains a metadata wrinkle worth preserving without exaggeration. The draft header says its intended status is Best Current Practice, while the Datatracker page currently displays no intended RFC status. Its working-group state is In WG Last Call, a state first recorded for revision 06 in October 2025. None of those labels makes revision 10 an RFC.

What the correction does—and does not—decide

Structured suffixes let software recognise an underlying format in names such as a type ending in +json or +zip. They do not make every media type with that ending semantically interchangeable. Revision 10 says the relationship between a suffixed type and the type produced by removing the suffix cannot be known from the names alone. Fragment interpretation and security properties may still be media-type-specific.

Removing unreachable prose therefore repairs the common registry guidance. It does not create a fragment language for any of the thirteen suffixes, change an application’s implementation, prove interoperability or document a past failure. No incident or exploit is established by these sources. RFC 3986 supplies the URI fragment model; it does not decide the application semantics of every registered media type.

Revision 10 also folds in the top-level-type work of RFC 9694 and says it would obsolete RFC 6838 and RFC 9694 if approved. Those broader changes matter, but they are not evidence that the thirteen-row cleanup has already happened.

A correction manifest for the fan-out

Publication of a governing document and completion of a registry edit are different transitions. The first authorises a common change. The second applies it to public records. For a one-to-thirteen correction, I would preserve a compact manifest with:

  1. the published governing document, section and immutable fingerprint;
  2. the exact list of targeted suffix records;
  3. each record’s stable identity and pre-change fingerprint;
  4. the text class authorised for removal;
  5. a fingerprint of the content that must be retained;
  6. the IANA action and execution time;
  7. the designated-expert disposition, where required;
  8. any IESG disposition invoked by the instruction;
  9. each post-change fingerprint; and
  10. a correction or reversal link if a row later needs repair.

This is deliberately smaller than an implementation report. It does not prescribe how applications process fragments and need not expose private deliberation. It answers one public question: did the approved correction reach every named registry row without silently changing unrelated content?

The approach follows the minimum-initial-specification discipline in Heng Lu’s essay: standardise the smallest shared evidence needed for coordination, while leaving media-type-specific behaviour where the relevant specification places it.

Evidence boundary

The Datatracker record and history establish revision and process state. The preceding revision, the merged pull request and its merge commit establish the change path. They do not prove future publication or registry execution.

Sources