Resumen

  • RFC 3404 convirtió la resolución en una solicitud tipada: I2L, I2R, I2C e I2N pedían ubicaciones, instancias del recurso, descripciones y nombres persistentes; algunas variantes distinguían además entre uno y varios resultados.
  • S, A y U indicaban la representación del siguiente paso. P salía de DDDS hacia un procedimiento propio de la aplicación. Localizar un resolutor no autenticaba ni al interlocutor ni al objeto devuelto.

Hay éxitos que son errores con buena presentación. Si una aplicación solicita una descripción y recibe una URL desde la que quizá pueda descargar un archivo, obtuvo información relacionada, pero no la respuesta pedida. Si solicita el objeto y recibe metadatos sobre él, el transporte puede haber funcionado mientras fracasa el significado.

RFC 3404, publicado como estándar propuesto en octubre de 2002, definió las aplicaciones DDDS para resolver URI y URN. Formaba parte de una arquitectura repartida entre cinco textos: RFC 3401 presentaba el sistema, RFC 3402 formalizaba el algoritmo, RFC 3403 alojaba reglas NAPTR en DNS, RFC 3404 precisaba las aplicaciones y RFC 3405 administraba los dominios uri.arpa. y urn.arpa..

El proceso partía de una cadena propia de la aplicación. En la resolución genérica de URI, el URI absoluto se canonicalizaba y codificaba; su esquema daba la primera clave conocida y se añadía uri.arpa. para la consulta DNS. En un URN, el identificador del espacio de nombres llevaba a urn.arpa.. Las reglas podían reescribir o delegar hasta producir una salida terminal o entregar el control a otro sistema.

Las aplicaciones de URI y URN eran técnicamente iguales, pero se separaron para no atar el despliegue de una a la otra. Los URN ya contaban con una vía abreviada. Un espacio de nombres debía poder ofrecer resolución útil sin esperar que todos los esquemas URI aceptaran un resolutor genérico.

El campo Services daba tipo a la respuesta. I2L pedía una URI de ubicación; I2Ls, una o varias. I2R e I2Rs devolvían instancias del recurso. I2C entregaba una descripción. I2N producía un URN, aunque el documento advertía que la igualdad entre URN podía exigir reglas particulares del espacio de nombres.

Una ubicación no es el recurso. Indica dónde intentar obtenerlo. Una instancia es el contenido recibido. Una descripción afirma algo acerca de él. Un nombre persistente pretende mantener la identidad cuando cambian los lugares. El mismo identificador podía ofrecer las cuatro operaciones, pero ninguna demostraba por sí sola el resultado de las otras.

También importaba la cardinalidad. La s minúscula en I2Ls e I2Rs permitía un conjunto. Si el consumidor guardaba solo el primer elemento, introducía una política que no estaba en la respuesta. Una auditoría debe conservar el servicio pedido, si se esperaba uno o varios, el conjunto completo y la elección posterior.

Antes de los servicios podía aparecer un protocolo opcional. Su nombre, por sí solo, era insuficiente. RFC 3404 exigía una especificación de cómo ese protocolo codificaba la solicitud de resolución y representaba la respuesta. «HTTP» no aclara cómo distinguir una petición de metadatos de una petición del recurso, qué tipo de contenido representa cada resultado o cómo se transporta una lista.

La lección es que descubrir una capacidad no crea el contrato que la usa. El protocolo, la operación solicitada y la clase observable de la respuesta deben alinearse. De otro modo, dos programas pueden reconocer la misma etiqueta y seguir hablando de cosas distintas.

Flags describía un eje separado. S, A y U eran indicadores terminales de DDDS. S conducía a una consulta SRV sobre el nombre resultante. A llevaba a una consulta de direcciones. U entregaba un URI. Terminal significaba que terminaba el bucle DDDS, no que la tarea completa o su validación hubieran concluido.

P era deliberadamente distinto. Señalaba que el procesamiento restante era específico de la aplicación y quedaba fuera de los conceptos DDDS. No era un cuarto tipo terminal. Era una frontera de control: a partir de ahí mandaba otro sistema de reglas.

En la aplicación de 2002 los cuatro indicadores se excluían entre sí. Sin embargo, una implementación no debía suponer que Flags tendría siempre cero o un carácter, porque futuras versiones podían definir combinaciones. Un indicador desconocido obligaba a ignorar el registro y continuar. Esa prueba tenía prioridad sobre el orden normal: un nuevo indicador podía cambiar cómo interpretar el resto del registro.

Services podía estar vacío al principio de una delegación. En ese punto, el publicador quizá aún no sabía qué protocolo ofrecería el resolutor final. Vacío no significaba inválido ni «cualquier servicio»; aplazaba la decisión.

El documento permitía una optimización estrecha dentro de un conjunto con el mismo ORDER. El cliente podía buscar un servicio más aplicable que su primera preferencia, pero debía conservar la misma entrada y salida del algoritmo básico. No podía cruzar ramas de delegación ni inspeccionar un ORDER superior después de hallar coincidencia.

Esa limitación protegía la diferencia entre capacidad local y autoridad publicada. Un cliente puede escoger entre opciones equivalentes que sabe usar. No puede ascender una opción cómoda desde otro nivel y presentarla como si el administrador la hubiera hecho equivalente.

Los datos SRV o de dirección de la sección Additional ahorraban viajes, pero nunca eran requisito. La aplicación debía continuar sin ellos. Descubrir el siguiente nombre, recibir datos auxiliares y completar la conexión eran tres hechos diferentes y debían registrarse como tales.

La seguridad tampoco viajaba automáticamente con el descubrimiento. Encontrar un resolutor no definía cómo autenticarlo ni cómo proteger el intercambio; cada protocolo debía especificarlo. La operación de uri.arpa. y urn.arpa. añadía riesgos de disponibilidad, suplantación y delegación. Incluso DNS validado no demostraba que la respuesta de aplicación fuera auténtica o que el recurso fuera el previsto.

Las expresiones regulares requerían revisión antes de ejecución. Una regla auténtica podía ser peligrosa si se entregaba sin control a un entorno capaz de ejecutar código. Procedencia y seguridad de interpretación seguían siendo pruebas distintas.

El RFC Editor registra tres erratas editoriales. Las verificadas 282 y 787 corrigen referencias al procesamiento de información Additional: debían apuntar a RFC 3403 y no a RFC 3404. La 2923, retenida para una futura actualización, corrige números de referencia en la sección 4. Ninguna modifica Services, Flags ni cardinalidades.

Un recibo operativo completo guardaría la entrada canónica, esquema o espacio de nombres, primera clave, consulta DNS, conjunto NAPTR, decisión sobre indicadores, protocolo, servicio pedido y cardinalidad, selección dentro del mismo ORDER, regla elegida, entrega S/A/U/P, consulta o URI siguiente, codificación de la solicitud, par autenticado, tipo de contenido, clase del objeto devuelto y resultado consumido.

El principio de especificación inicial mínima de Lu Heng explica el diseño: fijar con precisión lo compartido y permitir que protocolos particulares evolucionen localmente. La primacía del código operativo propone la prueba: pedir ubicación, recurso y descripción del mismo identificador; retirar Additional; introducir un indicador desconocido; variar las capacidades del mismo ORDER. Solo deben cambiar los resultados que el contrato autoriza.

RFC 3404 no prometía que cada URI ofreciera toda respuesta imaginable. Exigía decir qué se pedía y por qué frontera avanzaba el proceso. Así, «resuelto» dejaba de ser una luz verde vacía y pasaba a ser una afirmación auditable.

Fuentes