Resumen

  • RFC 3981 diseñó un núcleo IRIS que no bastaba por sí solo: los esquemas específicos tenían que definir consultas, resultados y clases de entidades, y otra capa se ocupaba del transporte, la autenticación y las sesiones.
  • El cliente universal fue una promesa rechazada de forma consciente. Un formato común podía transportar un lookup, pero no convertía una consulta en útil, soportada, autorizada ni comprensible sin conocimiento del registro.

Imagine un cliente con una sola caja de texto y un selector que promete consultar cualquier registro de Internet. El usuario escribe parte de un nombre, combina dos campos y espera que el mismo gesto funcione en todas partes. En un servicio, la búsqueda existe; en otro, ese índice no tiene sentido; en un tercero, el operador la ha limitado porque consume demasiados recursos. La interfaz sigue siendo común. La capacidad que insinuaba, no.

Ese problema ocupa el centro intelectual de RFC 3981, la especificación de enero de 2005 para el núcleo XML de IRIS, Internet Registry Information Service. Su ficha oficial, el registro de erratas y el historial de Datatracker sitúan el documento en Standards Track y registran la actualización posterior de RFC 4992. No dicen cuántos servidores llegaron a existir ni cuánto se utilizó el protocolo.

El texto presenta una arquitectura de tres capas. Abajo, cada tipo de registro define sus consultas, resultados y clases de entidades. En medio, IRIS aporta conjuntos de búsqueda y resultados, referencias y una forma común de identificar el tipo. Arriba —o, mejor dicho, fuera de esa semántica—, un transporte de aplicación resuelve autenticación, intercambio de mensajes, conexiones, sesiones y sintaxis URI. El acuerdo en el sobre no transfería al núcleo la autoridad sobre el contenido ni sobre el canal.

La especificación reconoce sin rodeos que su esquema básico contiene un tipo de consulta, dos tipos de resultado independientes y ninguna estructura de registro. Por eso tiene una utilidad limitada cuando está solo. No es una carencia que deba rellenarse con suposiciones del cliente. Es el hueco reservado para los esquemas concretos. RFC 3982, junto con su estado documental, define el tipo de registro de dominios. RFC 4698 hace lo propio para registros de direcciones. Ninguno de esos significados estaba oculto dentro del núcleo.

La frontera se entiende mejor al separar lookup de búsqueda. El lookup toma un valor discreto y lo contrasta con un índice. La operación común lookupEntity identifica tipo de registro, clase y nombre de entidad. Una búsqueda por valores parciales, por varios índices o mediante varias consultas sobre un índice es otra cosa. RFC 3981 no impuso una lengua estándar para todas esas búsquedas; cada tipo tenía que declarar las que correspondían a sus datos y a su servicio.

Así aparece el “señuelo del cliente universal”. Un programa genérico podía emitir el lookup y mostrar de forma elemental la respuesta. Para formular una búsqueda amable o explicar el resultado necesitaba conocer el dominio. Una lengua común no eliminaba ese conocimiento: obligaba a traducir la intención del usuario a un mínimo denominador, al tiempo que el propio usuario seguía necesitando saber qué relaciones tenían sentido.

La objeción no era solamente elegante teoría de modelos. Los registros de interés público debían defender la disponibilidad. Una búsqueda flexible, con coincidencias parciales cruzadas entre índices, servía tanto al investigador experto como al usuario abusivo. El operador probablemente desactivaría las variantes costosas, y la supuesta universalidad ofrecería funciones que dejarían de funcionar en los lugares donde más importaban. RFC 3707 y su ficha conservan los requisitos CRISP sobre búsqueda, referencias distribuidas, versiones y abuso que precedieron este diseño. Son antecedentes normativos, no mediciones de ataques o rendimiento.

También importaba qué demostraba una respuesta. Una referencia de entidad expresaba conocimiento específico sobre otra entidad. Una continuación de búsqueda indicaba que otra autoridad podía conducir a lo buscado, a algo distinto o a nada. El cliente debía seguir cada una solo una vez para no entrar en un bucle. Recibir el enlace no probaba que el destino estuviera disponible, que fuera la autoridad final o que devolviera un resultado.

El catálogo de errores impedía confundir sintaxis con éxito. invalidName señalaba la forma del nombre; invalidSearch, el significado de la búsqueda; queryNotSupported, la capacidad del servidor; limitExceeded, el límite permitido; nameNotFound, la ausencia en el índice elegido; y permissionDenied, la falta de autorización para recibir la entrada. Un XML válido podía contener una petición inútil, no soportada, demasiado cara o no autorizada.

La independencia del transporte completaba el dibujo. RFC 3983 y su estado llevaron IRIS sobre BEEP. Más tarde, RFC 4992, documentada además en su ficha, sus erratas y Datatracker, actualizó RFC 3981 con XPC, un transporte TCP que fragmentaba y canalizaba XML. Sustituir encuadre o gestión de sesión no reescribía la semántica del registro.

El registro de esquemas URI de IANA conserva iris y esquemas relacionados; el registro XML del IETF conserva el espacio iris1. Eso prueba registros protocolarios persistentes, no un despliegue vivo, una consulta satisfactoria ni una explicación causal de lo que vino después.

La aportación histórica de RFC 3981 fue negarse a confundir una articulación común con una mente común. Normalizó cómo podían encontrarse sistemas distintos y dejó que cada uno siguiera diciendo qué significaban sus datos. La incompletitud era la disciplina que hacía posible esa convivencia.

Sources