Resumen

  • La revisión 28 de Concise Diagnostic Notation formaliza una escritura humana de valores CBOR y extensiones registradas, pero el archivo no contiene toda la configuración que decide su significado.
  • Antes de confiar en el resultado, una organización necesita un recibo de interpretación con revisión, registro, implementación, versión, permisos, indicadores ignorados, avisos, valor y bytes resultantes.

La promesa de una notación diagnóstica es poder mirar un valor sin descifrar primero una secuencia binaria. Esa promesa es valiosa. El error comienza cuando la legibilidad se convierte, sin pruebas, en autoridad.

El borrador Concise Diagnostic Notation del grupo CBOR de la IETF reúne y formaliza la notación textual asociada al modelo de datos de CBOR. Los literales con prefijo permiten que texto hexadecimal o Base64 se transforme en bytes, que una fecha se represente mediante una extensión temporal o que una dirección y un prefijo IP se expresen de forma reconocible. Una secuencia prefijada puede suministrar parámetros y terminar en un único elemento de datos.

El prefijo, sin embargo, es una solicitud a un intérprete. Para saber qué ocurrió hay que conocer qué instantánea del registro resolvió el nombre, qué especificación se tomó como referencia, qué código y versión se ejecutaron, qué opciones estaban activas y qué lista de permisos aplicó el operador. El texto solo no responde esas preguntas.

La propia revisión 28 dibuja esa frontera. CDN no pretende ser una representación determinista. Un recorrido desde un valor hacia texto y de regreso no garantiza la misma forma textual ni los mismos bytes. Si aparece un indicador de codificación en el argumento de una extensión que no le da un significado especial, el consumidor debe aceptarlo procesándolo o ignorándolo; se recomienda avisar cuando no se procesa. Por eso, dos programas pueden mostrar “válido” y conservar pruebas distintas sobre lo que hicieron.

La seguridad añade una decisión aún más local. Una herramienta debe evitar que un atacante invoque extensiones que el operador nunca quiso exponer. El borrador contempla habilitación explícita o listas permitidas y describe ese permiso como configuración fuera de banda. Una extensión instalada puede estar deshabilitada; un nombre conocido puede ser rechazado correctamente; una actualización de política puede cambiar el resultado aunque el archivo permanezca idéntico.

Registrar no equivale a ejecutar

La propuesta crea un registro de identificadores de extensión y exige implementar un núcleo: h, b64, t1, b1, dt e ip. Ese registro reduce colisiones y hace que documentos distintos puedan pedir la misma función con el mismo nombre. No certifica que todas las instalaciones ejecuten la misma biblioteca, con la misma versión y la misma política.

La política es Expert Review. El texto admite situaciones en las que todavía no existe una especificación completa y permite registrar un identificador ya desplegado para impedir que otro uso choque con él. La inscripción aporta evidencia sobre coordinación del nombre. No demuestra madurez, seguridad, habilitación local ni autorización para una operación posterior.

Pensemos en una promoción entre entornos. Desarrollo acepta un prefijo porque carga todas las extensiones disponibles. Producción utiliza una lista mínima y lo rechaza. El hash del archivo coincide y el identificador está registrado. La diferencia no está en el documento, sino en quién controla la capacidad de invocar código. Sin capturar esa política, el expediente no puede explicar la divergencia.

O pensemos en dos aceptaciones. Un entorno interpreta un indicador; el otro lo ignora conforme a su extensión y emite un aviso que el sistema de compilación descarta. La casilla verde coincide, pero el recorrido semántico no. Un control serio conserva los avisos y compara el valor producido, no solo la respuesta del analizador.

Un borrador que declara su propia incertidumbre

Datatracker sitúa la revisión 28 como Internet-Draft activo del grupo CBOR, en último llamado del grupo, con estado IESG “I-D Exists”. No es un RFC ni una norma aprobada.

Las fuentes congeladas muestran además una discrepancia: la cabecera dice “Intended status: Standards Track”, mientras la API de Datatracker registra “Informational”. Este análisis no inventa una reconciliación. Ambos son datos provisionales del proceso.

La nota editorial de la revisión es todavía más importante. Dice que la versión 28 intenta reflejar eliminaciones debatidas en la lista como diferencia respecto de la 27. Reconoce que el texto queda parcialmente inconsistente, que algunas secciones explicativas pueden resultar engañosas y que faltan aportaciones del grupo sobre los nombres CDN y b1/t1. La comparación elimina, entre otras cosas, la extensión CRI, un registro de indicadores y representaciones binarias etiquetadas de entrada CDN.

Una declaración “compatible con la revisión 28” necesita, por tanto, detalles. ¿Se eliminaron realmente las funciones antiguas? ¿Siguen ocultas tras una opción? ¿Qué tabla de registro utilizó el proceso? ¿Qué comportamiento corresponde al texto normativo actual y cuál a una explicación que el propio borrador considera desfasada?

Siete pruebas en lugar de una palabra

“Se analizó correctamente” debería abrir siete registros: bytes y hash exactos de la fuente; revisión de gramática; instantánea del registro; especificación e implementación concreta; versión y parámetros; lista permitida, opciones e indicadores; avisos y valor resultante, más el hash de bytes cuando la codificación exacta importa.

Cada capa puede moverse sola. El archivo puede permanecer fijo mientras cambia el paquete de extensión. El registro puede seguir igual mientras producción modifica permisos. El valor puede ser el mismo con bytes diferentes. Los bytes pueden ser exactos y, aun así, carecer de autorización para activar un dispositivo o firmar una orden.

El objeto que falta es un recibo de interpretación. Es una recomendación operativa de Daniel Kade, no un mandato del borrador. El recibo debe incluir el hash de la fuente, revisión, registro, identificador, especificación, implementación y versión; también parámetros, configuración fuera de banda, lista permitida, tratamiento de indicadores, avisos, descripción o hash del valor y, cuando corresponda, perfil de codificación y hash binario.

Después debe terminar. La validación por esquema, la firma, la autorización, el cambio de red y el resultado empresarial pertenecen a comprobantes posteriores. Mezclarlos en un único “válido” impide localizar el punto de fallo.

Esta separación coincide con una idea más amplia: una representación simbólica puede facilitar la coordinación sin poseer la decisión futura de cada operador. CDN mejora el mapa. El código ejecutado y la política local siguen perteneciendo al territorio. La especificación mínima compartida debe hacer visible ese límite, no borrar al responsable local.

Las fuentes no prueban despliegue, adopción, interoperabilidad medida, vulnerabilidades, incidentes ni comportamiento de productos concretos. Tampoco hace falta inventarlos. El modelo de extensiones, la posibilidad de ignorar indicadores, la política de registro y la habilitación fuera de banda bastan para demostrar que el significado operativo tiene dependencias externas.

RFC 8949 y RFC 8610 aportan CBOR y CDDL; RFC 4648 y RFC 3339 aportan codificaciones base y tiempo. Ninguno garantiza que dos intérpretes desplegados compartan biblioteca y configuración. RFC 9741 trata la codificación determinista de un valor; no decide qué valor construyó una extensión.