Resumo

  • A RFC 779 definiu uma opção para o programa Telnet do usuário enviar ao host remoto uma localização em caracteres imprimíveis, mais precisa que o nome da instituição de origem.
  • O caminho tinha decisões separadas: opção desligada por padrão, oferta do cliente, aceitação do servidor, envio do texto e eventual uso no cadastro de pessoas conectadas.

Um colega podia consultar o computador para saber onde você estava em 1981. A máquina talvez mostrasse seu nome e o lugar físico do terminal. Para uma sessão vinda de outro centro, muitas vezes restava apenas o nome do centro. “Procure naquele prédio” não é um número de telefone. Earl Killian propôs na RFC 779 uma opção de Telnet que permitia ao programa do usuário fornecer uma descrição de sua localização ao servidor distante.

A utilidade vinha da rotina dos sistemas compartilhados. A RFC 742, que descrevia NAME/FINGER, previa uma lista de usuários ativos com nomes completos e locais físicos de seus terminais quando fosse possível determiná-los. Podiam aparecer também o nome da tarefa e o tempo de inatividade. Com esse dado, alguém encontrava um colega no prédio ou telefonava para perto de sua mesa. O login pela rede quebrava a precisão: o servidor via o site de origem da conexão, mas não a sala específica.

Killian chamou a opção de SEND-LOCATION e lhe deu o número 23. O estado inicial não ativava o envio em nenhum dos lados. Se o cliente conhecesse o local, podia anunciar WILL SEND-LOCATION. Um servidor disposto a recebê-lo respondia DO SEND-LOCATION. Depois, o cliente transmitia uma sequência de caracteres ASCII imprimíveis numa subnegociação entre IAC SB e IAC SE. Era uma descrição vinda do lado do usuário. Cabia ali o tipo de indicação útil naquele ambiente, sem que o protocolo precisasse localizar alguém por conta própria.

Os verbos também permitiam recusar. WON'T era a recusa do emissor; DON'T era a exigência do outro lado para não enviar. O servidor podia pedir o dado com DO, e o cliente podia negar. Uma vez acordada a opção, o texto podia chegar mais tarde durante a sessão. Oferecer, aceitar e entregar eram acontecimentos diferentes. A informação passava pela negociação, não apenas pelo fato de a pessoa ter se conectado.

A RFC 734 sobre SUPDUP já tinha um comando para mandar ao servidor um texto com a localização do console. O servidor normalmente o guardava para mostrar quando alguém perguntava who. SEND-LOCATION levou uma finalidade parecida para o conjunto de opções de Telnet. Nos dois casos, a origem próxima da pessoa conhecia o texto, e o computador distante o recebia para tratar segundo suas próprias regras.

NAME/FINGER descrevia o relatório de pessoas conectadas; SEND-LOCATION oferecia uma fonte de dados para o caso das sessões Telnet. A RFC 779 mencionava sistemas ITS capazes de aproveitar o campo. O servidor ainda precisava decidir o que colocar na lista. Receber uma frase e mostrá-la a outras pessoas eram passos diferentes, separados pelo programa que administrava a página de usuários.

A pequena opção mexia com algo bastante humano. Um nome e uma instituição apontavam para um campus inteiro. Uma indicação de sala ou telefone podia levar a uma conversa imediata. Ela também podia chegar à lista consultada por outros usuários do sistema. A RFC 779 distribuiu a escolha: o cliente oferecia o texto, o servidor decidia como o utilizaria. O terminal remoto deixava de ser apenas uma origem de caracteres e ganhava uma pista sobre a pessoa diante dele.