Resumo

  • A opção TERMINAL-SPEED do RFC 1079 separava a permissão negociada, o pedido posterior e a declaração de velocidade do terminal.
  • A resposta podia informar uma escolha local de tela, mas não demonstrava um fato sobre a rota nem autorizava mudanças em TCP, roteamento ou política de serviço.

Um número que não era uma sonda

Terminais físicos e modems diretamente conectados tinham ritmos que importavam para o software. Sistemas operacionais guardavam a taxa de bits desses dispositivos para controlar processos de exibição dependentes de tempo, como caracteres de padding; alguns programas ofereciam interfaces diferentes para terminais rápidos e lentos. Essa é a questão concreta de RFC 1079. O texto não propõe que Telnet descubra o estado da rede.

9600,100 pode parecer uma medição, mas no RFC é uma cadeia NVT ASCII fornecida por um participante, com representações decimais da velocidade de transmissão e recepção do terminal. Ela não é uma amostra de vazão, um relatório de roteador, uma medida de perda ou uma promessa de entrega TCP. Um valor pode ser bastante útil para uma decisão de apresentação e ainda ser insuficiente para qualquer conclusão sobre o enlace.

Primeiro consentir, depois pedir

RFC 854 dá a Telnet o Network Virtual Terminal como representação comum e usa WILL, WON'T, DO e DON'T para negociar convenções adicionais. RFC 1079 aplica esse mecanismo à opção 32. O padrão é nenhum intercâmbio: WON'T TERMINAL-SPEED e DON'T TERMINAL-SPEED.

WILL diz apenas que um par aceita enviar informação depois; DO diz que outro aceita recebê-la. Nenhum deles é a informação. Depois dos dois, somente quem enviou DO TERMINAL-SPEED pode solicitar IAC SB TERMINAL-SPEED SEND IAC SE; somente quem enviou WILL TERMINAL-SPEED pode responder com IAC SB TERMINAL-SPEED IS ... IAC SE. A resposta não pode ser espontânea.

O valor é uma dupla decimal de velocidades de transmissão e recepção, separada por vírgula, sem zeros iniciais ou caracteres extras. A forma estreita facilita interpretação compatível. Ela não autentica o terminal, não confirma o modem, não mede o percurso nem assegura que a tela chegou ao leitor.

A resposta local permanece local

RFC 1079 reconhece que alguns sistemas aceitam apenas velocidades discretas. Ele sugere escolher o valor permitido mais próximo numa direção segura; para padding, arredondar para cima pode ser melhor do que colocar pouco padding. Essa é uma sugestão para a decisão local do programa. Não manda alterar a linha, reservar capacidade, configurar roteador ou controlar congestionamento.

O software pode preservar a cadeia original, registrar o valor que escolheu e voltar a perguntar mais tarde. Assim fica auditável a diferença entre uma característica fornecida e o efeito que o programa decidiu produzir. RFC 930, citado como modelo, usa a mesma separação para tipo de terminal e esclarece que transmitir informação não implica imediatamente mudar o processamento.

O que a resposta deixa em aberto

Receber 1200,1200 sustenta apenas que um participante enviou esses caracteres na gramática prevista. Não prova velocidade física, sincronismo de modem, capacidade do caminho TCP, ausência de perda, leitura da tela, identidade, autorização ou êxito de uma ação. Também não demonstra uso atual de Telnet em uma rede identificada.

O erro seria inflar uma pista de sessão em medição, e a medição alegada em mandato de política. RFC 1079 cobre só a pista de terminal solicitada. Cada conclusão maior precisa de observação e autoridade próprias.

Fontes e fronteira de evidência

RFC 1079 fornece motivação, comandos, padrão, sintaxe e sugestão local; RFC 854 fornece NVT e o quadro de negociação; RFC 930 é a comparação histórica; RFC 1123 situa o RFC 1079 entre referências Telnet. O conjunto não prova implantação presente, implementação nomeada, capacidade, desempenho, identidade, autorização ou resultado de aplicação.