Resumen

  • En WHOIS++, el servidor podía devolver registros o SERVER-TO-ASK; el cliente convertía esas referencias en nuevas consultas.
  • Como un servidor podía participar en varias jerarquías, la malla admitía ciclos y el cliente debía conservar el conjunto de servidores ya visitados.
  • Ampliar elevaba el posible alcance, pero también podía elevar exponencialmente los recursos y los cobros; detenerse era una decisión editorial y operativa sobre la evidencia.

El cero abría otra ronda

El intercambio básico de RFC 1914 terminaba pronto: conectar, preguntar, recibir, cerrar. Sin embargo, el significado de la respuesta quedaba abierto. Si había registros, el cliente podía mostrarlos. Si había referencias, tenía que analizar el host, el puerto y el identificador del servidor y decidir si iniciaba otra conexión.

Cuando no aparecían coincidencias, el cliente podía consultar polled-by y polled-for. Así conocía servidores con una vista más amplia o relaciones adicionales y volvía a enviar la pregunta original. El protocolo no decía que un cero local fuese ausencia global. Lo trataba como una razón posible para expandir.

La diferencia importa porque el conjunto final no era producido por una sola autoridad. Cada servidor de base controlaba sus registros. Los servidores de índice controlaban el conocimiento adelantado y las referencias. El cliente controlaba qué bordes del grafo se convertían en tráfico real.

La amplitud podía crecer más deprisa que la utilidad

RFC 1914 fue explícito sobre el coste. Seguir referencias sin límites podía provocar un crecimiento exponencial del consumo de recursos. También señaló que algunas partes de la malla aplicaban cobros por respuesta. Una consulta aparentemente sencilla podía transformarse en una serie de transacciones con precio.

Por eso no recomendó una expansión automática ciega. Un cliente más sofisticado debía permitir cortar ciertos servidores, incluso porque uno de ellos fuese demasiado caro. La persona debía poder abandonar una operación larga. La interfaz de cancelación formaba parte del gobierno de la búsqueda.

Estas reglas impedían una definición ingenua de exhaustividad. Seguir una rama más podía aumentar el recuerdo. También podía repetir información, llegar a un servicio lento o disparar el presupuesto. Detenerse pronto preservaba recursos, pero reducía lo que podía afirmarse sobre lo ausente.

El bucle se rompía con memoria local

Los servidores no formaban necesariamente un árbol. Una sede sueca podía ser indexada por la jerarquía nacional y por la sede mundial de la empresa. Los enlaces cruzados acortaban algunas búsquedas, pero también abrían caminos que regresaban a nodos conocidos.

La arquitectura dejó la detección y eliminación de bucles enteramente al cliente. El algoritmo ilustrativo mantenía QueriedServers, AnswerList, OriginalServers y una lista de servidores pendientes. Antes de consultar, comprobaba si el servidor ya figuraba entre los visitados. La estabilidad dependía de una memoria que no estaba dentro de la malla.

Una captura del último resultado no conserva esa historia. Para auditar una búsqueda se necesitan el punto inicial, las referencias recibidas, el orden de recorrido, los duplicados evitados, los fallos y la condición que cerró la lista. Sin ello, dos clientes con la misma consulta pueden parecer contradictorios cuando en realidad recorrieron grafos diferentes.

Cercano no quería decir geográficamente limitado

El documento recomendaba configurar un servidor inicial lo más local posible. Esa cercanía podía reducir latencia o coste. No limitaba los registros del índice. Un servidor situado en Estados Unidos podía incluir personas de Suecia porque había sondeado otra rama.

Si la búsqueda debía quedar en un país, la condición tenía que estar en la consulta. La ubicación del servidor era una propiedad del punto de entrada; el país solicitado era semántica de la pregunta. Confundir ambos podía producir resultados inesperados y, peor aún, una falsa explicación de por qué aparecieron.

La misma distinción alcanza a cualquier resumen distribuido. La topología por la que llega una respuesta no determina automáticamente el ámbito administrativo, jurídico o geográfico del dato devuelto.

El directorio especial también necesitaba configuración

RFC 1914 describió un Directory of Servers para ayudar a elegir dónde empezar. Publicaba registros de navegación con un Server-Handle, el nombre de host y el puerto actuales, además de descripciones. Pero el propio host y puerto de ese directorio tenían que estar preconfigurados.

La ayuda para descubrir servidores no eliminaba el problema de arranque. Desplazaba una pequeña parte a una dirección conocida. En aquel momento, el texto recomendaba presentar las opciones al usuario en vez de seleccionar automáticamente un servidor en función de la consulta.

El identificador estable también servía para reparar una referencia envejecida. El nombre o la IP en SERVER-TO-ASK podía proceder de un sondeo de semanas atrás. Si la conexión fallaba, el cliente consultaba el handle y recuperaba el último endpoint conocido. Eso mostraba continuidad de identidad administrativa, no disponibilidad actual.

El centroide era una promesa comprimida

RFC 1913 explicaba cómo un índice podía orientar sin copiar la base. Un centroide contenía nombres de plantillas y atributos, y una lista sin duplicados de las palabras observadas en cada atributo. Si una palabra de la consulta aparecía, el servidor subyacente podía merecer una pregunta.

El resumen no mostraba el registro. Tampoco aseguraba que dos palabras estuvieran juntas en una misma ficha, que el registro siguiera presente o que su afirmación fuera correcta. La inferencia válida era pequeña: «aquí puede haber material relevante».

Una cadena probatoria necesita conservar la versión del centroide, el índice que la usó, la referencia generada, el endpoint alcanzado y la respuesta de la base. Saltar del token a la verdad del registro elimina precisamente las capas que hacían escalable el sistema.

Una lista negra no era un sello de confianza

El documento advirtió que podían aparecer servidores WHOIS++ falsos y propuso que el cliente tuviera una lista negra. Esa lista expresaba rechazo local. No convertía en autenticado todo lo demás. Un servidor fuera de la lista podía ser nuevo, desconocido o estar comprometido.

La confianza seguía un recorrido distinto del descubrimiento. El índice decía dónde preguntar. El Directory of Servers daba una dirección conocida. DNS resolvía un nombre. La red entregaba una conexión. El servicio remoto ofrecía su respuesta y su marco de autenticación. El cliente tenía que registrar qué evidencia aceptó en cada salto.

CIP defendió el control que parecía carga

RFC 2651 llevó el modelo al Common Indexing Protocol. Reconoció que el trabajo difícil parecía caer sobre el cliente, pero señaló el reverso: quien recorría también controlaba profundidad, velocidad y tamaño del conjunto. Rechazó una raíz única por razones de escala y mantuvo la importancia del punto de entrada.

RFC 2968 examinó más tarde mallas de servicios DAG en TISDAG. Era un documento informativo, no una prueba de adopción global. Junto con CIP muestra que el problema continuó evolucionando: compartir índices evitaba reunir todos los datos en un único lugar, pero exigía acuerdos de formato, semántica, seguridad y referencia.

Publicado en febrero de 1996, RFC 1914 figura hoy como Historic y WNILS como grupo concluido. Esos hechos no aportan una curva de uso ni una fecha exacta de desaparición. Sí permiten leer el diseño como una pieza histórica completa: descentralizar el índice no descentralizó mágicamente la responsabilidad por una afirmación de ausencia.

La búsqueda negativa necesitaba recibos

Para sostener que no se encontró algo, habría que conservar la consulta exacta, el servidor inicial, todos los bordes descubiertos, los centros de índice, handles, resoluciones, edades de caché, conexiones fallidas, ciclos evitados, exclusiones, coste, tiempo y decisión de parada.

Sin esos recibos, el vacío puede significar que el primer servidor no tenía ficha, que el centroide no tenía el término, que la referencia caducó, que la red falló, que una rama era cara, que un nodo ya había sido visitado o que la persona canceló. RFC 1914 puso en el cliente la capacidad de distinguirlos; con ella llegó la obligación de explicar hasta dónde buscó.

Fuentes