Resumo

  • A RFC 1073 permitiu ao cliente informar largura e altura em células de caracteres e repetir a informação após uma mudança local. O servidor podia aceitar o NAWS, ignorar os valores ou proibir novas atualizações depois.
  • DO/WILL concedia permissão para usar a opção; a subnegociação de quatro octetos registrava uma declaração do cliente. Atualizar o terminal remoto, sinalizar o processo filho, recompor a saída e mostrá-la a uma pessoa eram fatos independentes.

O Telnet começou por uma abstração mínima. Seu Terminal Virtual de Rede não tinha largura de impressão nem comprimento de página determinados. Essa falta de detalhes permitia que máquinas diferentes se encontrassem em um modelo comum. Quando o cliente passou a morar dentro de uma janela gráfica redimensionável, porém, a aplicação remota precisou de uma informação que o NVT deliberadamente não carregava.

A RFC 1073 atribuiu o código 31 ao NAWS, Negotiate About Window Size. O avanço central não foi aumentar o limite numérico. Foi reconhecer a origem correta da autoridade: o cliente tinha controle total sobre sua janela; o servidor podia pedir uma descrição, aceitar a conversa e decidir localmente se a usaria.

O acordo autorizava a gramática, não o efeito

O servidor podia enviar DO NAWS; o cliente disposto respondia WILL NAWS. DON'T e WON'T preservavam a recusa. A RFC 855 separava essa negociação inicial da subnegociação específica de cada opção. Primeiro as partes confirmavam que entendiam a extensão; só depois vinham os dados ricos.

Daí surge uma regra de evidência. DO/WILL prova um estado de permissão. Não prova que a geometria foi enviada. A chegada do NAWS prova que certos octetos alcançaram o interpretador Telnet. Não prova que o servidor os armazenou, que o terminal local mudou, que o filho recebeu um sinal ou que a aplicação refez a tela.

O corpo do NAWS continha dois octetos de largura e dois de altura, na ordem da Internet, com unidade em caracteres. Cada eixo chegava a 65.535. Como o Telnet reservava 255 para IAC, um 255 dentro desses dados precisava aparecer duplicado. Portanto, a medida lógica só existia depois de delimitar corretamente a subnegociação e remover o escape.

Zero não significava uma janela sem colunas ou sem linhas. Significava que aquele eixo não estava sendo informado. O servidor escolheria uma hipótese dependente do sistema operacional, talvez auxiliada pelo tipo de terminal recebido por outra opção. O protocolo mantinha o desconhecido visível em vez de inventar um número.

Uma nova medida não confirmava a anterior

No exemplo da RFC, a janela começa em 80 × 24 e depois passa a 80 × 64. O cliente envia outra subnegociação sem repetir DO/WILL. A mudança local cria uma nova geração de estado, e a opção já habilitada serve para anunciá-la.

Esse segundo valor não é uma confirmação de que o primeiro foi aplicado. O NAWS não define uma resposta dizendo que o processo remoto já reorganizou sua saída. O ambiente gráfico, o cliente, o servidor e a aplicação podem manter gerações diferentes por algum tempo. Perguntar “qual é o tamanho?” sem nomear o dono e o instante esconde essa defasagem.

O texto chama a informação de consultiva. Um servidor podia aceitar a opção e não usar os valores. Alguns sistemas operacionais não permitiam alterar o tamanho durante a sessão. Neles, o servidor podia mandar DON'T NAWS depois da aceitação inicial e impedir novos relatórios sem formar um laço de negociação. Isso fechava o canal de atualização; não congelava a janela do cliente.

O modelo anterior atribuía controle demais ao servidor

NAOL e NAOP tentavam tratar separadamente largura de linha e tamanho de página. A RFC 1073 considerou suas semânticas inadequadas para janelas: eram bidirecionais, sugeriam que o servidor poderia controlar dimensões do cliente, limitavam cada eixo a 253 e tinham pouco uso segundo o registro contemporâneo.

O NAWS enviava largura e altura juntas porque janelas mudam como retângulos. Mais importante, trocou “negociar o tamanho” por “informar o tamanho atual”. O servidor podia negociar a recepção, mas não redimensionava a janela local por essa opção.

Os valores eram células de caracteres. O exemplo de 300 × 24 não prova uma tela física muito larga, resolução, pixels ou escala. Qualquer conversão para essas grandezas exigiria fonte, densidade e renderização que o protocolo não descrevia.

Tipo, velocidade e geometria não eram sinônimos

A RFC 930 definiu o TERMINAL-TYPE: o servidor solicitava e o cliente respondia; receber o nome não implicava mudança imediata de processamento. A RFC 1091 depois permitiu percorrer vários modos de emulação, ainda sob solicitação do servidor. Tipo descrevia capacidade ou escolha, não media a janela corrente.

A RFC 1079 reservou o código 32 para velocidade. Depois do acordo, o solicitante pedia uma cadeia ASCII com taxas de transmissão e recepção; o outro lado não a enviava espontaneamente. Valores não suportados podiam ser arredondados em direção segura. No NAWS, depois do acordo, o cliente anunciava por iniciativa própria cada nova geometria, em dois eixos binários.

O tipo poderia orientar uma largura presumida quando o NAWS enviasse zero. Isso não o transformava em medição. A velocidade poderia orientar preenchimento ou interface, mas não colunas. Manter essas opções independentes protegia a origem e o prazo de validade de cada fato.

O registro de opções Telnet da IANA associa 31 ao NAWS e 32 ao TERMINAL-SPEED. A entrada demonstra atribuição do identificador e referência documental. Não comprova implementação atual, conformidade de produto ou uso numa sessão específica.

A geometria atravessava várias decisões locais

A sugestão de implementação da RFC percorre uma cadeia inteira. O sistema de janelas avisa o cliente Telnet. No 4.3BSD, o cliente pode capturar SIGWINCH. Ele envia NAWS. O servidor pode usar ioctl para atualizar seu terminal e então pode sinalizar o processo filho, provavelmente um shell.

Cada verbo condicional pertence a um componente diferente. Um NAWS válido não garante o ioctl. O estado atualizado não garante a entrega do sinal. O sinal não garante que a aplicação o processe antes da próxima saída. Uma saída bem quebrada em linhas tampouco prova que uma pessoa a viu.

Por isso, investigar uma tela desalinhada exige comparar o evento local, os octetos brutos, o desescape, a geometria armazenada, o sinal ao filho e o valor consultado pela aplicação. Um único campo “resize OK” elimina justamente a informação necessária para localizar a falha.

Fontes e limites

A RFC 1073 registra uma proposta de 1988 e uma experiência contemporânea em Carnegie-Mellon; não mede adoção universal. As RFCs 854 e 855 definem a moldura do Telnet. As RFCs 930, 1079 e 1091 documentam atributos vizinhos, sem provar aplicação do NAWS. O registro IANA não prova tráfego nem comportamento de software.

Também não é preciso alegar descendência direta para pseudoterminais SSH, layouts web responsivos ou desktops remotos. O feito histórico é mais preciso: uma condição local mutável ganhou uma forma portátil sem virar uma ordem remota. A janela continuou do cliente; a reação continuou do servidor.