Resumo

  • A RFC 9682 substitui a gramática coletada anterior, mas a sintaxe \u{hex} não ganha suporte automático em processadores antigos.
  • O aceite da compra deve separar compatibilidade do modelo, geração do validador, comportamento em produção e capacidade de reconstruir a versão de retorno.

A pergunta que antecede a demonstração comercial

Antes de contratar uma ferramenta CDDL, vale inverter a demonstração: em vez de perguntar apenas o que a versão nova permite fazer, perguntar o que continuará funcionando quando ela precisar ser retirada. O rollback exige que uma ferramenta antiga volte a ler o modelo? Ela aceita a escrita com chaves? Essa capacidade não pode ser presumida, como deixa explícita a RFC 9682, seção 2.

A consequência para a compra é direta: “suporta CDDL” não deveria encerrar a avaliação. A proposta precisa dizer quais versões serão utilizáveis, com quais modelos e sob quais condições de retorno. O objetivo não é impedir a modernização. É evitar que uma conveniência de escrita elimine, sem decisão explícita, a alternativa de voltar à configuração anterior.

O alcance exato do reparo

CDDL é uma linguagem para descrever estruturas de dados CBOR e JSON, conforme a RFC 8610. A ABNF, definida pela RFC 5234, formaliza regras sintáticas; sua seção 2.4 separa sintaxe de codificação externa. Uma descrição formal, portanto, não constitui demonstração de funcionamento de um programa.

O Apêndice A da RFC 9682 substitui a ABNF coletada do Apêndice B da RFC 8610. A revisão acrescenta \u{hex}, que representa um valor escalar Unicode em hexadecimal. Arquivos legados conformes continuam abrangidos pela nova gramática; isso não transforma toda entrada anteriormente tolerada por alguma ferramenta em entrada conforme. RFC 9682.

Os reparos atendem a problemas diferentes: a Errata 6527 trata dos escapes de texto; a 6278, da consistência dos literais; a 6526, de barras invertidas perdidas na publicação. A 6543 é atendida pela revisão dos literais, enquanto a 6575 esclarece a interpretação numérica na notação de tags e valores simples. RFC 9682, seções 2 e 3.

A distinção operacional proposta aqui é outra: separar a autoridade da gramática da capacidade entregue. O padrão fornece o critério para julgar uma implementação; não substitui essa implementação. Um resultado observado pode contrariar o padrão, mas não o reescreve. Para quem opera o serviço, contudo, esse resultado continua sendo um problema a resolver.

A matriz precisa incluir o caminho de volta

Recomenda-se que a matriz de versões cubra tanto a configuração pretendida quanto aquela reservada ao rollback. Em cada combinação, devem ser identificados o programa responsável pela análise sintática, sua versão exata, os recursos declarados e os efetivamente demonstrados. A versão exibida pela ferramenta principal não basta quando ela utiliza outro parser: é esse analisador que precisa ser identificado.

A comparação deve usar os bytes exatos do modelo, preservados junto com um resumo criptográfico. A RFC 8610, seção 3.1, estabelece UTF-8 para CDDL e não prevê normalização Unicode durante seu processamento. A recomendação decorrente é não substituir o arquivo de referência por uma cópia visualmente semelhante. Se houver transformação antes da análise, convém guardar também o texto efetivamente entregue ao parser.

Essas provas respondem a perguntas diferentes. O resumo criptográfico ajuda a conferir qual arquivo foi usado; não demonstra que o parser o compreendeu. O número da versão identifica uma implementação declarada; não demonstra que aquela implementação foi realmente executada. E uma aceitação sem erro registra um resultado particular, não uma cobertura completa da linguagem.

Para a homologação, propõe-se comparar modelos legados conformes com modelos que utilizem os recursos novos, além de casos de rejeição esperada. Os critérios devem distinguir recurso ausente, erro sintático e resultado semântico divergente. Trata-se de uma proposta de verificação, não de testes executados ou resultados atribuídos a produtos.

A matriz também precisa registrar o limite da promessa. Atualizar todos os analisadores e continuar usando apenas a escrita anterior é uma decisão diferente de autorizar imediatamente a nova sintaxe. A segunda decisão pode restringir as combinações disponíveis para retorno; não deve acontecer como efeito incidental da preferência de quem edita o modelo.

Um sucesso não transfere sua prova à etapa seguinte

Na avaliação de compra, análise sintática, compilação do esquema e geração de um validador devem ser tratadas como responsabilidades distintas, mesmo quando uma ferramenta as reúne no mesmo comando. Essa divisão é uma proposta de controle, não uma sequência de implementação imposta pela RFC. A seção 4.2 da RFC 8610 deixa aos responsáveis pela aplicação a extensão da verificação dos dados e não apresenta CDDL como promessa de escrever sua implementação.

Um parse bem-sucedido informa que o programa aceitou sintaticamente aquela entrada. Não demonstra que os escapes foram convertidos no valor pretendido, que o esquema poderá ser compilado ou que outro analisador aceitará a mesma entrada. Por isso, recomenda-se examinar o resultado interpretado, não apenas a ausência de erro.

Quando houver compilação do esquema, seu sucesso precisa ter escopo declarado: quais restrições foram reconhecidas e quais verificações serão executadas? A compilação bem-sucedida não atesta, por si, a correção do gerador: o código ou artefato produzido preserva essas decisões? Recomenda-se conservar o modelo utilizado, as versões das ferramentas, suas opções relevantes e o artefato resultante, sem tratar um certificado genérico de suporte como substituto desse conjunto.

Depois vem a implantação. Um artefato gerado não comprova que foi distribuído; um comprovante de distribuição não comprova que o consumidor o carregou. O aceite deveria exigir uma forma de conferir o validador efetivamente em uso. Quando o consumidor executa somente código previamente gerado, ele pode nem ler CDDL: sua aceitação de mensagens não demonstra capacidade de analisar \u{hex}.

A distinção entre poder simbólico e executável, proposta por Lu Heng em seu ensaio sobre camadas de realidade, oferece uma analogia limitada. Aqui, um rótulo de suporte não substitui o comportamento verificável. A analogia é interpretação editorial, não norma técnica nem evidência de que algum fornecedor tenha descumprido uma promessa.

A mensagem recebida não certifica o modelo

No CBOR, strings de texto usam UTF-8 e seus caracteres não são representados por escapes; strings de bytes e de texto também são tipos distintos. É o que estabelece a RFC 8949, seção 3.1. Logo, a notação usada para escrever um literal CDDL não precisa reaparecer na mensagem transmitida. Procurar esse escape no tráfego, como prova de suporte ao parser CDDL, confundiria descrição e conteúdo.

A mesma RFC distingue dados bem-formados, dados válidos segundo as restrições do CBOR e dados esperados pela aplicação. Esses níveis não são intercambiáveis. RFC 8949, seção 1.2. A inferência para o aceite é que receber uma mensagem não basta: é preciso saber quais verificações ocorreram e qual resultado a aplicação produziu.

Uma mensagem aceita constitui evidência sobre aquela mensagem, naquele consumidor, sob aquela configuração. Não prova aceitação de todas as mensagens permitidas, rejeição das proibidas ou equivalência entre dois validadores. Recomenda-se incluir casos positivos e negativos e limitar a conclusão de interoperabilidade às versões, configurações e comportamentos efetivamente observados. Uma divergência em execução exige investigação; sozinha, não identifica se a causa está no modelo, no gerador, no artefato carregado ou na própria mensagem.

Além disso, a RFC 8610, seção 5, recomenda não fazer a segurança do sistema depender da correção do modelo ou da implementação CDDL sem defesas adicionais. A verificação estrutural não deve receber uma responsabilidade de segurança maior do que aquela que efetivamente cumpre.

Reverter exige escolher o que será restaurado

Há pelo menos duas decisões distintas a documentar: restaurar um validador anterior já preservado ou reconstruí-lo a partir do modelo. No segundo caminho, é necessário demonstrar que as ferramentas disponíveis conseguem repetir o processamento relevante. Reintroduzir uma versão antiga do parser sem verificar o modelo que ela receberá deixa essa promessa incompleta. A combinação de retorno também precisa ser avaliada com as mensagens que continuará recebendo.

Recomenda-se, portanto, conservar uma combinação de retorno avaliada em conjunto. Se for escolhida uma escrita alternativa para manter compatibilidade, ela deve ser revisada como mudança de fonte e comparada quanto ao significado; não basta remover chaves mecanicamente. Reconstrução idêntica em bytes e comportamento equivalente também são critérios diferentes: as condições de aceite precisam dizer qual será cobrado e como.

A RFC 9682, seção 4, alerta para interpretações divergentes em ambientes com ferramentas atualizadas e antigas, potencialmente exploráveis, e recomenda cuidado de código-fonte com procedência, integridade e aplicabilidade dos modelos. Isso não é relato de incidente. Justifica exigir evidência antes de converter uma possibilidade de retorno em compromisso de continuidade.