Summary

  • On 10 September the IESG approved the Temporal-Spatial Resolution Request and Notification specification as a Proposed Standard. At the reporting cutoff it remained an Internet-Draft without a final RFC number, with IANA work still in progress.
  • A receiver can request a frame rate, width and height, while the sender can choose different values and report them in a notification. Both endpoints must support the mechanism, and mixers, congestion control and local policy can alter the result.
  • TSRR and TSRN describe a control exchange; they do not measure delivered resolution, receiver energy, battery life, emissions or preserved quality. An energy claim needs a separate request-to-effect evidence chain.

The approval standardises a conversation

The IESG’s 10 September protocol action approved RTP Control Protocol Messages for Temporal-Spatial Resolution as a Proposed Standard. The current Datatracker record identifies revision 17, records that the approval announcement was sent and still shows an active Internet-Draft with IANA work in progress. That sequence matters: the decision has been taken, but a final RFC number and completed registry action should not be invented ahead of the public record.

The approval write-up also preserves a useful piece of process history. A first Working Group Last Call in 2024 did not draw enough responses to declare consensus. Additional reviews preceded a second Last Call and the later conclusion that the document had good consensus. This does not discredit the result. It shows that “the IETF decided” is the end of a traceable process, not a mood attributed retrospectively to an institution.

What the IETF approved is a conversation between video endpoints. The revision 17 text defines a Temporal-Spatial Resolution Request, or TSRR, and a corresponding Notification, TSRN. The format sits in the feedback architecture of RFC 4585 and extends the codec-control model described by RFC 5104. Its energy context comes from the public catalogue entry for ISO/IEC 23001-11:2023, Energy Efficient Media Consumption.

That institutional chain gives the message a defined syntax and status. It does not give a future marketing sentence a measured denominator.

A receiver asks; it does not command

A TSRR carries a requested frame rate, picture width and picture height for a target media sender. The receiver may be trying to extend battery life, reduce decoder load or keep a scheduled call alive under constrained resources. The request must stay at or below the temporal and spatial limits negotiated through the session description.

The verbs in the specification are careful. A decoder can suggest a resolution. A capable encoder may take the request into account for future pictures. The sender then has to return a TSRN containing the values it will use as a result of the request. Those values need not be the requested values.

There are several legitimate reasons for a difference. The encoder may not support the requested change. Content may be pre-recorded. The request may exceed the negotiated envelope. Multiple participants may ask for incompatible outcomes. A sender, mixer or translator may have policy limits, while congestion control can impose a lower delivered rate than an attempted increase. A zero-valued or above-negotiated request is ignored rather than treated as authority.

The SDP example makes capability equally conditional. An offer can include tsrr; if the answer omits it, the mechanism is not negotiated for that session. The operational section says the change must be implemented at both endpoints: implementation at only one end changes nothing in the RTP service. Feature presence in a product sheet is therefore weaker evidence than successful offer/answer, and successful offer/answer is weaker than a completed control exchange.

A notification is still not an observation

TSRN closes one uncertainty. It tells each requesting entity that the sender received the request and identifies the frame rate and dimensions the sender says it will use. Sequence numbers bind a notification to the corresponding request, including retransmissions. That is valuable protocol evidence.

It does not close every uncertainty. “Will use” is not a sample of the media that arrived. A mixer may transform the stream. Congestion control may intervene. A configuration can change again after the notification. A decoder may consume less power, the same power or more power depending on codec, hardware acceleration, display behaviour, workload and device state. A lower pixel rate can also move cost elsewhere or lower quality enough to trigger a retry, a longer call or a user override.

The draft itself warns that honoring inadequate suggestions can harm quality of experience and produce complaints. It tells operators to calibrate acceptable hints and consider service-level assurance. That warning prevents a convenient but false equation:

TSRR received ≠ TSRN sent ≠ lower-resolution media observed ≠ receiver energy fell ≠ environmental benefit proved.

A standards-compliant exchange can be the first two links. The remaining links need evidence generated by the service and receiver environment.

Multiparty media moves the decision point

Point-to-point calls provide the cleanest case, but the specification also covers mixers and translators. A mixer that encodes the content reaching the requester has to consider whether it can fulfil the request itself. A translator that cannot may forward the request toward the original media sender. A mixer serving several participants has to consider their joint needs before issuing its own request.

That creates a governance question, not merely a packet-format question. Which actor selected the final resolution? Was one receiver’s battery constraint balanced against another receiver’s accessibility or presentation need? Did an acceptable-range policy belong to the sender, the mixer, the service operator or an enterprise administrator? A single TSRN value cannot describe that decision chain by itself.

The format is intentionally not an authorization protocol. It has no field saying that a requester may reduce another participant’s quality, no universal priority rule for competing receivers and no carbon-accounting method. Those choices remain local. Local choice is not a defect; invisible local choice is the risk.

Security protects the message, not the claim

The security section identifies concrete abuse. Forged feedback could force very low frame rate or picture dimensions, attempt values above the negotiated session or create an excessive stream of requests. The specification calls for authentication and integrity protection and points to the secure feedback profile in RFC 5124. It also tells implementations to behave conservatively when reporting is unusual.

Cryptographic protection answers who produced a message inside a protected context and whether it was changed in transit. It does not establish that the requester’s policy was legitimate, that the receiver measured a resource constraint accurately, that the sender’s response preserved a promised level of service or that energy fell after the change. An authenticated bad hint remains a bad hint. A correctly authenticated notification remains a statement about selected parameters, not a wattmeter reading.

Operational reporting should therefore keep security state and outcome state separate. A useful incident record can show that a protected participant issued a request, that the sender accepted a particular value and that the delivered media later diverged. Compressing those facts into “secure green metadata worked” would hide the failure point.

Implementation has a rights surface too

The Datatracker links two public intellectual-property notices associated with this work and its predecessor. Qualcomm’s disclosure 5764 names a predecessor draft and states a reasonable and non-discriminatory licensing position with a possible royalty or fee. InterDigital’s disclosure 6159 relates to early revisions of the Working Group draft and states willingness to negotiate on reasonable, reciprocal and non-discriminatory terms if relevant claims would necessarily be infringed.

Those notices are inputs to adoption due diligence. They are not findings by the IETF that a claim is valid, essential or infringed, and they do not establish a price. An implementer needs to read the actual declarations and make its own assessment. The economic boundary mirrors the evidence boundary: publication of a notice is not the same event as a licence being required, negotiated or paid.

Build a resolution-change evidence chain

If a service wants to say that this mechanism saved energy, the public claim should be backed by a privacy-bounded resolution-change evidence chain. The chain begins with the session and implementation versions, negotiated tsrr capability and security context. It records requester and target roles, request sequence and time, requested values, and the sender or mixer policy revision that governed acceptable ranges and aggregation.

Next come the TSRN values and time. They should be labelled as the sender’s selected future configuration, not silently relabelled as observed delivery. A separate observation should record delivered frame rate, dimensions and bitrate over a defined window. If the operator makes an energy statement, it should add the receiver-side measurement method, baseline, window, device conditions and uncertainty. Quality and service evidence belongs beside it: freezes, latency, accessibility effects, complaints, overrides, rollback and correction.

The public version should omit participant identifiers, session secrets and exploitable thresholds. Protected evidence may remain available for operations, dispute handling or security review. The goal is not to expose calls; it is to stop one protocol message from borrowing the authority of measurements that were never taken.

This evidence chain is my editorial proposal. It is not required by the IETF, ISO, IANA or either patent holder. It follows the authority discipline in Heng Lu’s Policy Mirror: show which actor can decide and which evidence supports the state. His Minimum Initial Specification supports a narrow common signal while leaving implementation and adoption local. Why BTW Media Exists supplies the final restraint: report what the mechanism can demonstrate, not what its label invites an institution or vendor to imply.

The new RTCP messages can make a receiver’s need legible to a sender and make the sender’s response legible to the receiver. That is a real interoperability gain. Their legitimacy will be stronger, not weaker, when energy, quality and authority claims remain outside the message until evidence earns them.

Sources

  1. IETF protocol-action announcement
  2. IETF Datatracker document record
  3. Internet-Draft revision 17
  4. IETF approval write-up
  5. RFC 4585
  6. RFC 5104
  7. RFC 5124
  8. IETF IPR disclosure 5764
  9. IETF IPR disclosure 6159
  10. ISO/IEC 23001-11:2023 catalogue record
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists