Resumen

  • La RFC 9517 registra el espacio URN ddi, compuesto por una agencia aprobada, un recurso asignado dentro de esa agencia y una versión explícita.
  • Resolver exige convertir la agencia en un nombre bajo ddi.urn.arpa, seguir DNS/DDDS y NAPTR, elegir un servicio y presentar el URN original.
  • La forma correcta no prueba asignación, autoridad, disponibilidad, integridad ni preservación. Cada afirmación pertenece a un actor y necesita un comprobante distinto.

El inventario mostraba un identificador permanente. El validador aceptaba su sintaxis y el espacio de nombres figuraba en IANA. Aun así, un servicio descubierto estaba caído y otro entregaba una descripción de una versión anterior. La cadena de caracteres seguía estable. Lo inestable era la infraestructura y, sobre todo, la conclusión que la organización había pegado al nombre.

La RFC 9517 fue publicada en enero de 2024 como documento Informational del Independent Stream. Registra ddi para recursos acordes con los estándares de Data Documentation Initiative. No es una norma del Standards Track ni expresa consenso de la IETF. Su valor para operaciones está en separar las manos que crean identidad de las que resuelven, sirven y conservan.

Una cadena bien formada puede no haber sido asignada

El patrón es urn:ddi:<agencia>:<recurso>:<versión>. La DDI Alliance aprueba el identificador de la agencia, basado en convenciones de dominio invertido. Después, cada agencia administra sus recursos, versiones y posibles subagencias.

La unicidad es una obligación repartida. La Alianza evita que dos agencias reciban el mismo ámbito; la agencia evita colisiones dentro de él. Un parser solo comprueba caracteres y separadores. La RFC 8141 impide el salto lógico: un texto que empieza por urn: no se convierte en URN asignado por parecerse a uno. El NID debe estar registrado y la parte específica debe proceder del proceso administrado.

Las reglas de comparación también importan. urn, ddi y la agencia no distinguen mayúsculas. El recurso y la versión sí. Poner todo en minúsculas puede unir objetos diferentes; respetar mayúsculas en la agencia puede duplicar una autoridad. Hay que conservar el valor original, el análisis por componentes y la normalización realizada.

La persistencia no vive dentro de los dos puntos

La propia RFC vincula la persistencia a la continuidad de la agencia y a una delegación adecuada de resolución. La agencia sigue siendo responsable de que la referencia sobreviva. El URN puede permanecer en un artículo mientras desaparecen el DNS, el catálogo, los ficheros o el permiso de acceso.

El campo de versión tampoco es una certificación. Distingue una revisión según la política de la agencia, pero no demuestra qué bytes devolvió un repositorio ni si dos copias coinciden. Para eso hacen falta el identificador devuelto, una huella, procedencia y constancia de preservación.

Las subagencias facilitan repartir administración y servidores. También abren otra frontera: la agencia principal puede seguir aprobada cuando la rama ya cambió de operador. Una auditoría debe guardar la cadena completa, no solo la marca DDI.

Resolver es ejecutar una cadena, no abrir un nombre

El cliente extrae la agencia, normaliza su caso, invierte sus etiquetas y añade .ddi.urn.arpa. El DNS actúa como base DDDS. La consulta pasa por la autoridad de urn.arpa, la DDI Alliance y el servidor de la agencia. NAPTR describe opciones. Una regla terminal u puede producir un URI; una s remite a SRV.

Lo obtenido es información para conectar con uno o varios servicios. No es el recurso. Tampoco demuestra que el servicio esté vivo, continúe autorizado o sirva la versión indicada. La evidencia debe incluir resolver, hora, TTL, edad de caché, validación, campos NAPTR, respuesta SRV, criterio de selección, identidad TLS y respuesta final.

I2R puede entregar una instancia del recurso; I2C, una descripción; I2L, un localizador; I2Ls, varios. Que todos terminen con una respuesta de red exitosa no los convierte en la misma prueba. Una descripción puede sobrevivir al objeto. Una URL puede apuntar a otra revisión. Dos ubicaciones pueden discrepar. Un sistema que reduce todo a encontrado pierde el significado de la operación.

DoH protege un tramo, no el objeto científico

La RFC considera bajo el perfil de seguridad por tratarse de información pública, pero reconoce la dependencia de las amenazas generales del DNS. DoH puede cifrar el enlace entre cliente y resolutor. No autentica por sí solo a la agencia, al repositorio ni al contenido.

Conviene separar DNSSEC, transporte cifrado, identidad TLS, mandato institucional y verificación del objeto. El orden probatorio es: registro del espacio, sintaxis, aprobación de agencia, asignación del recurso, delegación observada, tipo de servicio, terminal autenticado, respuesta ligada al URN exacto, objeto validado y decisión de uso.

El identificador permanente mantiene una referencia común durante todos esos cambios. No fracasa por ser limitado. Fracasa la gobernanza cuando convierte esa referencia en una promesa de disponibilidad o verdad.

Fuentes