Resumo

  • A RFC 3485 permitiu que a primeira mensagem SigComp referenciasse material SIP/SDP porque todos os endpoints carregavam o mesmo estado estático, exato e imutável.
  • As listas legíveis dos apêndices explicavam as entradas, mas a interoperabilidade dependia do valor binário normativo, identificador, tamanho e fatias exatas.

Na primeira mensagem não existe histórico para comprimir. Nenhum cabeçalho anterior chegou ao receptor, e nenhum estado derivado da conversa pode ser compartilhado. A RFC 3485 criou esse passado antes do diálogo, instalando o mesmo dicionário nas duas pontas.

A solução exigia permanência. Toda implementação SigComp para SIP/SDP deveria ter um único dicionário, definido uma vez e não atualizado conforme os protocolos evoluíssem. Assim, o compressor não precisava descobrir qual edição estava no receptor antes de usar a primeira referência.

O acordo era um estado SigComp preciso. A seção 3 fixava identificador completo, tamanho 0x12E4, acesso mínimo de seis octetos e todos os bytes. O exemplo STATE-ACCESS usava seis bytes do identificador segundo as regras de busca, mas selecionava o mesmo objeto integral.

Os apêndices A e B listavam strings, prioridades, offsets, tamanhos e referências de SIP e SDP. Eram informativos. A forma binária da seção 3 era normativa. Duas implementações com as mesmas palavras, mas um byte em posição diferente, não compartilhavam o estado prometido.

O valor concatenava uma região de strings e uma tabela. A primeira continha os materiais como substrings; a segunda guardava comprimentos de um byte e offsets de dois bytes acrescidos de 1024, permitindo acesso direto quando carregada no endereço UDVM 1024. Métodos ligados à família LZ78 podiam usar a tabela como tokens iniciais.

Substrings comuns ocupavam espaço compartilhado. Um prefixo podia servir a vários cabeçalhos, e códigos de resposta possuíam entradas sem e com a frase sugerida. O código era normativo; a frase não. Entradas lógicas distintas podiam apontar para bytes sobrepostos.

A formatação fazia parte da correspondência. O dicionário distinguia maiúsculas e minúsculas e muitas entradas incluíam CRLF anterior, dois pontos e espaço. Uma mensagem SIP válida com outro espaçamento podia ganhar menos. Igualdade semântica não era igualdade de bytes.

Prioridades de um a cinco registravam expectativas de frequência, não medições. Números baixos indicavam material considerado comum e o colocavam em posições eficientes para certos algoritmos. Não demonstravam a frequência observada em redes posteriores.

Os níveis permitiam carregar fatias menores. A RFC fornecia offsets e tamanhos exatos para prioridade um, um a dois, um a três e um a quatro. Uma fatia não era nova versão negociada, mas intervalo do estado imutável completo.

Por isso um log “dicionário usado” é insuficiente. É preciso guardar identificador parcial, offset, tamanho, região e prioridade. Mesmo esses dados provam acesso, não descompressão bem-sucedida. A saída ainda precisa ser validada como SIP/SDP e autorizada pela aplicação.

A RFC 3320 já cobre execução UDVM e autorização de estado persistente; a RFC 3321, confirmação e vida de estado dinâmico; a RFC 3322, modelo de desempenho. A RFC 3485 ocupa somente a memória estática anterior ao primeiro intercâmbio.

Documentos posteriores mantiveram o limite. A RFC 3486 sinalizou SigComp em SIP; as RFCs 4464 e 4465 explicaram e testaram acesso; a RFC 4896 esclareceu o layout; a RFC 5049 exigiu suporte. A RFC 5112 criou outro dicionário para presença, sem revisar silenciosamente este.

A seção de segurança remetia à RFC 3320 e não identificava risco novo conhecido. Isso não tornava compressão autenticação. Um identificador correto não prova remetente, autorização, integridade, entrega ou sessão concluída.

O documento também não forneceu taxa observada nem implantação nomeada. A motivação indicava eficiência inicial, sobretudo em links estreitos, mas algoritmo, conteúdo, formato, fatia e rede determinam o resultado medido.

Pelas camadas de realidade de Heng Lu, primeiro se confirma hash, identidade e tamanho do estado. Depois se preservam todos os operandos STATE-ACCESS e se resolve o intervalo. Em seguida se compara a execução do descompressor. Validade, autenticação, transporte e sessão entram só depois.

A contribuição histórica foi dar memória à primeira mensagem. Essa memória só permaneceu comum porque não era um glossário editável, mas uma matriz de bytes selada para sempre.

Fontes