Resumen

  • RFC 1107 planteó un programa de tres etapas para un directorio de personas de Internet y del National Research Network; el texto aclara que la comunidad no había comprometido esa actividad de investigación.
  • La propuesta empezaba con pruebas comparativas y limitadas, antes de implementar y preparar un despliegue amplio. La calidad de los datos, la autoridad sobre los nombres, los permisos y los clientes seguían sin resolverse.

En una guía impresa, la búsqueda por apellido es la parte visible. Detrás están la recopilación de datos, las correcciones y el control de quién consulta cada dirección. Las “White Pages” de RFC 1107 trasladaban ese trabajo a las redes: permitirían encontrar personas y datos útiles para contactarlas, desde buzones electrónicos hasta calendarios o servidores de archivos. Las “Yellow Pages” tenían otra función: localizar recursos mediante atributos. No se trataba de convertir el DNS de máquinas en una lista de empleados.

Karen Sollins publicó “A Plan for Internet Directory Services” en julio de 1989 para documentar una reunión de dos días celebrada en febrero. Un grupo reducido reunió perspectivas académicas, comerciales y gubernamentales. Los participantes consideraron factible un servicio en tres años si contaba con financiación y apoyo suficientes. Sin embargo, el aviso de estado del RFC es inequívoco: el documento se ofrecía a debate y no representaba una actividad de investigación ya comprometida por la comunidad de Internet. El plazo era una previsión condicionada, no prueba de presupuesto aprobado, lanzamiento o despliegue.

La arquitectura debía decidirse después de aprender, no antes. X.500 parecía la opción más probable por la riqueza de sus conceptos y su creciente condición de norma internacional. A la vez, seguía incompleto y su jerarquía estricta generaba reservas. La primera etapa proponía comparar al menos una implementación X.500 —Quipu era la más madura para participar entonces— con Profile y DNANS, el servicio de nombres de DEC. Profile exploraba nombres descriptivos sin exigir un único árbol jerárquico; DNANS aportaba diseños para control de acceso, replicación y caché.

Incluir una segunda implementación X.500 ayudaría a distinguir los límites del estándar de los de un programa concreto.

Para que esa comparación fuera válida, las pruebas necesitaban una base común. RFC 1107 recomendaba un formato compartido para los datos recogidos y herramientas comunes de gestión, de forma que los sistemas pudieran trabajar con entradas comparables. El ensayo debía revelar cómo reunir y corregir información, distribuirla y replicarla, limitar lecturas y modificaciones, proteger su integridad, diseñar interfaces y soportar distintas pilas de protocolos. El plan sugería empezar con un entorno acotado y familiarizado con el problema; para DNANS proponía una comunidad que ya se preparaba para DECnet.

Un piloto así podía generar experiencia controlada, pero no demostrar que las organizaciones aceptarían las mismas reglas.

Las proyecciones de escala explican el problema de pasar del piloto al servicio. El RFC estimaba diez millones de usuarios de ciencia e investigación y unas diez consultas semanales por persona: 10^8 a la semana, alrededor de 170 por segundo como promedio y picos mucho mayores. También pedía capacidad para al menos 10^7 entradas y consideraba necesaria una solución distribuida con varios servidores. Son hipótesis para orientar el diseño, no métricas de un sistema en producción. Una búsqueda amplia podía encarecerse con el tamaño total del directorio; la caché, la distribución de los datos y el ritmo de actualización afectarían al rendimiento.

Si las personas encontraban contactos desactualizados, la corrección técnica de la respuesta no salvaría la confianza.

El calendario colocaba las pruebas en el primer año, la implementación en el segundo y el despliegue amplio en el tercero. Las fases, no obstante, debían empezar cuanto antes y solaparse. La implementación podía elegir un servicio o combinar funciones útiles observadas en los ensayos. Después harían falta servidores fiables e interfaces distintas para personas y programas. La reunión no elaboró los detalles de despliegue: recopilar y mantener registros, ubicar servidores, distribuir y enseñar el uso de los clientes, administrar la operación y delegar autoridad sobre partes del espacio de nombres y su contenido.

Ese último conjunto de tareas revela que un directorio también reparte autoridad. ¿Quién crea una rama para una organización, decide dónde se aloja o corrige la ficha de una persona? RFC 1107 reconoce que las instituciones podían rechazar la delegación de sus nombres y que personas o empleadores podían limitar el acceso a datos de personal. Al mismo tiempo, un directorio amplio debía permitir búsquedas que cruzaran esas fronteras. La interoperabilidad pedía reglas comunes; la confianza requería registros actualizables, permisos y control cercano a quienes aportaban la información.

RFC 1107 documenta un plan de trabajo serio, no el resultado de su ejecución. Su aportación fue convertir la idea de un directorio de Internet en pruebas, decisiones y responsabilidades concretas, situando los datos y la gestión junto a los protocolos. Tres años solo podían ser plausibles si cada etapa encontraba responsables, recursos y evidencia de que sus supuestos se cumplían. El propio documento no ofrece el registro posterior de esa ejecución.

Fuentes