A data parecia óbvia. A biblioteca ainda era parte da decisão.

Resumo

• A revisão 28 de Concise Diagnostic Notation organiza uma forma humana de representar CBOR e suas extensões, mas o arquivo não carrega toda a política que define sua interpretação.
• Processos sensíveis precisam de um recibo de interpretação com revisão, registro, extensão, implementação, versão, permissões, indicadores ignorados, avisos, valor produzido e, quando necessário, hash dos bytes.

Ler uma representação não é o mesmo que reproduzir sua execução. Essa diferença se torna crítica quando a notação deixa de ser uma ajuda de diagnóstico e entra em compilação, provisionamento, assinatura ou automação.

O Internet-Draft Concise Diagnostic Notation, do grupo de trabalho CBOR da IETF, consolida a escrita textual do modelo de dados CBOR. Um literal com prefixo chama uma extensão de aplicação. h e b64 podem transformar texto em bytes; dt trata uma representação temporal; ip trata endereços e prefixos. Uma sequência prefixada pode levar parâmetros e produzir um único item do modelo.

O arquivo, porém, só solicita um nome. Ele não prova qual fotografia do registro resolveu esse nome, qual especificação foi aplicada, qual biblioteca e versão executaram a conversão, nem se o operador autorizou a extensão. Opções, pacotes instalados, allowlist e política de avisos ficam fora do texto.

A revisão 28 explicita o limite. CDN é voltada a pessoas e não é uma representação determinística. Ir de um valor ao texto e voltar não garante a mesma grafia nem os mesmos bytes. Se um indicador de codificação aparece no argumento de uma extensão que não define tratamento especial, o consumidor precisa aceitá-lo, processando ou ignorando; recomenda-se avisar quando ele não é processado. Portanto, sucesso de parse não demonstra que tudo o que o revisor viu influenciou o resultado.

A seção de segurança também recomenda impedir que um atacante invoque extensões que o operador não planejou expor. Habilitação explícita e lista de permissões são limites legítimos, configurados fora de banda. Duas plataformas podem entender a gramática e tomar decisões diferentes porque seus responsáveis concederam capacidades diferentes.

O registro não contém o ambiente

O rascunho propõe um registro de identificadores e torna obrigatórias as extensões h, b64, t1, b1, dt e ip. O registro reduz colisões; não transforma entrada, especificação, código e política local numa única garantia.

A política é Expert Review. O texto admite que uma especificação completa talvez ainda não esteja disponível e que um nome já implantado possa ser registrado para evitar colisão. “Registrado” prova coordenação nominal. Não prova semântica completa, uniformidade entre bibliotecas, segurança, habilitação ou autorização para o uso seguinte.

Imagine que desenvolvimento carregue toda extensão instalada e produção permita apenas um conjunto mínimo. O mesmo arquivo é aceito num lado e recusado no outro. O hash coincide e o prefixo existe. A diferença é uma decisão operacional. Sem registrar a lista permitida, a auditoria não consegue explicar a divergência.

Agora imagine que ambos aceitem. Uma biblioteca interpreta um indicador; a outra o ignora e emite um aviso que a interface descarta. Os dois painéis ficam verdes, mas a prova semântica é diferente. Resultado e avisos precisam acompanhar o status.

A revisão 28 avisa que ainda está se movendo

O Datatracker mostra trabalho ativo do grupo CBOR, em último chamado do grupo, com estado IESG “I-D Exists”. É Internet-Draft, não RFC nem padrão aprovado.

Há ainda uma divergência de status: o cabeçalho diz “Intended status: Standards Track”; a API do Datatracker registra “Informational”. Este artigo preserva a divergência e não inventa uma decisão final.

A nota editorial informa que a revisão 28 tenta refletir remoções de recursos discutidas na lista como delta da 27. Ela chama o texto de parcialmente inconsistente, alerta que explicações podem estar enganosas e registra falta de contribuição do grupo sobre os nomes CDN e b1/t1. O diff remove, entre outros pontos, a extensão CRI, um registro de indicadores e representações binárias com tags para entrada CDN.

Assim, “suporta a revisão 28” é uma afirmação incompleta. É preciso dizer quais recursos antigos saíram, se algum ficou atrás de uma opção, qual registro foi usado e qual comportamento vem do conteúdo técnico atual.

O recibo de interpretação

Um único “válido” comprime perguntas independentes: quais bytes foram revisados; qual gramática os aceitou; qual registro resolveu o nome; qual especificação, implementação e versão rodaram; qual allowlist permitiu a chamada; quais indicadores foram processados ou ignorados; quais avisos foram preservados; qual valor e quais bytes resultaram.

Cada resposta pode mudar sozinha. O arquivo fica estável enquanto o pacote de extensão sobe de versão. O registro fica estável enquanto a política local muda. O valor permanece e a codificação muda. Os bytes ficam exatos, mas o aplicativo continua sem autoridade para executar uma ação.

Por isso, um fluxo de alto impacto deve produzir um recibo de interpretação. Trata-se de recomendação operacional de Daniel Kade, não de requisito da revisão 28. O recibo registra hash da fonte, revisão, fotografia do registro, identificador, especificação, implementação, versão, parâmetros, configuração fora de banda, lista permitida, tratamento dos indicadores, avisos, descrição estável do valor e, se necessário, perfil e hash da codificação.

O recibo termina na saída do intérprete. Validação por esquema, assinatura, autorização, mudança de rede e efeito comercial exigem provas próprias. Um sinal único de “válido” impede saber em qual camada ocorreu o desvio.

As fontes não provam adoção, interoperabilidade medida, produto específico, incidente, vulnerabilidade, desempenho ou indisponibilidade. O argumento não depende disso. Modelo de extensão, indicadores que podem ser ignorados, registro, habilitação fora de banda e não determinismo já mostram que o controle é compartilhado.

RFC 8949, RFC 8610, RFC 4648 e RFC 3339 delimitam CBOR, CDDL, codificações de base e tempo. Não demonstram que duas instalações usem o mesmo código e configuração. RFC 9741 trata de codificação determinística depois que o valor existe; não decide qual valor a extensão deve criar.