Resumen

  • La RFC 779 permitió que un cliente Telnet ofreciera al servidor una ubicación escrita por el lado del usuario, útil cuando el sistema remoto solo conocía el sitio de origen.
  • La opción empezaba apagada: primero había oferta, luego aceptación, después el texto y, finalmente, la decisión del servidor sobre cómo mostrarlo.

En 1981, «está en el otro laboratorio» podía ser toda la ayuda que daba una computadora para encontrar a un colega. Para llamar a la persona, aún quedaba un edificio por recorrer. Earl Killian propuso en la RFC 779 una pequeña ampliación de Telnet: que el programa desde el cual se conectaba el usuario enviara al servidor una descripción de su ubicación. El ordenador remoto podría tener un dato más preciso que el nombre de la institución de origen.

La idea nacía de una costumbre de los sistemas compartidos. La RFC 742, sobre NAME/FINGER, explicaba cómo devolver listas de personas conectadas, con sus nombres completos y, cuando podía determinarse, el sitio físico de sus terminales. También podían aparecer el trabajo en curso o los minutos de inactividad. Esa información servía para acercarse a la consola de alguien o llamar a un teléfono próximo. Una sesión llegada por la red dejaba un hueco: el servidor conocía de dónde venía la conexión, pero ignoraba qué mesa ocupaba la persona dentro del sitio remoto.

SEND-LOCATION, la opción Telnet número 23, llenaba el hueco mediante negociación. Su estado inicial era de rechazo en ambos sentidos. Si el cliente conocía la ubicación del usuario, podía ofrecerla con WILL SEND-LOCATION. El servidor, si podía utilizarla, contestaba DO SEND-LOCATION. Entonces el cliente enviaba caracteres ASCII imprimibles dentro de una subnegociación marcada por IAC SB al inicio y IAC SE al final. Era una frase o descripción aportada desde el lado del usuario. El protocolo no necesitaba un mapa para llevarla.

Los comandos también permitían negarse. WON'T expresaba el rechazo a enviar; DON'T exigía que el otro extremo dejara de hacerlo. El servidor podía solicitar el dato con DO, y el cliente podía decir que no. Tras el acuerdo, el texto podía llegar en cualquier momento de la sesión. Ofrecer, aceptar y transmitir eran hechos distintos. La ubicación entraba al sistema remoto por esa secuencia, no por el mero acto de iniciar sesión.

La RFC 734 de SUPDUP ya describía una orden para enviar texto con la ubicación de la consola. Normalmente el servidor lo guardaba para mostrarlo al consultar quién estaba conectado. Killian llevó una función parecida a la negociación de Telnet. La diferencia importante no era una nueva capacidad para adivinar dónde vivía alguien, sino una forma explícita de pasar al servidor un texto que el lado del usuario conocía.

NAME/FINGER indicaba qué podía aparecer en un informe de usuarios. SEND-LOCATION describía una vía para alimentar ese informe en el caso de Telnet. La RFC citaba sistemas ITS capaces de aprovechar el dato. El servidor decidía cómo tratarlo y mostrarlo. Un texto recibido no recorría por sí solo el último paso hasta una pantalla ajena. Allí intervenían las prácticas y el programa del sitio que recibía la conexión.

El cambio tenía una apuesta social pequeña y reconocible. Una lista que mostraba solo el laboratorio de origen ayudaba poco a encontrar a una persona. Un texto más preciso podía señalar una habitación o un teléfono. También podía circular en una lista que otras personas del sistema consultaran. La RFC 779 repartió las decisiones entre quien proporcionaba la descripción y quien la exhibía. Dos páginas bastaron para introducir un dato humano en la conversación entre terminales.

Telnet llevaba caracteres de una sesión remota. Esta opción recordaba que detrás de los caracteres había alguien sentado en algún sitio, quizá esperando que un compañero pudiera encontrarlo sin llamar a todas las puertas del edificio.