Resumen

  • En 1977, NAME/FINGER permitía pedir a un sistema remoto una lista de usuarios conectados o información sobre una persona concreta.
  • Una consulta mínima podía devolver nombres, ubicación de terminales, inactividad, última salida o una nota escrita por el usuario.

Una línea vacía ya era una pregunta

En uno de los ejemplos de RFC 742, la persona buscada ni siquiera ha iniciado sesión. Aun así, la respuesta incluye el plan que dejó escrito: cuenta cuándo suele ser imposible localizarla, cuándo se conecta desde casa y cómo contactarla. La ausencia también se había vuelto información consultable. Ese detalle cambia el sentido de la petición que parece más inocua: bastaba un retorno de carro y un salto de línea para preguntar por quienes usaban el sistema. Según la instalación, podía incluir nombres completos, tareas activas, cuánto llevaba una terminal sin actividad y dónde estaba situada.

Una búsqueda por nombre podía ir más allá de la sesión: mostrar la última hora de salida y un mensaje que la persona había dejado.

La red compartía el acceso, no una respuesta uniforme

Eso antecede a las páginas de perfil, pero no era una versión temprana de una página web. La consulta se conectaba con información que cada equipo ya sabía producir sobre sus cuentas y terminales. El RFC 742 de Ken Harrenstien describe una sola línea de comando y no exige un formato de respuesta. Cada sitio decidía cómo convertir sus datos locales en texto. La pregunta podía viajar entre máquinas; la representación de la persona seguía dependiendo del sistema que la alojaba.

De FINGER a una pregunta que cruza la red

El documento cuenta una cadena de adaptación. El programa FINGER de Les Earnest en SAIL inspiró NAME en el sistema ITS del MIT. Earl Killian en MIT y Brian Harvey en SAIL implementaron el protocolo original; después se puso en marcha un servidor parecido en SRI. El RFC nombra esos tres lugares, pero no ofrece una cifra de adopción para el resto de la red.

Los ejemplos muestran por qué “estado en línea” es una descripción demasiado estrecha. Una salida registra consolas y trabajos en curso. Otra dice que alguien no ha iniciado sesión y publica su plan: dónde estará, cuándo podrá responder y cómo localizarlo. Ningún sitio tenía que ofrecer todos esos datos. Aun así, los ejemplos prueban que la misma respuesta podía mezclar señales del sistema con información redactada expresamente por una persona.

La primera especificación conserva el vocabulario de su entorno técnico. RFC 742 describe el acceso al socket 117 en octal —puerto 79 decimal— mediante ICP y dos conexiones de 8 bits. En 1984, RFC 924 catalogó Finger como protocolo electivo y señaló que hacían falta cambios para TCP. Su resumen seguía poniendo en el centro la actividad actual o más reciente de un usuario.

En junio de 1990, el acta de una reunión IAB/IETF mantuvo provisionalmente RFC 742 como Proposed Standard heredado y encargó conseguir un documento mejor para volver a examinarlo. RFC 1194 apareció en noviembre. Buscó aclarar el intercambio sin romper las implementaciones existentes, muchas derivadas de BSD Unix. También describió la información de usuarios como sensible y trató decisiones sobre rechazo de consultas, archivos accesibles, programas ejecutables y auditoría.

Las decisiones de rechazo y auditoría que RFC 1194 incorporó en 1990 permiten releer los ejemplos de 1977: NAME/FINGER no definía una ficha universal, sino que dejaba a cada host convertir datos locales en una respuesta. Por eso, hacer consultable a una persona a través de la red no obligaba a publicar siempre la misma información. El administrador podía decidir qué mostrar, mientras el usuario podía añadir un plan sin vetar necesariamente los datos que generaba el sistema. La revisión de 1990 no resolvió esa tensión; la convirtió en una cuestión de operación.

Fuentes primarias