Resumen

  • RFC 3402 hizo que cada regla de reescritura operara sobre la misma Application Unique String, incluso cuando el resultado no terminal servía como clave para recuperar otro conjunto ordenado de reglas.
  • La norma separó el objeto de la ruta: una delegación podía cambiar el lugar de la consulta, pero no podía convertir una salida intermedia en el nuevo sujeto de todas las decisiones posteriores.

Una cadena de reescrituras parece intuitiva porque imita una línea de montaje. La primera regla cambia una expresión, la segunda recibe lo que quedó y la tercera continúa. El problema aparece al investigar el resultado: después de varias etapas, nadie sabe si la última autoridad resolvió el objeto inicial o una identidad accidental fabricada por las transformaciones anteriores.

RFC 3402 diseñó DDDS para evitar ese desplazamiento. El documento, publicado en octubre de 2002 dentro de la vía de estándares, era la segunda parte del Dynamic Delegation Discovery System. Describía un mecanismo de vinculación tardía en el que una aplicación entregaba una Application Unique String, abreviada AUS, y el cliente recorría reglas obtenidas dinámicamente hasta hallar una salida terminal.

La palabra «reescritura» no significaba que cada salida sustituyera a la entrada. Cuando una regla no era terminal, su sustitución generaba la clave con la que se buscaba el siguiente conjunto de reglas. Nada más. La siguiente expresión volvía a aplicarse sobre la AUS exacta que había iniciado el proceso. El RFC lo prohibía de forma normativa y obligaba a cada especificación de aplicación a preservar la misma separación.

La ruta empezaba con una First Well Known Rule definida por la aplicación. No se descargaba de la base y no surgía de una inferencia del cliente. Su función era producir la primera clave válida a partir de la AUS. Ese anclaje importaba porque el formato que una base acepta no basta para demostrar que la aplicación estaba autorizada a empezar allí.

Una consulta devolvía reglas en un orden definido. El cliente probaba las expresiones de sustitución contra la AUS hasta obtener un resultado no vacío. Después interpretaba Services, Flags y Priority. El resultado léxico, el servicio ofrecido, la condición terminal y la preferencia eran pruebas diferentes; una coincidencia no convertía automáticamente la regla en una opción utilizable.

Si el cliente rechazaba el servicio de una regla que había coincidido, continuaba en la misma lista a partir de la posición siguiente. No reiniciaba la lista ni ocultaba el rechazo. Esta mecánica permitía construir un recibo fiel: qué regla coincidió, por qué no se aceptó y en qué índice se reanudó la evaluación.

Al aceptar una regla no terminal, el cliente comprobaba que la sustitución produjera una clave permitida por la base correspondiente. Una expresión regular defectuosa podía crear una clave ilegal. La validación impedía convertir una cadena sintácticamente plausible en una consulta arbitraria; tampoco autorizaba a usarla como nueva AUS.

El RFC describió la alternativa acumulativa como una forma frágil y propensa a errores, semejante a ciertas cadenas de reescritura de sendmail. La razón no era estética. Si cada salida se vuelve sujeto, un error temprano cambia el significado de todas las reglas posteriores. Cuando el sujeto permanece fijo, cada autoridad puede ser auditada por separado: se reproduce su expresión contra la misma entrada y se evalúa su salida como clave o como término.

Había una salida explícita del contexto. Un Flags podía suspender la aplicación DDDS y entregar el procesamiento a otra aplicación o a una regla específica del protocolo. RFC 3404 daba como ejemplo el indicador p. Sin embargo, ese salto declaraba el cambio. No permitía que las reglas de la aplicación anterior siguieran funcionando mientras fingían que una clave intermedia era todavía el sujeto original.

Una regla terminal devolvía el resultado previsto por el contrato de la aplicación junto con Services y Flags. «Terminal» solo describía el estado del algoritmo. No certificaba la disponibilidad posterior, la legitimidad del editor de la regla ni el éxito del consumidor. Un valor final sin la cadena de autoridad era una respuesta sin procedencia.

Priority también tenía límites claros. Expresaba preferencia entre reglas equivalentes, por ejemplo una alternativa mejor, más rápida o más barata. RFC 3402 negó expresamente que fuera un mecanismo de balanceo de carga. Si una aplicación necesitaba distribuir tráfico, debía usar el mecanismo adecuado, como SRV cuando correspondiera, y conservar ese acto como otra capa de decisión.

La caducidad protegía la continuidad temporal. Un cliente podía recordar claves y reglas previas para optimizar, siempre que respetara la semántica de expiración de la base. Si una regla usada antes había vencido, el algoritmo volvía al primer paso. Combinar una parte antigua con otra actual habría creado una ruta que nunca existió en un solo momento.

Por eso DDDS no era un algoritmo autosuficiente. La especificación de la aplicación debía definir la AUS, la primera regla, las bases aceptables, el tratamiento de caracteres y la forma de salida. La especificación de la base debía definir almacenamiento, consulta, formato de claves y reglas, inserción y prevención de colisiones. RFC 3401 advirtió que leer una sola parte de la serie podía producir incompatibilidades.

El diseño también rechazaba falsas omnisciencias. A partir de la AUS y una regla podía derivar delegación. No podía decidir hechos externos como la hora, un pago, un derecho o una transacción. Si una política dependía de ellos, debía existir una prueba fuera del algoritmo en lugar de disfrazarse como otra sustitución.

La seguridad solo se volvía concreta al combinar aplicación y base. RFC 3403 describía la base DNS y NAPTR; RFC 3404, la resolución de URI; RFC 2916, el antecedente de ENUM. Eran aplicaciones relacionadas, no prueba de que cualquier cliente DDDS entendiera todas las variantes ni de que toda regla publicada fuera confiable.

El registro de servicios ENUM de IANA muestra una coordinación vigente de identificadores en una aplicación posterior. El alta de un servicio no demuestra ejecución, frescura, autoridad, terminación correcta ni disponibilidad. El RFC Editor enumera hoy una sola errata editorial verificada para RFC 3402, la 7049: la referencia a la explicación del indicador p en RFC 3404 debe señalar la sección 4.3 y no la 4.4. La corrección no afecta el principio central.

La evidencia operativa debe conservar la AUS, aplicación y versión, First Well Known Rule, tipo de base, claves sucesivas, conjuntos ordenados completos, identidad y vigencia de cada regla, coincidencia y sustitución, rechazo de servicio y punto de reanudación, decisión de prioridad, indicador terminal, validación del formato esperado y resultado del consumidor.

La especificación inicial mínima de Lu Heng explica por qué el documento evitó dictar una solución universal: fijó la frontera mínima que dos implementaciones debían compartir y dejó que aplicaciones y bases declararan su propia semántica. La primacía del código en ejecución exige la contrapartida empírica: reproducir la ruta y demostrar que ninguna salida intermedia ocupó el lugar del objeto.

RFC 3402 conservó una distinción que los sistemas distribuidos olvidan con facilidad. Delegar autoridad no equivale a delegar identidad. Las claves podían cambiar en cada etapa y conducir a otra base; la pregunta profunda seguía siendo la misma. Cada regla reescribía el camino. Ninguna podía reescribir aquello sobre lo que el camino debía responder.

Fuentes