Resumo

  • Em 10 de setembro, a IESG aprovou a especificação de Pedido e Notificação de Resolução Temporal-Espacial como Proposed Standard. No corte, ela ainda era o Internet-Draft 17, sem número RFC final e com trabalho da IANA em andamento.
  • O receptor pede taxa de quadros, largura e altura; o emissor informa os valores que pretende usar. A resposta pode divergir por limitações técnicas, conteúdo gravado, múltiplos participantes, política local ou congestionamento.
  • TSRR e TSRN comprovam uma troca de controle. Não medem o vídeo entregue, a energia do receptor, a autonomia ou a qualidade. Uma alegação de economia exige uma cadeia de evidência que chegue ao efeito observado.

Um formato para negociar, não um selo verde

O anúncio da IESG de 10 de setembro aprovou RTP Control Protocol Messages for Temporal-Spatial Resolution como Proposed Standard. O registro atual no Datatracker mostrava a aprovação anunciada, mas ainda identificava a revisão 17 como Internet-Draft e a etapa da IANA como em curso. A decisão existe; um número RFC definitivo e registros concluídos ainda não existiam no corte.

O relato de aprovação preserva como o consenso foi estabelecido. A primeira última chamada do grupo de trabalho, em 2024, não recebeu respostas suficientes para uma declaração. Novas revisões antecederam uma segunda rodada, após a qual se concluiu haver bom consenso. Esse histórico não reduz a autoridade do resultado. Ele mostra de onde ela veio.

A necessidade operacional é direta. O decodificador conhece a própria bateria e capacidade de processamento; o codificador remoto controla a quantidade de quadros e pixels. A extensão cria mensagens específicas dentro do retorno definido por RFC 4585 e do controle de codec de RFC 5104. O ganho comum é poder expressar o pedido e receber uma resposta interoperável.

Pedir não é ordenar

Na revisão 17, TSRR identifica a fonte de mídia alvo e leva número de sequência, quadros por segundo, largura e altura. O receptor pode solicitar uma configuração que caiba no envelope negociado por SDP. Valores zero ou superiores ao que foi negociado são ignorados.

O emissor mantém a decisão. Se conseguir ajustar a codificação, pode considerar a sugestão para os próximos quadros. Depois, deve enviar TSRN com a configuração que usará como resultado. A notificação pode conter números diferentes dos pedidos.

Isso pode acontecer sem falha. Um vídeo pré-gravado talvez não mude. O codificador pode não oferecer aquela combinação. Um mixer precisa combinar necessidades de vários participantes. A política do serviço pode estabelecer um piso de qualidade. E o controle de congestionamento continua limitando o que atravessa a rede.

Nem sequer a capacidade é unilateral. O exemplo SDP mostra que tsrr só permanece disponível quando oferta e resposta o aceitam. A seção operacional diz que implementar a mudança em apenas uma ponta não altera o serviço RTP. É preciso separar cinco estados: código presente, capacidade negociada, pedido enviado, resposta recebida e mídia efetivamente modificada.

TSRN é um recibo de intenção

TSRN liga a resposta ao número de sequência de TSRR e permite que cada solicitante saiba que foi ouvido. Também informa taxa, largura e altura que o emissor declara usar dali em diante. Em retransmissões e em topologias com mixer ou tradutor, há regras para evitar respostas ambíguas.

Esse recibo encerra a incerteza sobre o controle recebido. Não encerra a incerteza sobre o fluxo entregue. Um elemento intermediário, a congestão ou uma mudança posterior podem produzir outra realidade. O protocolo também não observa watts, joules, tempo de bateria, carga do processador ou emissões.

O contexto vem de ISO/IEC 23001-11:2023, Energy Efficient Media Consumption. O trabalho da IETF transporta feedback temporal e espacial relacionado a esse contexto. Ele não define uma metodologia completa de energia e experiência.

Assim, a cadeia correta não usa igualdade:

TSRR → TSRN → mídia observada → energia medida → efeito de qualidade.

Só os dois primeiros passos pertencem ao novo formato. Os demais dependem de operação verificável.

A experiência precisa entrar na conta

O próprio rascunho alerta que aceitar sugestões inadequadas pode reduzir a qualidade de experiência e gerar reclamações. Operadores podem calibrar intervalos aceitáveis e considerar o risco em procedimentos de SLA. Menos resolução pode preservar uma reunião, mas também tornar texto ilegível, prejudicar acessibilidade ou levar a uma nova chamada.

Numa conferência, a pessoa com bateria fraca pode não ser quem precisa da imagem mais detalhada. Se um mixer consolida várias solicitações, a notificação final não explica sozinha qual necessidade prevaleceu. O registro operacional precisa indicar quem decidiu, qual política estava vigente e quais exceções foram usadas.

A IETF não precisa escolher essa política globalmente. O valor da coordenação mínima está em padronizar a fala sem centralizar a decisão. A responsabilidade fica com quem administra o serviço: tornar a escolha local visível e corrigível.

Segurança comprova origem, não benefício

Um pedido forjado pode reduzir brutalmente taxa e dimensões, tentar superar os limites negociados ou criar uma sequência excessiva de solicitações. O texto pede autenticação e integridade, referencia o perfil seguro de RFC 5124 e recomenda cautela diante de comportamento anormal.

Essas proteções mostram quem enviou dentro do contexto seguro e se a mensagem foi alterada. Não mostram que a estimativa do receptor era correta, que ele tinha autorização política para afetar outros ou que o resultado economizou energia. Uma sugestão ruim continua ruim depois de autenticada.

Há ainda uma superfície de direitos para a decisão de adotar. A divulgação IPR 5764 da Qualcomm relaciona-se ao rascunho predecessor e declara termos razoáveis e não discriminatórios com possível royalty ou taxa. A divulgação IPR 6159 da InterDigital relaciona-se às primeiras revisões do texto do grupo e oferece negociação razoável, recíproca e não discriminatória sob as condições descritas. São avisos públicos, não julgamentos da IETF sobre validade, essencialidade, infração, preço ou necessidade de licença.

Registrar a mudança até o efeito

Uma empresa que anuncie economia deveria manter uma cadeia de evidência da mudança de resolução. O primeiro bloco registra versões das pontas, negociação de tsrr, contexto de segurança, papéis de solicitante e alvo, sequência, horário e valores pedidos.

O segundo identifica o decisor — emissor ou mixer —, a revisão da política, a faixa aceitável e a regra para combinar pedidos. TSRN aparece como configuração anunciada. Em seguida, uma observação separada mede taxa de quadros, dimensões e bitrate recebidos numa janela definida.

Se houver afirmação energética, entram dispositivo, caminho de decodificação, aceleração, tela, carga paralela, linha de base, unidade, duração e incerteza. Qualidade vem junto: congelamentos, legibilidade, acessibilidade, reclamações, substituição manual, reversão e correção. A versão pública remove participantes, segredos e limiares exploráveis; a evidência protegida continua disponível para operação e contestação.

Essa cadeia é minha proposta editorial, não uma exigência da IETF, ISO, IANA ou dos declarantes. Ela aplica The Policy Mirror, de Heng Lu: identificar o ator capaz de decidir e a evidência de cada estado. Minimum Initial Specification explica como um sinal mínimo comum pode coexistir com adoção local voluntária. Why BTW Media Exists exige não confundir intenção institucional com realidade operacional.

O RTCP agora pode levar a necessidade do receptor e a resposta do emissor. A prova de economia começa depois da resposta.

Sources

  1. Anúncio da ação da IETF
  2. Registro no IETF Datatracker
  3. Internet-Draft, revisão 17
  4. Relato de aprovação
  5. RFC 4585
  6. RFC 5104
  7. RFC 5124
  8. Divulgação IPR 5764
  9. Divulgação 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