Resumo

  • O RFC 884, de dezembro de 1983, reservou o código 24 para a opção Telnet TERMINAL-TYPE. DO e WILL abriam a conversa; SEND pedia o nome e IS o entregava.
  • O terminal podia apresentar uma designação específica e depois uma mais ampla. Repetir o último nome encerrava a lista. Em 1985, o RFC 930 resolveu uma confusão de mensagens cruzadas ao exigir que IS só respondesse a SEND.

Há uma pequena tragédia da computação antiga que cabe inteira numa tela: o programa desenha uma interface elegante; o terminal remoto interpreta os comandos como outra coisa; o usuário recebe um emaranhado de caracteres. A rede cumpriu sua parte, mas o computador do outro lado desconhecia o aparelho físico. Mover um cursor não era um gesto universal. Algumas máquinas nem tinham uma tela onde o cursor pudesse fazer pose.

O protocolo Telnet começava por um terminal virtual de rede, uma representação comum para equipamentos diferentes. Era suficiente para iniciar a conversa sem que cada host carregasse uma enciclopédia dos periféricos alheios. A aplicação que quisesse cores ou endereçamento de cursor, porém, precisava conhecer melhor o visitante. Marvin Solomon e Edward Wimmers propuseram no RFC 884 um cartão de visitas para o terminal.

A opção recebeu o número 24. Com DON'T e WON'T, seu estado inicial, não circulava informação sobre o modelo. Um lado enviava DO, o outro aceitava com WILL, e a porta se abria. O pedido efetivo vinha depois, no subcomando SEND, código 1. A resposta IS, código 0, carregava uma cadeia de caracteres NVT ASCII. No exemplo da especificação, ela dizia IBM-3278-2. Letras maiúsculas e minúsculas tinham o mesmo valor para comparar o nome.

A lista sugerida pelos autores passeava por terminais IBM, máquinas conhecidas em sistemas TOPS20 e equipamentos do ambiente Unix. DEC-VT100 e TELETYPE-33 dividiam o documento. É uma fotografia das pontas heterogêneas da Internet de então: a mesma conexão chegava a aparelhos com repertórios de saída radicalmente distintos. Saber o nome permitia entregar a um driver local a escolha de comandos apropriados, inclusive recursos além do terminal virtual básico, quando o software os conhecia.

Nomes também tropeçam na grafia. O RFC observou que IBM3278-2 e IBM-3278/2 poderiam atrapalhar duas máquinas que julgavam falar do mesmo tipo. Não havia uma mensagem especial de rejeição para um nome que o servidor não reconhecesse. Em vez disso, o terminal podia oferecer sucessivamente uma designação precisa e outra mais genérica. O servidor perguntava de novo; o visitante descia um degrau na especificidade. Para indicar o fim das alternativas, repetia o último nome. Duas respostas iguais em sequência eram o sinal para parar. Até um computador ganha bons modos quando aprende a perguntar: “Você atende por outro nome?”

O nome fornecia uma pista ao servidor, não uma transformação instantânea da sessão. Um processo local podia usá-lo para selecionar tratamento de tela e, com a opção BINARY, chegar a funções como cursor e cores. Se o aparelho fosse desconhecido ou dificilmente reconhecido, UNKNOWN era uma resposta prevista. O controle do comportamento continuava nas mãos da implementação que recebia e compreendia o nome.

Os bons modos de 1983 precisaram de uma correção. Depois de DO e WILL, o RFC 884 deixava o lado do terminal mandar IS espontaneamente. Os autores imaginavam, no pior caso, informação repetida se um SEND saísse ao mesmo tempo. Em janeiro de 1985, o RFC 930 mostrou a ambiguidade: uma resposta antecipada pode cruzar o pedido, e o próximo IS parecer o segundo nome da lista. A regra passou a exigir pergunta antes de resposta.

O RFC 1091 ampliou o jogo em 1989 para clientes capazes de alternar entre modos de emulação. A cena de 1983 era mais simples e mais divertida. O servidor queria desenhar melhor na tela de alguém. Primeiro, precisava saber como chamá-la; depois, descobrir se ela também tinha um apelido que ele entendesse.