Resumo

  • No parâmetro LOCATION_FILTER, de código 0x21, a edição 21 usava Length para indicar pelo tamanho em bytes quantos inteiros opcionais vinham a seguir. A edição 22 substitui esse campo por Location Filter Type. Valores de 0x00 a 0x05 escolhem a forma do filtro; outros valores são PROTOCOL_VIOLATION.
  • A atualização, publicada em 1º de outubro, continua sendo um Internet-Draft do grupo MOQ. O apêndice identifica a alteração como mudança do plano de sessão e controle e distingue dela as reorganizações editoriais, inclusive a explicação sobre assinaturas pausadas.

Pense numa retransmissão de baixa latência que precisa começar no próximo objeto, e não no começo de um grupo já visto. A tela de operação pode mostrar conexão estabelecida, mas essa informação não diz como o relay leu o ponto de início solicitado. O novo texto reduz a margem para que a estrutura do pedido seja deduzida indiretamente. Sua relevância é a verificabilidade da seleção, não a promessa de ausência de perda.

Na versão 21, o primeiro inteiro identificava o parâmetro 0x21 e o segundo era o comprimento. Depois poderiam aparecer até quatro inteiros de tamanho variável. O número de bytes determinava quais campos estavam presentes. Comprimento zero significava nenhum filtro; dois campos de valor zero davam o sentido especial de “próximo objeto”. O desenho funcionava como uma gramática inferida a partir do tamanho e dos dados, e não como uma enumeração explícita da modalidade pedida.

O rascunho 22 conserva o identificador externo e altera essa gramática. 0x00 significa sem filtro; 0x01, início relativo; 0x02, início absoluto; 0x03, intervalo que termina no grupo indicado; 0x04, intervalo absoluto com objeto final; e 0x05, próximo objeto sem campos adicionais. Um tipo fora dessa lista constitui violação de protocolo. A comparação das seções 9.20.10 e 9.20.9 mostra a mudança no fio. Não se deve interpretar os seis valores como classes de usuários ou como uma nova política de acesso: são formas de codificar posições.

O mesmo parâmetro pode aparecer em FETCH, SUBSCRIBE, PUBLISH, numa atualização de assinatura e numa notificação do estado publicado. O ponto sensível para um operador é o relay que recebe uma intenção e faz outra solicitação a montante. Se as duas pontas de um serviço forem atualizadas em momentos diferentes, será necessário saber qual versão foi negociada em cada trecho e qual seletor foi efetivamente processado. Isso é uma conclusão para planejamento de testes, não um relato de falha observada.

O documento prevê negociação de versão por ALPN em QUIC e pelo mecanismo de WebTransport, com identificadores temporários associados a cada edição do rascunho. Uma implementação correta não deveria tratar bytes de versões diferentes como se fossem a mesma gramática. Logo, a simples diferença entre as duas edições não demonstra uma quebra em produção. Demonstra, sim, que a evidência de compatibilidade precisa incluir versão, decodificador e objetos escolhidos, em vez de apenas “a sessão abriu”.

O histórico de alterações delimita a notícia. A explicitação do tipo do filtro é o item listado em sessão e controle desde a versão 21. Textos sobre pausas e a organização de FETCH são chamados de mudanças editoriais. Eles ajudam a ler a especificação, mas não autorizam apresentar pausas como uma invenção desta revisão. O objeto da reportagem é a representação explícita do filtro, precisamente onde uma solicitação passa a ter significado para a outra ponta.

Fontes