Résumé

  • L’IESG a approuvé le 10 septembre la spécification TSRR/TSRN comme Proposed Standard. À la date de notre vérification, le texte restait un Internet-Draft sans numéro de RFC définitif et le travail IANA était toujours en cours.
  • Le récepteur propose une cadence et des dimensions ; l’émetteur répond avec les valeurs qu’il compte appliquer. La réponse peut différer à cause du codage, du contenu, des autres participants, des règles locales ou du contrôle de congestion.
  • Ni la demande ni sa notification ne mesurent la vidéo reçue, l’énergie du terminal ou la qualité vécue. Toute allégation d’économie doit donc conserver une chaîne de preuve distincte.

Trois événements que le mot « vert » ne doit pas confondre

Le message d’approbation de l’IESG porte sur RTP Control Protocol Messages for Temporal-Spatial Resolution. Il officialise une décision de normalisation, pas une réduction chiffrée de consommation. La fiche Datatracker indiquait encore, lors de la clôture de cette enquête, la révision 17, le statut d’Internet-Draft et une action IANA en cours. Il serait donc prématuré de lui attribuer un numéro de RFC ou des valeurs de registre définitives.

La décision elle-même possède une histoire utile. Le dossier d’approbation rappelle qu’un premier Last Call du groupe de travail, en 2024, n’avait pas reçu assez de réponses pour constater un consensus. Des examens supplémentaires ont précédé un second passage et la conclusion de bon consensus. Ce détail n’annule rien ; il empêche simplement de présenter l’institution comme une voix sans procédure.

Le troisième événement aura lieu chez l’opérateur : deux logiciels compatibles négocieront-ils vraiment la fonction et modifieront-ils le flux ? Ce futur état n’est pas contenu dans l’annonce. Entre une décision de l’IETF, une fonction implémentée et une économie mesurée, il existe trois preuves différentes.

La demande appartient au récepteur, le choix à l’émetteur

Le texte de la révision 17 définit TSRR, la demande de résolution temporelle et spatiale. Elle contient une cadence d’images, une largeur et une hauteur, associées à la source média visée. Un terminal peut s’en servir lorsqu’il estime sa batterie insuffisante pour terminer une session programmée, ou lorsque son décodeur manque de ressources.

Cette demande est une suggestion bornée. Elle ne doit pas dépasser ce qui a été négocié par SDP. Si l’encodeur sait s’adapter, il peut en tenir compte pour les images suivantes. Il doit ensuite émettre TSRN, une notification qui reprend les valeurs qu’il prévoit d’utiliser. Le modèle prolonge l’architecture de retour de RFC 4585 et les messages de contrôle de codec de RFC 5104.

La dissymétrie est saine : demander n’est pas imposer. L’émetteur peut ne pas savoir modifier un contenu préenregistré, agréger plusieurs souhaits incompatibles ou appliquer une plage acceptable définie par le service. Un mélangeur peut traiter lui-même la demande ou la transmettre. Le contrôle de congestion conserve aussi son autorité sur le débit réellement livré.

Le mécanisme doit en outre être négocié des deux côtés. Si tsrr figure dans l’offre mais pas dans la réponse SDP, il n’est pas retenu pour la session. La spécification dit explicitement qu’une implémentation sur un seul terminal ne change rien au service RTP. Une bibliothèque compatible, une option activée et un échange réussi sont donc trois états distincts.

TSRN atteste une réponse, pas un résultat énergétique

TSRN apporte une vraie valeur probante : son numéro de séquence permet de l’associer à la demande, et chaque demandeur apprend que son message a été reçu. La cadence et les dimensions indiquées peuvent être différentes de celles réclamées. L’émetteur doit exposer le choix qu’il fera, au lieu de laisser le récepteur deviner.

Mais la formulation porte sur l’avenir. Elle n’échantillonne pas les paquets vidéo arrivés, ne mesure pas la charge du décodeur et n’observe pas la batterie. Après la notification, un mélangeur, un nouvel arbitrage ou la congestion peuvent encore produire un flux différent. Deux appareils recevant la même résolution peuvent aussi consommer différemment selon le codec, l’accélération matérielle, l’écran et les tâches concurrentes.

Le contexte énergétique vient d’ISO/IEC 23001-11:2023, consacré à l’Energy Efficient Media Consumption. La contribution de l’IETF est plus étroite : transporter certains retours entre décodeur et encodeur. Elle ne définit ni compteur de joules, ni méthode carbone, ni protocole complet de qualité d’expérience.

La frontière peut se résumer ainsi :

demande TSRR ≠ réponse TSRN ≠ flux observé ≠ énergie mesurée ≠ bénéfice environnemental.

Une communication conforme ne remplit que les premières cases. Les autres exigent un dispositif de mesure déclaré.

La qualité fait partie du bilan

La section opérationnelle avertit qu’une suggestion inadéquate peut détériorer l’expérience et provoquer des réclamations. Elle invite les opérateurs à calibrer les plages acceptables et à intégrer ce risque dans l’assurance des niveaux de service. Une baisse de pixels n’est donc pas un bien gratuit : elle peut prolonger une batterie, mais aussi rendre un détail illisible, gêner un usage professionnel ou pousser l’utilisateur à relancer la session.

Dans une conférence, l’arbitrage devient collectif. Le participant contraint n’est pas nécessairement celui qui dépend d’une image fine. Le mélangeur doit concilier plusieurs besoins et la notification finale ne raconte pas, à elle seule, quel intérêt a prévalu. Il faut conserver l’acteur qui a appliqué la règle, la version de cette règle et les demandes écartées.

Le standard laisse ces choix locaux. C’est cohérent avec une coordination minimale : un format commun n’a pas à dicter chaque promesse commerciale. En revanche, l’opérateur ne devrait pas cacher cette discrétion sous l’étiquette générique de « green metadata ».

Authentifier ne suffit pas à légitimer

De faux messages pourraient imposer une cadence ou une image très faible, tenter une hausse au-delà de la négociation ou multiplier les requêtes. Le projet demande l’authentification et l’intégrité, en s’appuyant notamment sur le profil sécurisé de RFC 5124, et recommande une réaction prudente aux comportements inhabituels.

Cette protection établit l’origine et l’intégrité d’un message dans un contexte de session. Elle ne prouve pas que la demande est bien calibrée, que son auteur est autorisé par la politique du service à diminuer la qualité des autres, ni que l’effet énergétique annoncé s’est produit. Une mauvaise consigne authentifiée reste une mauvaise consigne.

La même prudence vaut pour le coût d’implémentation. Deux déclarations de propriété intellectuelle sont publiques : la déclaration Qualcomm 5764 vise le projet prédécesseur et mentionne une licence raisonnable et non discriminatoire avec redevance ou frais possibles ; la déclaration InterDigital 6159 porte sur les premières versions du projet du groupe et propose, sous conditions, une négociation raisonnable, réciproque et non discriminatoire. Ce sont des avis à examiner, pas des conclusions de l’IETF sur la validité, le caractère essentiel, la contrefaçon ou le prix.

Publier une chaîne de preuve du changement

Lorsqu’un service revendique une économie, il devrait produire une chaîne de preuve du changement de résolution. Son premier segment décrit la version des terminaux, la négociation tsrr et le contexte de sécurité. Viennent ensuite le rôle du demandeur, la source visée, le numéro et l’heure de la demande, puis les valeurs souhaitées.

Le deuxième segment identifie l’émetteur ou le mélangeur qui a tranché, la version de sa politique, la plage acceptable et la règle d’agrégation. La notification et son heure sont conservées comme une intention de configuration. Un troisième segment mesure séparément la cadence, les dimensions et le débit effectivement reçus pendant une fenêtre définie.

Si une économie d’énergie est publiée, un quatrième segment donne l’appareil, le chemin de décodage, l’état de l’écran, la référence, la durée, l’unité et l’incertitude de la mesure. Enfin, la qualité apparaît avec les plaintes, les dérogations, le retour au réglage précédent et les corrections. La version publique doit retirer identifiants de session, secrets et seuils exploitables ; les preuves protégées peuvent rester disponibles pour l’exploitation et les litiges.

Cette chaîne est ma proposition éditoriale, non une exigence de l’IETF, de l’ISO, de l’IANA ou des titulaires déclarants. Elle transpose The Policy Mirror de Heng Lu : indiquer qui peut décider et sur quelle preuve repose l’état. Sa Minimum Initial Specification justifie un signal commun étroit sans centraliser les choix de déploiement. Why BTW Media Exists impose enfin de préférer l’opération constatée à l’ambition suggérée par un nom.

TSRR donne au récepteur un moyen propre d’exprimer une contrainte. TSRN oblige l’émetteur à rendre son choix visible. L’économie d’énergie, elle, doit encore être démontrée.

Sources

  1. Annonce de l’action IETF
  2. Fiche Datatracker
  3. Internet-Draft, révision 17
  4. Dossier d’approbation
  5. RFC 4585
  6. RFC 5104
  7. RFC 5124
  8. Déclaration IPR 5764
  9. Déclaration IPR 6159
  10. ISO/IEC 23001-11:2023
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists