Resumo

  • FORWARD=0 pausa a entrega de Objetos em uma assinatura estabelecida no Media over QUIC Transport 22, sem interromper mensagens de controle como PUBLISH_DONE.
  • Se todos os assinantes downstream estiverem pausados, o retransmissor pode manter a assinatura upstream ativa para aquecer o cache. O recibo de pausa não prova que aquisição e uso de recursos cessaram.

O espectador toca em pausa. A imagem congela e o tráfego até o aparelho cai. No meio do caminho, porém, um retransmissor pode continuar recebendo a transmissão ao vivo para reduzir o atraso quando o usuário voltar. A revisão 22 permite as duas realidades.

draft-ietf-moq-transport-22, de 1º de outubro de 2026, define o MOQT como protocolo de publicação e assinatura sobre QUIC e WebTransport. O Datatracker o registra como Internet-Draft ativo do grupo Media Over QUIC. Não é RFC nem prova de implantação. O cabeçalho diz Standards Track, enquanto a ficha não mostra hoje um status RFC pretendido; essa diferença não autoriza tratá-lo como aprovado.

A revisão torna explícita uma fronteira anterior. A versão 21 chamava o estado de Forward State, com 0 ou 1. A versão 22 fala em assinatura pausada ou não pausada e anota essa mudança de linguagem. O mecanismo básico já existia; a semântica operacional ficou mais clara.

O editor não envia Objetos em uma assinatura pausada, mas continua enviando controle, inclusive PUBLISH_DONE. O iniciador define FORWARD em PUBLISH ou SUBSCRIBE. Depois, o assinante usa REQUEST_UPDATE com 0 para pausar e 1 para retomar. Outro valor encerra a sessão por violação de protocolo.

Pausa não é cancelamento. O estado permanece até cancelamento, PUBLISH_DONE ou REQUEST_ERROR. Também não guarda uma solicitação de preenchimento para depois: FILL_PARAMETERS processado durante a pausa não abre um fluxo fill-fetch, e retomar sem reenviar o parâmetro não o abre. Recuperar o intervalo exige intenção nova.

O fechamento do fluxo oferece outra evidência. Se o emissor fechar um fluxo de subgrupo antes de todos os Objetos pertinentes, precisa reiniciá-lo; omissão por pausa é um caso expresso. Um FIN limpo pode indicar subgrupo completo desde o começo da assinatura. Um reset avisa que podem existir Objetos posteriores. São resultados válidos, não recibos iguais.

No retransmissor surge a decisão econômica. Enquanto houver um assinante downstream sem pausa, deve existir uma assinatura upstream ativa. Quando todos pausam, o retransmissor escolhe. Deixar o upstream ativo recebe Objetos e aquece o cache, reduzindo a latência futura, mas gasta recursos do editor e da rede com conteúdo que ninguém recebe naquele instante. Pausar o upstream economiza trabalho e pode atrasar a retomada.

Logo, o selo “pausado” prova menos do que muitas promessas de custo ou privacidade sugerem. Ele descreve a entrega de uma assinatura. Não prova que o retransmissor parou de buscar, que o cache parou de mudar, que o editor ficou ocioso ou que o consumo faturável zerou. Também não prova que tudo continuou; a perna upstream precisa ser medida.

Uma operação responsável conserva sete registros: intenção ordenada do assinante; estado confirmado pelo editor; cessação de Objetos downstream; controle que continua; decisão upstream do retransmissor; tráfego, recursos e cache medidos; resultado visível na retomada. REQUEST_UPDATE_OK sozinho não encerra a história.

A Especificação Inicial Mínima de Heng Lu sustenta a divisão: o contrato comum define com precisão FORWARD, mas deixa a política de latência e recursos sob decisão local. A Primazia do Código em Execução exige observar bytes nos dois lados. As Camadas da Realidade separam tela congelada, estado de protocolo, cache e trabalho do editor. Essa é a análise editorial de Daniel Kade, não uma posição da IETF.

A autoridade do comando termina na fronteira nomeada. O usuário suspende sua entrega; não passa a controlar automaticamente a estratégia upstream. Se o produto promete não buscar, não armazenar e não cobrar após a pausa, precisa de outro controle verificável e de outro recibo.

Fontes