Resumo

  • O RFC 9682 permite zero regras no arquivo de entrada, mas mantém a obrigação de haver uma regra de entrada após o processamento de todas as diretivas.
  • A modularização amplia o objeto do aceite: além do arquivo entregue, entram as dependências encontradas, a raiz escolhida e o ambiente que produziu o modelo.

A entrega veio com um arquivo e uma confirmação de que ele passou no teste. O comprador arquivou os dois. Meses depois, precisou reproduzir o resultado com outra ferramenta e descobriu que faltava registrar justamente o que não estava no arquivo: de onde vieram as regras incorporadas e qual delas havia sido escolhida como entrada.

Esse é um cenário hipotético, não o relato de uma falha empresarial. Ele ajuda a enxergar uma consequência da modularização que costuma ficar escondida sob uma palavra confortável: validado. Quando o produto final é montado a partir de várias fontes, é preciso dizer o que recebeu essa validação.

Uma alteração aparentemente pequena da gramática CDDL torna a pergunta especialmente clara. O documento permite uma entrada que antes seria rejeitada, sem abrir mão da condição exigida ao final. A oportunidade é melhorar o momento da verificação. O risco é tratar a sua retirada de uma etapa como retirada de todo o processo.

A ausência de uma regra pode ser temporária e legítima

Na notação ABNF, usada para escrever a gramática, o limite inferior omitido de uma repetição permite zero ocorrências. Com limite inferior igual a um, exige-se ao menos uma. A diferença determina o que o analisador sintático aceita, e não se o trabalho está pronto para uso. RFC 5234, seção 3.6

Publicado em novembro de 2024, o RFC 9682 passa a admitir arquivos CDDL sem regras porque diretivas de módulos podem fornecer todas elas. A seção 3.1 mantém, depois do processamento das diretivas, a restrição semântica de haver uma regra que ofereça uma entrada. O apêndice informativo B.2 também separa a análise externa de cadeias de bytes qualificadas do tratamento posterior de seu conteúdo. Adiar uma etapa não elimina seu significado. RFC 9682

Não se está discutindo aqui se um dado bem formatado diz a verdade. A pergunta vem antes: existe um modelo utilizável contra o qual o dado possa ser examinado? Um arquivo CDDL vazio não é um modelo concluído que aceita indiscriminadamente qualquer entrada de dados.

No CDDL básico, a primeira regra definida funciona como raiz e precisa ser um tipo, não um grupo. Seu nome não precisa ser start. A decisão da aplicação sobre o grau de verificação dos dados é outra questão. Misturar essas duas camadas faria parecer que uma escolha de aplicação cancela uma condição da formação do modelo. RFC 8610, seções 2.2.4, 4.2 e 5

Isso também mostra por que acrescentar uma regra qualquer apenas para atender a uma lista antiga não é uma boa solução. O arquivo ganha conteúdo, mas a organização continua sem saber se a raiz selecionada corresponde ao uso pretendido. O indicador melhora enquanto a explicação piora.

O ambiente passa a fazer parte da entrega verificável

A proposta de módulos consultada em 7 de setembro de 2026 é draft-ietf-cbor-cddl-modules-07, de 2 de setembro. Ainda é um Internet-Draft, não um RFC aprovado. O RFC 9682 remetia a uma versão anterior.

A proposta carrega diretivas em comentários que ferramentas básicas podem ignorar. Isso permite projetar certos arquivos para ambos os usos, mas não promete equivalência entre ignorar uma diretiva necessária e processá-la. Ela distingue inclusão de regras de importação com dependências referenciadas e deixa parte da organização dos diretórios de origem a cargo do contexto. CDDL Module Structure, versão 07

Em uma implementação descrita, a busca começa no diretório atual e segue para a coleção da própria ferramenta. Outro exemplo escolhe a raiz pela linha de comando e gera uma primeira regra sintética sem fornecer arquivo de entrada. São exemplos documentados; não foram executados neste trabalho.

Imagine, então, que o ambiente de desenvolvimento contenha uma definição mais recente com o mesmo nome de uma dependência. A montagem feita ali pode divergir da montagem de uma equipe que usa a coleção distribuída com a ferramenta. O arquivo principal não precisa mudar para que o objeto efetivamente aceito seja outro.

Separar espaços de nomes ajuda a administrar colisões. Não comprova sozinho a procedência do conteúdo encontrado. E confiar na procedência não comprova que a raiz escolhida seja apropriada. São perguntas complementares, não formas intercambiáveis de dizer que tudo foi validado.

A documentação do aceite precisa acompanhar essas escolhas sem virar uma coleção de formulários inúteis. Uma referência ao conteúdo exato, à configuração de busca e ao resultado produzido vale mais do que vários carimbos sobre o arquivo que iniciou a composição.

Três resultados, sem três burocracias

Uma equipe pode realizar toda a operação com uma única ferramenta e continuar distinguindo os resultados: a sintaxe foi aceita, as dependências foram processadas e o modelo final tem a entrada esperada. O objetivo não é criar um departamento para cada verbo. É impedir que o primeiro sucesso seja usado como prova dos demais.

Este artigo recomenda um registro de composição que associe fontes, configuração, versão do processador, raiz e saída final. Trata-se de orientação editorial, não de uma exigência administrativa nova do IETF. Sua função é permitir que outra pessoa reconheça e reproduza o objeto sobre o qual houve decisão.

Sem esse registro, uma limpeza de diretórios ou uma atualização de coleção pode apagar informações necessárias para explicar o passado. Preservar o arquivo principal é importante, mas insuficiente quando escolhas decisivas aconteceram fora dele.

As fontes sustentam o desenho e seus limites. Não sustentam uma taxa de adoção, um prejuízo estimado nem a acusação de um ataque específico. Nenhum experimento de implementação foi executado aqui. A inferência gerencial é deliberadamente estreita: se uma condição continua necessária, ela precisa reaparecer no ponto certo, com evidência reconhecível.