Resumen

  • La revisión de la gramática no actualiza por sí sola los procesadores ni acredita los validadores que estos ayudan a generar.
  • La unidad útil de revisión es una entrega identificable: modelo exacto, herramientas utilizadas, artefacto producido y consumidor efectivo, con resultados de ejecución separados.

En un proceso hipotético de entrega, un equipo actualiza la comprobación sintáctica de sus modelos CDDL y obtiene un resultado satisfactorio. La aplicación, sin embargo, incorpora un validador generado con anterioridad. Ambas cosas podrían coexistir: la comprobación reciente y el artefacto antiguo tendrían genealogías distintas. El color del informe no las uniría.

Para quien autoriza el despliegue, la pregunta incómoda no sería si existe una gramática corregida, sino qué interpretación acabó convertida en código ejecutable. Un parser, o analizador sintáctico, analiza el modelo; un generador puede transformar esa interpretación en un validador. Aunque ambas funciones compartan herramienta, conviene distinguirlas. Aquí interesa esa arquitectura posible, no presentarla como un procedimiento impuesto por CDDL.

La consecuencia práctica es precisa: aprobar una fuente y distribuir un derivado son decisiones diferentes. La genealogía permite comprobar su relación; las pruebas de comportamiento permiten valorar lo que hace ese derivado. Ninguna sustituye a la otra.

Una referencia corregida no reescribe un ejecutable

La referencia de partida es RFC 8610, que define CDDL para describir estructuras de datos representadas en CBOR o JSON.

El Apéndice A normativo de RFC 9682 sustituye la gramática ABNF recopilada del Apéndice B de RFC 8610. La revisión resuelve las cuestiones recogidas en las erratas 6278, 6526, 6527, 6543 y 6575 e incorpora el escape hexadecimal \u{hex} para expresar valores escalares Unicode.

ABNF, definida en RFC 5234, proporciona una notación formal para la sintaxis. Su precisión no convierte la publicación de una gramática en un registro de las herramientas que la implementan. Consultar la referencia correcta resuelve qué reglas deben tomarse como base; no identifica el ejecutable que intervino en una entrega.

La compatibilidad de la ampliación es asimétrica: el material antiguo conforme sigue encajando en la gramática nueva, pero un modelo que emplee la sintaxis añadida no tiene garantizada la aceptación por procesadores anteriores. Tampoco equivale «antes lo aceptaba una herramienta» a «era conforme».

De ahí que una declaración como «compatible con CDDL» resulte insuficiente para este control. La propuesta operativa es exigir una afirmación acotada: qué edición y capacidades se admiten, bajo qué configuración y para qué modelos. Eso permitiría separar una promesa comercial de una combinación técnicamente examinable, sin atribuir capacidades a un producto por su nombre.

Buscar el modelo dentro de la historia del artefacto

En el escenario hipotético inicial, la revisión debería comenzar por el validador incluido en el paquete, no por el archivo más reciente del repositorio. Desde ese artefacto habría que remontarse a la operación que lo produjo y al modelo que recibió. Una fecha cercana entre ambos no demostraría parentesco.

Conviene conservar los bytes exactos del modelo y su huella criptográfica junto con la identificación de la herramienta, sus opciones y el resultado de generación. La huella serviría para comparar contenidos, no para certificar por sí sola quién los aprobó. La autorización del cambio y la autenticidad del registro necesitarían sus propias evidencias.

Un ejemplo hipotético permite ver por qué importa esa precisión: estado = "se\u00F1al" y estado = "se\u{F1}al" expresan el mismo valor con los escapes correspondientes, pero no tienen los mismos bytes de fuente. La sintaxis de escapes de RFC 9682 sustenta esa equivalencia de valor, no una identidad entre archivos.

Aunque la modificación se presentara como un retoque de escritura, habría cambiado la entrada entregada al parser. El expediente debería permitir saber cuál de las dos recibió el generador. Que el revisor viera la segunda mientras el producto conservara un derivado de la primera sería una posibilidad hipotética que investigar, no un fallo que este análisis atribuya a ninguna herramienta.

Por eso interesa registrar el ejecutable realmente invocado, no solo la versión prevista en una instrucción de trabajo. La capacidad declarada, la configuración efectiva y el resultado de analizar esos bytes responderían a preguntas distintas. Una etiqueta de versión ayuda a identificarlas; no las demuestra todas.

El acta de nacimiento no prueba el comportamiento

El resultado de parseo acredita, dentro del alcance de la comprobación realizada, que una herramienta aceptó una fuente. No basta para concluir que se compiló el esquema, que se generó un validador o que este aplica todas las restricciones pretendidas. Cada conclusión necesita una salida identificable de su propia etapa.

RFC 8610, sección 4.2, contempla usos de CDDL como ayuda para implementar y comprobar estructuras, y deja a diseñadores e implementadores decidir hasta dónde hacer cumplir la descripción, teniendo en cuenta la seguridad. No conviene convertir una función posible de las herramientas en una garantía automática sobre cualquier producto generado.

Para la cadena hipotética examinada aquí, una comprobación útil compararía el comportamiento del validador candidato con casos cuya aceptación o rechazo se hubiera establecido a partir del modelo y del protocolo. Incluiría literales escapados, valores próximos pero distintos y entradas fuera del esquema, comparando valores y bytes, no solo la apariencia del texto. No bastaría con generar ejemplos y aceptarlos mediante el mismo recorrido de interpretación: una equivocación compartida podría pasar inadvertida.

Tampoco sería riguroso prometer equivalencia semántica universal después de un conjunto finito de casos. Coincidir en ellos reforzaría la confianza dentro de su cobertura. Una divergencia exigiría localizar la etapa responsable antes de culpar a la gramática: lectura del literal, representación del esquema, generación o ejecución del código.

Reconstruir el artefacto añadiría otra evidencia, también limitada. Reproducir el mismo resultado demostraría reproducibilidad bajo las condiciones conservadas, no que la interpretación fuese correcta. Estas comprobaciones son recomendaciones de ingeniería para hacer examinable la entrega, no obligaciones adicionales atribuidas a RFC 9682.

El consumidor no siempre lee CDDL

En otra variante hipotética, la aplicación consumidora recibiría únicamente un validador ya generado y mensajes CBOR. Nunca analizaría el modelo CDDL. Su antigüedad no permitiría deducir, por sí sola, que debe rechazar datos porque la fuente del esquema utilizó una notación más reciente. A la inversa, actualizar un parser de desarrollo no demostraría que se reemplazó el código desplegado.

La separación entre representación del modelo y representación del mensaje tiene una base concreta. RFC 8949, sección 3.1, define las cadenas de texto CBOR mediante UTF-8: los caracteres no se transmiten como escapes de la notación fuente. La escritura elegida en CDDL no debe confundirse con una nueva exigencia de escape para el receptor CBOR.

El control propuesto consiste en vincular la identidad del validador con la versión y configuración del consumidor que efectivamente lo ejecuta. Un paquete publicado demostraría disponibilidad; su presencia verificada en una instancia demostraría instalación; una ejecución registrada aportaría información sobre uso. Son hechos relacionados, pero no intercambiables.

Y todavía quedaría el mensaje real. RFC 8949 distingue entre datos bien formados, válidos y ajustados a lo que espera una aplicación. Por analogía, que el modelo se haya procesado correctamente no acredita que una entrada concreta cumpla el protocolo. Una observación de interoperabilidad tendría que identificar participantes, versiones, mensajes y comportamiento, sin extender su conclusión a intercambios no observados.

Un expediente de entrega, no una colección de sellos

La cadena completa tendría que conservar relaciones comprobables: la publicación fija la referencia; los bytes identifican el modelo; versión, capacidad y configuración delimitan el parser; el registro de parseo documenta su aceptación; el registro de compilación del esquema documenta otra etapa; el validador generado es un producto identificable. Después vienen el consumidor desplegado, el mensaje efectivamente procesado y la interoperabilidad observada. Acumular certificados aislados no demostraría que todos se refieren a la misma entrega.

La sección 4 de RFC 9682 advierte de la confusión al mezclar herramientas actualizadas y no actualizadas y de interpretaciones divergentes explotables. Recuerda la necesidad de comprobar procedencia, autenticidad, integridad y aplicabilidad, y aconseja tratar los modelos CDDL operativos como código fuente.

La distinción de Lu Heng entre poder simbólico y poder ejecutable procede de otro terreno: la gobernanza. Usada aquí como lente analítica, no como requisito IETF, invita a preguntar qué hay detrás del sello «aprobado». La analogía no resta autoridad a la norma: evita atribuir al sello una observación que nadie ha documentado.

Sin registros de herramientas y despliegues no corresponde afirmar adopción, incidentes ni fallos de productos. El resultado honesto puede ser más estrecho: se conoce la referencia normativa, pero todavía no está acreditada la relación entre esa referencia y un consumidor concreto.