Resumo

  • O RFC 1408 publicou VAR=0 e VALUE=1 para a opção Telnet 36; o RFC 1571 registrou que a implementação BSD de referência usava os dois significados ao contrário.
  • O RFC 1571 tentou identificar o dicionário do par por formas proibidas, posição, marcadores vazios, contagens e nomes reconhecíveis. Alguns fluxos continuavam ambíguos.
  • O RFC 1572 manteve o mapeamento escrito e o colocou na nova opção 39, NEW-ENVIRON. Mesmo após uma decodificação inequívoca, cabia ao servidor ignorar, substituir ou aplicar a entrada.

Um número não carregava a história do parser

Publicado em janeiro de 1993, o RFC 1408 criou um meio de transportar informações de ambiente na abertura de uma sessão Telnet. ENVIRON recebeu a opção 36. A subnegociação usava IS=0, SEND=1 e INFO=2; dentro da carga, VAR=0, VALUE=1, ESC=2 e USERVAR=3 separavam nomes, valores e bytes literais.

A diferença entre zero e um definia a árvore sintática. Sem VALUE depois de um nome, a variável era indefinida. Com VALUE seguido imediatamente de outro tipo ou do fim, a variável existia, mas continha uma cadeia vazia. Um ambiente sem entradas também era resposta válida. Inverter os marcadores alterava onde o nome terminava e o valor começava.

O RFC 1571 descreveu o problema em janeiro de 1994: as definições de VAR e VALUE no RFC 1408 estavam invertidas em relação à implementação BSD. O memorando chamou BSD de implementação de referência que o RFC deveria ter documentado e de base para muitas implementações existentes.

Isso não é uma medição de mercado. Não informa quantos sistemas estavam em cada lado. Mas delimita a incompatibilidade real: a opção 36 já possuía duas linhagens. O número negociado identificava o assunto, não o dicionário instalado.

O protocolo transportava contexto sem possuir o contexto

Sistemas operacionais guardavam informações de inicialização que podiam ser úteis no host remoto. Criar uma opção Telnet para cada item teria transformado o protocolo em um inventário de detalhes locais. ENVIRON ofereceu uma moldura genérica.

Os nomes bem conhecidos eram USER, JOB, ACCT, PRINTER, SYSTEMTYPE e DISPLAY. USERVAR levava pares arbitrários propostos pelo usuário. Essa diferença registrava a classe de origem; não certificava a informação. O RFC reconhecia que uma implementação desconfiada poderia tratar ambas as classes com igual cautela e deixava colisões de nomes para a política local.

O padrão era não trocar dados: WONT ENVIRON, DONT ENVIRON. O lado disposto a enviar anunciava WILL; o disposto a receber, DO. Apenas o emissor de DO podia iniciar SEND; apenas o emissor de WILL podia responder com IS ou comunicar alterações por INFO.

O desenho separava disponibilidade, pedido e efeito. WILL não comprovava transmissão. SEND não comprovava existência. IS atendia ao pedido inicial. INFO podia surgir espontaneamente para mudanças posteriores, mas não substituía a primeira troca. Nenhum desses registros mostrava que o host receptor adotara o conteúdo.

Chegar antes do login aumentava a necessidade de filtro

Muitos sistemas só propagavam o ambiente ao criar um processo. Por isso, a informação costumava chegar no início da conexão, antes de o usuário entrar. O momento útil era também o momento perigoso.

O RFC 1408 deixou o servidor livre para não inserir todas as variáveis no ambiente. Ele podia rejeitar um nome desconhecido, usar USER ou ACCT numa decisão de login sem copiá-lo para o processo, ou preferir uma fonte mais exata.

O exemplo de TERM tornou o limite operacional. Se Terminal-Type já tivesse determinado o tipo do terminal, o servidor poderia ignorar USERVAR TERM=xterm. No caso de conflito entre DISPLAY e a opção X-Display-Location, o RFC escolheu a informação recebida mais recentemente. O mecanismo comum expunha as entradas; a resolução permanecia no destino.

Assim, USER era o nome de conta desejado pelo cliente, não prova de identidade. PRINTER apontava para um local cujo formato nem sequer tinha uma convenção de rede única; não provava permissão nem impressão. DISPLAY não provava conexão X, tela criada ou percepção humana.

A seção de segurança exigia análise cuidadosa das variáveis aceitas antes da autenticação. Uma escolha que alterasse o programa de login poderia permitir contorno ou comprometimento. O documento não relatava um ataque específico. Ele separava o dado remoto da autoridade local que poderia dar consequência ao dado.

A mensagem impossível denunciava o dicionário

Como a opção 36 não trazia uma versão de gramática, o RFC 1571 examinou a forma dos fluxos.

Para o cliente, SEND só podia conter VAR e USERVAR. Encontrar o marcador que seu próprio mapa chamava VALUE significava que o servidor provavelmente usava a ordem invertida. O cliente passaria a inverter a leitura no restante da solicitação e ao gerar IS ou INFO. Se zero e um não aparecessem, faltava evidência; a regra era assumir a definição publicada.

No servidor, IS e INFO podiam conter valores. Um VAR logo depois do comando indicava a ordem do RFC; um VALUE, a invertida. Quando a primeira entrada era USERVAR, os dois marcadores podiam ocorrer legalmente em posições diferentes. Restava procurar repetições impossíveis, marcadores vazios, comparar quantidades e testar se certas cadeias pareciam nomes bem conhecidos.

Essas heurísticas classificavam uma convenção histórica. Não autenticavam o par e não validavam o conteúdo. Uma forma proibida sob uma leitura oferecia evidência forte; um nome familiar oferecia só probabilidade. Quando nada discriminava, o parser adotava o RFC por política padrão.

Guardar apenas a dupla final elimina o caminho da decisão. Um registro auditável incluiria bytes originais, opção, sentido, estado da negociação, versão do parser, regra acionada, mapa escolhido e dúvida restante.

O 39 criou futuro sem fingir que apagava o 36

O RFC 1572 preservou VAR=0 e VALUE=1, mas sob a opção 39, NEW-ENVIRON. O novo número, dizia o texto, permitia que as implementações interoperassem sem ambiguidade.

Repetir a tabela sob o número 36 não revelaria qual binário remoto estava instalado. O número 39 funcionou como seletor de uma gramática única. A correção não conquistou o passado; ofereceu uma camada comum mínima para adoção futura.

O registro de opções Telnet da IANA mantém as duas entradas: 36 para Environment Option, com RFC 1408, e 39 para New Environment Option, com RFC 1572. O registro conserva a história. Não demonstra implementação, sessão, variável aplicada ou resultado.

NEW-ENVIRON continuou desligado por padrão e negociado por direção. O receptor continuou autorizado a preferir outra fonte ou não aplicar a entrada. A sintaxe ganhou um significado comum; a decisão futura não saiu do host.

A prova não terminava no decodificador

A cadeia precisa distinguir: atribuição publicada; dicionário do emissor; bytes enviados; interpretação do receptor; heurística escolhida; par candidato; classe de origem; política de aceitação; criação de processo; ambiente observado; ação externa.

O RFC não reescreveu software. Um WILL não provou um IS. Um USER decodificado não autenticou alguém. Aceitar não comprovou herança pelo processo. Herdar não comprovou execução. O efeito final precisava de sua própria observação.

Fontes

As fontes sustentam a gramática, o relato contemporâneo do conflito BSD, as heurísticas, o número novo e o registro. Não sustentam uma implementação nomeada, participação de mercado, ataque, identidade, login aceito, ambiente aplicado, comando executado ou risco atual.