Summary

  • O co_repair da RFC 5225 usa CRC-7 para toda a cadeia de cabeçalhos não comprimidos reconstruída e um CRC-3 separado para os campos de controle aplicáveis. Esses campos nem sempre participam da descompressão do pacote que os transporta.
  • Aceitar a saída atual, avançar o estado persistente e enviar feedback positivo são decisões diferentes. Cada uma deve depender de evidência que cubra o objeto efetivamente autorizado.

Um resultado correto pode carregar uma premissa errada

O descompressor reconstrói o cabeçalho, verifica o CRC-7 e obtém um pacote utilizável. Ao mesmo tempo, o pacote pode trazer campos que atualizam o contexto compartilhado. O resultado visível pertence ao presente; a atualização de contexto governará eventos que ainda não ocorreram.

Por isso o formato co_repair inclui control_crc3_encoding. O CRC-7 cobre a cadeia inteira de cabeçalhos reconstruídos. O CRC de controle de três bits cobre a concatenação dos campos de controle aplicáveis. Não são duas avaliações da mesma coisa.

A RFC explica que os campos atualizados nem sempre são usados para descomprimir o cabeçalho que os carrega. Logo, podem ficar fora da proteção do CRC-7. Sem a verificação separada, a descompressão pode funcionar, o feedback positivo pode ser enviado e os campos de controle ainda assim podem ter sido atualizados incorretamente.

Contexto é infraestrutura de continuidade

ROHC reduz repetição ao apoiar-se em estado compartilhado entre compressor e descompressor. Cada omissão no pacote é compensada por uma dependência do contexto. Esse estado não é resíduo técnico; é infraestrutura para a próxima interpretação.

No estado Repair Context, a RFC 5225 admite que pacotes tenham sido descomprimidos com sucesso sem que todo o contexto seja confiável. Uma validação apropriada com CRC-7 ou CRC-8 pode restaurar Full Context. Um pacote atrasado na sequência pode ser descomprimido sem atualizar o estado e pode não receber ACK. A detecção de dano de contexto depende da implementação.

Assim, dois eventos chamados de sucesso podem produzir efeitos diferentes. A operação precisa registrar não apenas o que funcionou, mas o que mudou e qual confiança essa mudança merece.

Toda marca verde precisa de um complemento

“CRC passou” não é uma proposição completa. É necessário saber quais dados entraram no cálculo. Em co_repair, o CRC-7 fala do cabeçalho reconstruído; o CRC-3 fala dos campos de controle. Nenhum é assinatura criptográfica nem prova origem, entrega à aplicação, experiência do usuário ou correção de um produto específico.

Um recibo útil identifica o objeto verificado, o estado anterior, os campos propostos, o alcance do cálculo, o resultado e a ação liberada. Sem isso, a organização transforma uma evidência estreita em permissão ampla.

A falha tardia nasce numa transação verde

Saída inválida costuma falhar perto da causa. Saída válida com transição inválida pode falhar vários pacotes depois. Até lá, o feedback positivo já pode ter confirmado aos dois lados uma premissa comum incorreta.

A investigação procura o pacote que exibiu o sintoma, não a operação anterior encerrada como sucesso. Os detalhes podem ter sido descartados, tentativas podem aprofundar a divergência e um rollback de código pode manter o estado derivado pela versão antiga.

Governar esse risco exige preservar causalidade: qual evidência autorizou a saída, qual autorizou a mutação e quem decidiu continuar quando os escopos eram diferentes.

Separar uso, mutação e confirmação

Uma operação com resultado visível e estado oculto precisa permitir três respostas independentes. O resultado atual pode ser usado? O estado durável deve avançar? O outro lado deve receber confirmação positiva?

É possível aceitar um resultado e rejeitar a aprendizagem, o cache, a política ou o estado de controle que o acompanha. Também é possível ter uma atualização internamente coerente sem comprovar resultado ao usuário. Amarrar tudo a um único bit de sucesso simplifica a automação, mas elimina a governança da diferença.

Limites desta análise

A RFC 5225 não relata falha de aparelho, modem, operadora, fornecedor ou implementação nomeada. Não oferece participação de mercado atual, incidente, captura de pacotes nem medida de qualidade. O registro da IANA demonstra identificadores, não adoção.

A existência do controle independente tampouco prova erro em cada pacote de reparo. Ela demonstra que o primeiro controle não cobre o mesmo assunto. Uma salvaguarda de projeto não é um relatório de ocorrência.

Manter um recibo em duas partes

O recibo de saída registra entrada, reconstrução, alcance exato da validação, resultado e fronteira de entrega. O recibo de transição registra identificador do estado anterior, campos propostos, controle independente, mutação aceita ou rejeitada, feedback enviado, identificador do novo estado e responsável pela continuidade.

Registre também saída bem-sucedida com atualização recusada, atualização válida sem entrega comprovada, entrada tardia sem avanço, ACK retido, reparo solicitado e contexto restabelecido. Esses casos definem onde a afirmação de sucesso termina.

A abordagem de Lu Heng privilegia realidade operacional e responsabilidade atribuível. O nome de um protocolo ou de uma instituição não responde pela decisão de permitir que a evidência de hoje determine o estado de amanhã.

Sources

Registro adicional de padrões

  1. RFC 5225 em texto simples
  2. Registro informativo da RFC 5225
  3. Registro Datatracker da RFC 5225
  4. Histórico da RFC 5225
  5. Erratas da RFC 5225
  6. Visão de erratas em linha da RFC 5225