Resumo

  • A RFC 1096 definiu X-DISPLAY-LOCATION como a opção Telnet 35. WILL e DO apenas liberavam a discussão posterior; o valor aparecia em uma resposta IS solicitada por SEND.
  • O localizador seguia <host>:<dispnum>[.<screennum>]. O cliente Telnet precisava adaptar atalhos locais como :0, mas essa mudança não autenticava o host, não provava posse e não testava a rota.
  • O aplicativo remoto ainda abria uma conexão X separada e enfrentava os controles de acesso e autorização do servidor X. Receber o endereço, passar pelo setup e produzir uma janela visível eram fatos diferentes.

O shell remoto não conhecia a tela local

O usuário executava um cliente Telnet dentro do ambiente X, entrava em outro computador e iniciava ali um aplicativo gráfico. O processo remoto conhecia o próprio host, mas não necessariamente o display diante do usuário. Faltava-lhe uma coordenada que o ambiente local normalmente fornecia sem explicação.

A RFC 1096, Proposed Standard de março de 1989, atribuiu o código 35 à opção X Display Location. O servidor Telnet poderia pedir ao cliente o local do display sob o qual ele rodava. O registro de opções Telnet da IANA mantém essa atribuição.

A solução não carregava gráficos pelo Telnet. Ela entregava uma indicação para que um segundo protocolo tentasse o próprio caminho. A continuidade vista na mesa do usuário escondia dois fluxos e uma passagem de contexto entre eles.

A negociação permitia falar, não entrar

O padrão é WON’T/DON’T. Pela RFC 854, WILL e DO negociam o comportamento de uma opção. Na RFC 1096, WILL sinaliza disposição para fornecer depois um local; DO sinaliza disposição para recebê-lo.

O documento restringe o significado: os comandos só obtêm e concedem permissão para discussão futura. A RFC 855 organiza a subnegociação em duas etapas, primeiro o acordo e depois o parâmetro entre SB e SE. As formas negativas encerram a possibilidade.

Uma resposta positiva comprova estado entre pares Telnet. Ela não consulta o servidor X, não confirma quem controla o display e não torna o endpoint alcançável. Consentir em fornecer um endereço não é consentir em usar o recurso.

SEND e IS controlavam a iniciativa

Somente quem enviou DO pode emitir SEND; somente quem enviou WILL pode responder com IS. O local não pode ser anunciado sem pedido. Assim, disponibilidade geral e divulgação efetiva continuam separadas.

O desenho vem da RFC 1079, a opção Telnet Terminal Speed. A RFC 1096 reutilizou a sequência solicitada de SEND/IS. O formato de conversa era familiar, mas a natureza do valor não: uma localização X aponta para um serviço com política própria.

No exemplo, IS contém SRI-NIC.ARPA:0.0 em NVT ASCII, e a subnegociação mede 22 octetos. Esse recebimento comprova que o par declarou a cadeia. Não comprova que um servidor X a reconheceu.

Reescrever :0 mudava o ponto de vista

A forma Unix DISPLAY é <host>:<dispnum>[.<screennum>], sem espaços ou caracteres extras. Localmente, :0 e unix:0.0 podem omitir o host porque “aqui” é inequívoco. No computador remoto, “aqui” apontaria para outro lugar. O cliente Telnet precisa tornar a localização adequada antes de transmiti-la.

Essa é uma conversão de escopo. A RFC não diz que ela autentica o nome, valida DNS, testa a rota, abre a porta ou demonstra que o display pertence ao usuário. Uma string correta pode estar desatualizada; uma localização exata pode estar inacessível; um serviço alcançável pode recusar a conexão.

O localizador reduz atrito. Não reduz as verificações posteriores a uma só.

A conexão X começava depois

A RFC 1013 descreve um cliente X estabelecendo uma conexão IPC independente com o servidor. Em TCP, o display N corresponde à porta 6000+N. O host e o número recebidos podem orientar essa tentativa.

O fluxo Telnet não se transforma em X. A opção 35 não é túnel, proxy nem encaminhamento, e não transporta pedidos de desenho. O aplicativo remoto inicia um novo caminho, sujeito a nome, rota, filtros, listener e estado próprios.

Se IS chegou e o TCP falhou, o localizador foi entregue mesmo assim. Se o TCP conectou e o setup X foi rejeitado, a rede chegou mais longe do que a autorização. Preservar esses marcos evita o diagnóstico impreciso de “Telnet não funcionou”.

O servidor X mantinha a decisão de acesso

O setup X inclui nome e dados de um protocolo de autorização. O servidor pode devolver um motivo de falha ou aceitar e apresentar informações de telas, formatos e recursos. A RFC 1013 deixa a escolha do mecanismo válido fora do protocolo central.

Ela também descreve uma lista de controle de acesso por hosts. Esses controles pertencem ao servidor X e não são herdados de DO/WILL. A negociação Telnet permite a entrega do destino; X decide se admite o cliente que chega depois.

No registro atual da IANA, X Display Location é a opção 35 e Telnet Authentication é a opção 37. A classificação ajuda a não chamar 35 de autenticação, mas não prova que uma combinação posterior estivesse presente em uma implantação de 1989.

A evidência forma uma escada: opção negociada, string entregue, endpoint alcançado, setup aceito, recurso criado, janela observada. Cada degrau responde a uma pergunta e tem um controlador. Pular degraus transforma conveniência em alegação sem fonte.

Aceitação ainda não era experiência do usuário

Depois do setup, o aplicativo precisa criar recursos, enviar operações e mapear a janela certa. O servidor deve processá-las; a janela deve permanecer utilizável; o usuário deve vê-la. O setup aceito prova a conexão, não todo esse resultado.

Essa separação é a herança útil da RFC. Ela resolveu um problema específico sem alegar autenticação, criptografia, política de acesso, encaminhamento ou renderização. Um contrato estreito permite dizer exatamente onde o sistema chegou.

O registro IANA também não é censo de uso. Ele mostra número e referência, não mercado, comportamento de um host nem resultado de uma pessoa. A história apoiada pelas fontes é a do mecanismo e de seus limites.

O endereço atravessou o Telnet. O direito de usar o display continuou pertencendo ao X.

Fontes