Resumo

  • O RFC 1043 registrou em 1988 a implementação DODIIS da opção TELNET Data Entry Terminal. No eco remoto descrito pelos autores, uma tecla podia gerar um datagrama de ida e outro de volta.
  • DET permitia editar campos desprotegidos no terminal. Aplicação e terminal negociavam os recursos compartilhados, trocavam a vez com GO-AHEAD e podiam devolver apenas campos “modificados”, inclusive os marcados assim pela própria aplicação.

Uma letra viajava com bagagem demais

A abertura do RFC 1043 descreve um pequeno desperdício repetido milhares de vezes. Um caractere digitado seguia ao host num datagrama com cabeçalhos TCP/IP; o host mandava de volta outro datagrama para ecoá-lo. A Defense Intelligence Agency desenvolvia acesso a aplicações de tela cheia através de uma rede de comutação de pacotes. O texto relatava DET implementado em IAS, MVS, OS86 e UNIX, com trabalho em VM e VMS em andamento. Sistemas diferentes precisavam apresentar um formulário reconhecível ao usuário. Consultar um host distante para cada toque do teclado era uma maneira cara de preencher uma linha.

A opção de terminal de entrada de dados existia desde o RFC 732. O problema de RFC 1043 veio depois: organizações DODIIS haviam construído implementações independentes, e ninguém queria descobrir tarde demais que elas não conversavam entre si. O ganho de tráfego de um formulário incompatível logo viraria despesa de suporte. Por isso o documento descreveu o mínimo comum, as funções extras negociáveis e a passagem de controle entre os dois lados.

O aparelho imaginado era semidúplex e orientado a formulários. Sua tela retangular tinha dados protegidos e campos desprotegidos onde o usuário escrevia. O teclado editava localmente; teclas de função e seleção de campos ofereciam outras respostas. A tela padrão tinha 80 caracteres por linha e 24 linhas, e o host do usuário devia suportar páginas de 24 a 48 linhas. A aplicação montava campos com posição, tamanho, atributos e conteúdo. Quando a ficha ficava pronta, enviava GO-AHEAD, liberando o teclado. A pessoa preenchia, concluía ou acionava uma função; o terminal devolvia os dados e outro GO-AHEAD. O cursor era passado como bastão numa corrida de revezamento.

Antes do formulário, vinha a negociação de DET. Era a opção TELNET de número 20, acertada nos dois sentidos com DO e WILL. Sem acordo, o padrão era WONT DET -- DONT DET, mantendo a conexão no modo de terminal virtual de rede. O RFC pedia que Echo, Suppress Go-Ahead e Binary fossem recusados ou encerrados ao entrar em DET, por entrarem em conflito com suas regras. Um velho eco de caractere ligado ao lado de um novo esquema de turnos faria a tela receber instruções desencontradas.

Mesmo dentro de DET, recursos adicionais precisavam de consentimento técnico específico. Quatro subcomandos de facilities anunciavam edição, limpeza, transmissão e formatação. O terminal indicava o que tinha; a aplicação indicava o que queria. O conjunto utilizável era a interseção lógica dos dois mapas. A intensidade visual ficava no menor nível oferecido. Um recurso opcional só entrava em uso depois da negociação e podia ser retirado por qualquer ponta. Bits reservados saíam zerados, impedindo que um recurso futuro fosse aceito sem querer.

O texto ainda mandava lembrar qual lado iniciou cada conversa de negociação; computadores educados demais podem passar o dia respondendo um ao outro.

O retorno do formulário mostrava a economia. A aplicação podia pedir a tela inteira, só campos desprotegidos ou só campos modificados por meio de TRANSMIT-SCREEN, TRANSMIT-UNPROTECTED e TRANSMIT-MODIFIED. Sem pedido explícito, atributos Modified e Protection já negociados definiam a menor resposta permitida. O formulário permanecia na tela e a aplicação podia ajustá-lo para a próxima rodada. As teclas trabalhavam perto da pessoa; os campos completos viajavam na hora combinada.

Havia uma armadilha no termo “modificado”. Em TRANSMIT-MODIFIED, o terminal devia devolver tanto os campos alterados de fato pelo usuário quanto aqueles marcados com o atributo Modified. Uma resposta contendo certo campo podia refletir uma marca do projeto do formulário. Para descrever o que a pessoa fez, era preciso conhecer essa regra. O RFC colocou o detalhe numa caixa de cautela, quase um bilhete de agradecimento ao futuro analista de bugs.

O conjunto mínimo de comandos DET, usado sem negociação extra, não bastava para todos os formulários DODIIS. Hosts de usuário deveriam implementar os subcomandos especificados e atributos disponíveis no hardware ou fáceis de emular por software. Servidores implementariam o que suas aplicações exigissem. Uma tabela distribuía quem envia e quem recebe cada comando. O objetivo era cooperação entre máquinas diferentes, com as diferenças à vista.

O RFC 1043 substituiu uma procissão de ecos por uma ficha compartilhada. Primeiro as duas pontas combinavam o que sabiam fazer; depois a pessoa editava localmente e o terminal devolvia os campos certos. O silêncio na rede nascia de um acordo muito claro entre máquinas que não precisavam ser iguais.