Summary

  • The IESG approved draft-ietf-avtcore-rtp-jpegxs-3ed-07 as a Proposed Standard on 14 September, but on 21 September it still had no RFC number and the RFC Editor queue was waiting for author input.
  • Revision 07 preserves conforming RFC 9134 implementations within their supported feature set; that does not make an older receiver capable of decoding third-edition Temporal Differential Coding.
  • An edition-compatibility receipt should join the standards state to the exact SDP exchange, both endpoint builds, a non-TDC fallback and bounded media tests before an operator calls the upgrade working.

A control room can show green at seven different layers and still fail to put a picture on the far monitor. The document may be approved. The RFC may later be published. IANA may update video/jxsv. A vendor may ship support. Two endpoints may accept an SDP description. A decoder may render one sample. An operator may finally enable the path in production. None of those lights substitutes for the next one.

That distinction became timely on 14 September 2026, when the IESG approved revision 07 of RTP Payload Format for ISO/IEC 21122 (JPEG XS) for publication as a Proposed Standard. The action is consequential, but its name is easy to overread. Proposed Standard is not Internet Standard, and an IESG Protocol Action is not an RFC publication event.

The live record on 21 September shows the handoff in progress. Datatracker lists the document in the RFC Editor queue. The queue says the intake form is pending and author input is required. No RFC number is assigned. IANA marks the changed version for further review. The public video/jxsv registration still cites RFC 9134. These are ordinary production states, not evidence that the approval failed. They are also why an operator should not write “the new RFC” yet.

Obsoletes does not mean disables

Revision 07 says the eventual document will obsolete RFC 9134. In the RFC series, that relationship tells readers which specification supersedes the older one. It does not send a control message to installed devices, revoke firmware or make an RFC 9134 packet stream stop working on publication day.

The draft is explicit about its intended continuity. Existing conforming RFC 9134 implementations remain valid under the updated specification. Non-TDC streams are not changed by the new TDC provisions, and the upgrade can be introduced incrementally. Legacy implementations remain operational within the feature set they already support.

The final words define the boundary. “Within their supported feature set” is not the same as “supports every feature in edition three.” The continuity claim protects the older compatibility set. It does not silently add a decoder, frame buffer or profile that the installed product never implemented.

TDC adds state, not just a label

The first two JPEG XS editions used intra coding. The third edition adds Temporal Differential Coding, which decorrelates successive pictures in the wavelet domain. A non-TDC codestream can be decoded as a stand-alone picture. A TDC stream may depend on reconstructed coefficients held from the preceding codestream: one frame buffer for progressive material, and separate buffers for the two fields in interlaced or progressive-segmented-frame material.

The revision therefore recognises an SLI marker for TDC-enabled slices and adds fbblevel, the frame-buffer-bandwidth level. It also permits TDC profile names such as TDC444.12. fbblevel is allowed only when TDC is used and, like the other declarative parameters, must agree with the value carried in the JPEG XS picture segment.

This is why packet acceptance and picture decoding are different tests. An older implementation can remain conforming for a non-TDC stream while being unable to reconstruct a TDC stream. A newer sender can implement the approved revision while still needing a safe path for an older receiver.

SDP is the session contract

The media subtype remains video/jxsv, with a 90 kHz RTP clock and a required packetmode. SDP carries jxsv/90000 in a=rtpmap and places packetmode plus optional fields such as profile, level, sublevel and fbblevel in a=fmtp.

Revision 07 gives offer/answer a hard edge. An answerer must support every parameter and value offered; otherwise it must reject the session. If it accepts, it returns the same parameter values. The offerer is responsible for selecting values the answerer is expected to support.

That rule prevents a clean standards story from becoming an ambiguous session. It does not make fallback automatic. If a TDC offer is rejected, the operational question is whether the sender or orchestration layer can make a fresh, explicitly non-TDC offer that both ends can use. A successful SDP answer then proves agreement on declared parameters. It still does not prove that the exact media sample decoded without buffer, timing or visual faults.

Record the compatibility claim at the point of use

An edition-compatibility receipt should be small enough to attach to a change ticket and specific enough to reproduce a decision.

Receipt field Evidence to retain
Standards state Draft revision 07, its SHA-256, IESG date, RFC number if assigned, RFC Editor state and IANA reference
Stream contract video/jxsv, payload type, clock rate, packetmode, profile, level, sublevel, fbblevel and TDC on/off
Endpoint identity Sender and receiver product, build, firmware, codec module and configuration
Negotiation Exact offer, answer or rejection, plus the result of an explicit non-TDC fallback
Media test Sample identity, signal form, frame rate, duration, packet conditions, decoded result and monitored alarms
Change control Failure, correction, retest, upgrade window, rollback path and exit condition

The receipt should also state its scope. One transmitter-receiver pair, one profile and one progressive sample do not prove interlaced support, every level, every gateway or a production plant. Conversely, a failed TDC session does not invalidate non-TDC operation under RFC 9134. The useful result is not a universal “compatible” badge. It is a bounded statement about which two builds exchanged which stream under which conditions.

Standards documents coordinate expectations. Registries describe assigned parameters. Implementations create capabilities. Sessions expose the intersection. Production evidence begins only when those layers are joined without erasing their different states.

Sources

  1. IETF Datatracker: RTP Payload Format for ISO/IEC 21122 (JPEG XS)
  2. Datatracker document history
  3. Revision 07 plain text
  4. RFC Editor queue
  5. RFC 9134
  6. IANA registration for video/jxsv