Summary

  • RFC 7865 identified the SIPREC recording-metadata XML document as application/rs-metadata+xml, while RFC 7866 used the truncated application/rs-metadata in its procedures and examples.
  • Erratum 7987 reported that contradiction in June 2024 and still displays Held for Document Update. RFC 9806, published on the Standards Track in June 2025, updates RFC 7866, replaces every old instance and says it resolves the erratum.
  • RFC 9806 also supplied the IANA registration that the two 2016 documents had omitted. The current registry row names application/rs-metadata+xml and cites RFC 7865 and RFC 9806.
  • Those records establish the current specification. They do not show which deployed SRC or SRS accepts which label, what a live INVITE or UPDATE carried, how a multipart body was parsed, or what an archive stored. A correction-custody receipt must bind those facts.

Four records can agree while two machines still disagree

The contradiction was small enough to fit in four characters and important enough to require a new Standards Track RFC.

RFC 7865, the 2016 recording-metadata specification, describes participant details and other metadata as a recording-specific XML document of type application/rs-metadata+xml. RFC 7866, published the same month, defines the Session Recording Protocol but repeatedly calls the content application/rs-metadata. Its Section 9, sample initial INVITE and sample snapshot request all use the shorter name.

That was not a dispute over whether the body was XML. RFC 7866 points back to RFC 7865 for the format. It was a disagreement over the identifier carried in MIME-aware protocol fields. A parser can understand the same bytes and still refuse a body whose Content-Type does not match its dispatch table. A generator can produce valid SIP and valid XML while advertising the wrong registered type.

Erratum 7987 recorded the mismatch on 12 June 2024. Its current page says Held for Document Update, gives the old and corrected strings, and notes that neither original RFC had registered the type. That status is part of the evidence. It is not the same thing as a Verified erratum, and this article does not rename it.

RFC 9806 supplies the later decision. Published in June 2025 as an IETF Standards Track document, it carries Updates: 7866. It says RFC 7865 is the normative metadata definition, states that Erratum 7987 reported the problem, and declares that the new document resolves it. Its operative rule is direct: every application/rs-metadata instance in RFC 7866 is replaced by application/rs-metadata+xml.

The record is therefore no longer ambiguous about the current name. The deployment may still be.

An update does not erase the page an implementer once read

RFC publication preserves history. Opening the original RFC 7866 text today still shows the shorter label in Section 9 and Figures 12 and 13. RFC 9806 does not silently rewrite that file. It adds an explicit update that changes how the combined specification is to be implemented now.

That design is valuable: a reviewer can see the original claim, the reported inconsistency and the later resolution. It also means that evidence is distributed. A developer who reads only RFC 7866 can copy the old type. A compliance inventory that stores only “RFC 7866 supported” cannot reveal which reading the product implements. An errata scraper that records only the current Held status can miss the later RFC that says the issue is resolved. A registry check can find the right row without proving that a release ever consumed it.

These are not defects in the archival model. They are reasons to keep document state separate from implementation state.

The four relevant records answer different questions. RFC 7865 says what the metadata document type was intended to be. RFC 7866 shows where the inconsistent identifier entered the wire procedure. Erratum 7987 preserves the report and its disposition state. RFC 9806 provides the formal update and registration. None is an inventory of running software.

The IANA row closes the namespace gap

RFC 9806 says neither 2016 RFC registered the media type and then provides the missing template. The registration defines type application, subtype rs-metadata+xml, no required or optional parameters, and encoding considerations aligned with application/xml under RFC 7303. It identifies Session Recording Clients and Session Recording Servers as the applications, gives intended usage as COMMON and leaves change control with the IETF.

The IANA Media Types registry captured on 20 September 2026 lists application/rs-metadata+xml with references to RFC 7865 and RFC 9806. That row performs a precise coordination function: it gives the name a public home and references the specifications that define and correct it.

The +xml suffix also carries a useful machine-readable fact. RFC 7303 explains that it lets generic XML-aware software recognize an XML MIME entity. It does not tell an implementation that the document conforms to the SIPREC schema, belongs to the right Recording Session or contains a coherent sequence of snapshot and partial updates. Syntax family and application meaning remain different layers.

Nor does an IANA allocation install a parser. The registry cannot show whether a product release added the new token, whether a configuration enabled it, whether a proxy rewrote it or whether an archive normalized it to an internal value. Registration closes the namespace gap. It does not close the rollout.

The correction becomes operational inside the MIME envelope

RFC 7866 makes the wire surface concrete. An SRC can send a full snapshot or partial update in an INVITE or UPDATE. When one SIP message contains both an SDP offer and metadata, its body must be multipart/mixed: one subordinate part carries SDP and another carries recording metadata. The metadata part uses Content-Disposition: recording-session. The boundary, part headers, XML body and SDP labels together determine what the SRS receives.

RFC 9806 changes the relevant media-type occurrences, including the values shown in the examples. But a real interoperability receipt needs more than the corrected string in a conformance document. It should preserve the method, dialog and transaction identifiers; the outer multipart/mixed header and boundary; the metadata part's exact Content-Type and Content-Disposition; a bounded hash of the metadata body; the XML namespace; whether the content was a full snapshot or partial update; and the peer's parse result.

The outcome matters because RFC 7866 gives the SRS stateful duties. It must follow the sequence of partial updates. After internal state loss, it may request a fresh full snapshot. If it detects a metadata syntax or semantic error, it may terminate the Recording Session rather than repeat the same failure. A 2xx response elsewhere in the SIP dialog cannot be promoted into proof that this metadata chain was accepted.

Similarly, a recording file is not conclusive evidence. RFC 7866 puts storage and playback outside the protocol's scope. Media may have been recorded while metadata was delayed, suppressed, rejected, normalized or stored under a legacy label. To prove correction custody, the archive needs its own evidence: which label it retained, how it indexed the body and which playback or export path later interpreted it.

Compatibility can conceal the last uncorrected node

A dual-accept parser may be a sensible migration tool. Accepting both application/rs-metadata and application/rs-metadata+xml can keep an older peer working while generators move to the corrected name. RFC 9806 does not prescribe that policy, however, and compatibility creates a second problem: success becomes less informative.

If every server accepts both labels indefinitely, an outdated client can remain invisible. If a gateway rewrites the old name to the new one, downstream telemetry can make the fleet look corrected while the source remains unchanged. If the server normalizes both values before logging, an operator loses the only signal that residual legacy traffic exists. Compatibility without origin-preserving telemetry turns a transition into a permanent blind spot.

The decision is not simply “strict” versus “lenient”. The operator needs to define direction and time. A new generator can emit only the corrected label while a parser temporarily accepts both. A legacy alias can be limited to named peers or cohorts. Rewrites can record the received and forwarded values separately. Retirement can depend on observed traffic rather than a calendar guess. Each exception needs an owner and an exit criterion.

A correction-custody receipt

The proposed receipt is Daniel Kade's editorial control, not an RFC 9806 field and not an IETF, RFC Editor or IANA requirement.

Begin with the documentary chain: fixed references to the two original section claims; Erratum 7987's ID, report date, status and correction; RFC 9806's publication category, update relation and replacement rule; and a dated IANA registry entry and template hash.

Then bind the implementation: SRC and SRS product, version, build, parser and generator module, configuration generation and the exact labels accepted and emitted in each direction. Record whether a legacy alias is rejected, accepted, normalized or rewritten, and identify the rule that makes that behavior visible.

For the transaction, retain the SIP method and bounded identifiers, Accept and Content-Type values, multipart boundary, Content-Disposition, metadata-body hash, namespace, snapshot/update state, SDP-label binding and peer outcome. Store a rejection class, snapshot request or session termination rather than collapsing all results into “recording succeeded”.

Join the archive path: stored label, index key, normalization rule, export representation and replay result. Add the rollout cohort, old/new/unknown traffic counts, canary result, compatibility window, negative tests, rollback trigger and owner. Finally, preserve the decision that retires the alias, along with residual legacy traffic and accepted exceptions.

The receipt does not make the correction more normative. It makes adoption reviewable. Publication proves the rule exists. The receipt shows where the rule ran.

Evidence boundary

The source record establishes the contradiction, erratum, update and registry state. It contains no census of SIPREC products or deployments, no vendor support matrix, no measured share of old or new labels and no reported incident attributed to the mismatch. No named implementation is accused here of being stale or non-compliant.

The risk paths in this article are testable scenarios, not observed failures. They follow from the protocol's visible dispatch and state surfaces: exact media-type tokens, multipart framing, XML parsing, update sequence and archival handling. A deployment should verify them locally rather than treating the existence of RFC 9806 as a substitute for evidence.

Sources