Resumen

  • El permiso para aceptar cero reglas en un archivo CDDL es sintáctico. RFC 9682 mantiene la exigencia semántica de una regla de entrada después de procesar las directivas.
  • En un sistema modular, conservar el archivo principal no basta para reproducir lo aceptado. También importan las dependencias resueltas, el entorno y la raíz elegida.

¿Qué compra una organización cuando recibe un componente acompañado de una comprobación satisfactoria? La respuesta parece evidente hasta que parte de ese componente se obtiene de otros archivos y la regla que determina su uso se selecciona fuera del documento entregado.

En ese momento, una prueba puede ser auténtica y, aun así, referirse a un objeto distinto del que utiliza el comprador. No hace falta que alguien mienta. Basta con que la aceptación conserve una imagen demasiado pequeña de lo que se ha compuesto.

Una modificación de CDDL permite observar ese problema antes de que se convierta en una disputa contractual. El cambio no consiste en tolerar modelos incompletos. Consiste en reconocer que una fuente todavía no es el modelo completo y que algunas condiciones solo pueden exigirse después del ensamblaje.

El cero tiene un ámbito preciso

ABNF, la notación de la gramática, permite expresar el mínimo de repeticiones. Si ese mínimo se omite, puede ser cero; si se fija en uno, debe aparecer al menos un elemento. La consecuencia está en el conjunto de entradas que acepta el análisis sintáctico, no en una autorización para declarar terminado cualquier resultado. RFC 5234, sección 3.6

RFC 9682, publicado en noviembre de 2024, permite archivos CDDL sin reglas porque las directivas de módulos pueden aportarlas todas. Su sección 3.1 exige que, una vez procesadas las directivas, permanezca una regla que proporcione el punto de entrada. El anexo informativo B.2 adopta también un tratamiento semántico posterior para el contenido de cadenas de bytes calificadas. Son decisiones sobre etapas, no renuncias al significado. RFC 9682

Conviene distinguirlo de otra discusión: que un dato tenga la forma correcta no demuestra que sea verdadero. Aquí la pregunta es anterior. ¿Se ha formado un modelo utilizable? Un archivo CDDL vacío no equivale a un validador completo que acepte todos los datos.

En CDDL básico, la primera regla definida actúa como raíz y debe ser un tipo, no un grupo. No se exige que su nombre sea literalmente start. La aplicación decide por separado hasta dónde impone la descripción de datos. Invocar esa discreción no convierte en opcional la condición de formación del modelo. RFC 8610, secciones 2.2.4, 4.2 y 5

Por eso, añadir una regla irrelevante para satisfacer una comprobación antigua puede empeorar la situación. El expediente mostrará algo no vacío, pero no habrá demostrado que la entrada elegida corresponda al uso previsto. Se habrá confundido la presencia con la pertinencia.

Una parte de la especificación vive en el entorno

La propuesta de módulos consultada el 7 de septiembre de 2026 es draft-ietf-cbor-cddl-modules-07, fechada el día 2. Sigue siendo un Internet-Draft y no un RFC. El RFC de 2024 remitía a una versión anterior.

Las directivas se presentan como comentarios para las herramientas básicas. Esto facilita archivos diseñados para ambos usos, pero no garantiza que ignorar una directiva de la que depende el modelo produzca el mismo resultado que procesarla. La propuesta diferencia, además, la inclusión de reglas de la importación que sigue dependencias referenciadas. CDDL Module Structure, versión 07

La organización de los directorios de origen y su prioridad no se fija por completo para todos los contextos. Una implementación descrita busca primero en el directorio actual y después en su colección. Otro ejemplo selecciona la raíz mediante la línea de órdenes y genera una primera regla sintética sin aportar archivo de entrada. Son ejemplos del documento, no experimentos ejecutados para este artículo.

Supongamos que un proveedor ensambla con su colección habitual y el cliente con otra. El archivo principal puede conservar exactamente sus bytes, mientras cambian las reglas incorporadas. Si el registro de aceptación solo identifica aquel archivo, no permitirá distinguir ambos casos.

Un prefijo de espacio de nombres ayuda a evitar colisiones entre reglas. No acredita el origen del contenido encontrado bajo un nombre de módulo. La confianza en ese origen tampoco determina por sí sola que se haya seleccionado la raíz adecuada. El resultado necesita una explicación que mantenga separadas esas preguntas.

La causa de una diferencia puede ser ordinaria: una copia local más reciente, una colección incluida con una versión nueva de la herramienta o una prioridad de búsqueda no documentada. Se trata de escenarios plausibles, no de incidentes atribuidos a una empresa. Su utilidad consiste en mostrar lo que el archivo aislado deja fuera de la prueba.

Aceptar el resultado que realmente se utilizará

Una propuesta práctica es conservar un registro de composición: contenidos fuente, configuración de búsqueda, versión del procesador, raíz elegida y modelo resultante. No es una nueva exigencia del IETF. Es una forma de limitar el coste de reconstruir decisiones cuando cambian las personas y las herramientas.

Ese registro debe distinguir el éxito del análisis sintáctico, la resolución de dependencias y la formación del modelo con la entrada esperada. No es necesario repartirlos entre tres departamentos. Sí es necesario que un único indicador verde no certifique más trabajo del que efectivamente se realizó.

Exigir que todas las piezas sean autosuficientes puede bloquear una composición válida. Suprimir el control sin situarlo al final puede permitir que nadie compruebe el conjunto. Ambas respuestas conservan la comodidad de una lista antigua a costa de entender peor el sistema nuevo.

Las fuentes no establecen una tasa de adopción, pérdidas económicas ni un ataque concreto. Tampoco se han ejecutado pruebas de implementación aquí. La conclusión documentada es limitada: se admite un tipo de entrada antes rechazado y la condición final sobrevive. La conclusión de gestión es una inferencia: la prueba y la responsabilidad deben trasladarse con ella.