Resumo

  • No SDXF, cada bloco tem identificador, sinalizadores, comprimento de três bytes e conteúdo. O exemplo da RFC 3072 ignora identificadores desconhecidos e avança ao bloco seguinte.
  • A regra mantém a leitura em andamento, não a compreensão: a aplicação ainda precisa de significado compartilhado, conversão, métodos implementados e autorização para agir sobre o valor.

Em março de 2001, Max Wildgrube apresentou a Structured Data Exchange Format (SDXF) na RFC 3072 como uma maneira independente de plataforma para trocar dados hierárquicos. A promessa pede uma leitura cuidadosa. O documento diz que um programa pode desempacotar dados SDXF sem conhecer o sentido de cada elemento; no exemplo de leitura, porém, o código trata IDs conhecidos em um switch, não define uma alternativa padrão e chama a operação para avançar ao próximo bloco. O campo desconhecido é ignorado, e a análise prossegue.

A estrutura binária explica essa continuidade mecânica. Um bloco comum contém um ID não zero de dois bytes, um byte de sinalizadores, o comprimento do conteúdo em três bytes e, em seguida, o conteúdo. Um bloco estruturado pode conter outros blocos recursivamente. Se o leitor consegue localizar o limite seguinte conforme as regras atuais, pode continuar sem interpretar o corpo que acabou de atravessar. Ele sabe onde o bloco termina; não sabe o que aquele ID significa para determinada aplicação.

A RFC 3072 propõe ignorar IDs desconhecidos e não depender da ordem dos blocos em protocolos baseados em SDXF. Isso pode ajudar leitores antigos a tolerar uma extensão. Não define se ela é dispensável para a transação do emissor, se muda a interpretação da aplicação ou se descartá-la altera uma ação importante. Continuar o percurso é uma regra de compatibilidade com escopo definido, não uma declaração universal de que o campo é irrelevante.

O formato também explicita os acordos que continuam necessários. A RFC 3072 normaliza valores binários em big-endian, propõe ISO 8859-1 como representação interna de caracteres, permite tabelas de conversão e define um tipo UTF-8. Compressão e criptografia dependem de sinalizadores, números de método e funções. Quando ambas são usadas, a compressão vem primeiro; criptografar exige uma chave. Assim, um limite estrutural legível não garante que o receptor tenha a tabela de caracteres, o método, a implementação ou a chave exigidos pelo conteúdo.

Os registros IANA do SDXF hoje listam RUN-LENGTH e DEFLATE para compressão, além de AES como método de criptografia 01. O registro identifica as atribuições, mas não comprova que o receptor implementa o método ou que uma mensagem foi transformada corretamente. A RFC 3072 é Informational, não um padrão da Internet; as fontes não comprovam sua implantação ou adoção. Uma proposta de formato não é um relatório de interoperabilidade em produção.

O ponto prático é manter distintas as evidências. O comprimento localiza bytes segundo a regra do formato; o ID remete a um significado definido pela aplicação; a tabela converte caracteres; o número escolhe um método cuja execução depende do código e da chave; e outra política decide se o valor extraído pode produzir um efeito. Running-Code Primacy, como lente analítica posterior, recomenda observar o comportamento executável em vez de inferi-lo pelo documento. Reality Layers ajuda a separar significado simbólico de efeito verificável. Nenhuma dessas ideias é atribuída a Wildgrube.

Isso também explica por que “desconhecido pode ser ignorado” não funciona como regra isolada do protocolo. Só o contrato da aplicação pode dizer se o campo é opcional, se precisa ser preservado intacto ou se a sua ausência ainda permite concluir a mesma operação com segurança. O analisador genérico não recebe essa autoridade do campo de comprimento.

Fontes