Resumo

  • O corpo da RFC 1097 diz especificar um padrão para a comunidade da Internet. Hoje, o RFC Editor registra o documento como Unknown no Independent Stream, e o IETF Datatracker informa que ele não tem posição formal no processo de padronização do IETF.
  • A opção satírica começava desativada. DO/WILL precisava estabelecer a concordância dos terminais antes da subnegociação de mensagem, duração e frequência. Esse estado pertencia ao cliente Telnet, não à decisão informada do usuário.
  • O cliente devia apenas tentar uma exibição cujo lugar e cuja forma dependiam da implementação. Receber os parâmetros não provava luz na tela, atenção humana, persuasão, atualização ou conduta.

O documento podia fazer uma afirmação, não conceder a si mesmo autoridade

A RFC 1097 tem a aparência familiar de uma especificação: Network Working Group, autor B. Miller, CMU-NetDev, data de 1º de abril de 1989, comandos, padrão inicial, motivação e exemplos. Sua seção de status afirma que o texto especifica um padrão para a comunidade da Internet. A opção SUBLIMINAL-MESSAGE recebe o número 257.

Isso registra o que o memorando disse. A classificação cabe a outra superfície. A página atual do RFC Editor mostra status Unknown e Independent Stream. O IETF Datatracker acrescenta que a publicação não foi endossada pelo IETF e não possui posição formal em seu processo de padrões.

O corpo e o catálogo não são versões concorrentes do mesmo campo. Um preserva o objeto histórico; o outro informa a autoridade institucional que lhe foi atribuída. Se a autodescrição bastasse, qualquer documento poderia produzir seu próprio título normativo.

Preservar uma sátira não a transforma em regra da rede

Ao contar cinquenta anos da série, a RFC 8700 descreve os RFCs de 1º de abril como uma parte humorística especial do Independent Stream, sem o processo formal comum de revisão e aprovação, embora escolhida e revista para essa finalidade.

RFC 1097 depende desse contraste. Ela trata “Use VMS”, “Go home”, o brilho do fósforo e um LED de Caps Lock com o vocabulário metódico de uma opção real. O arquivo confirma que o texto foi publicado e preservado. Não confirma que cada texto preservado seja um Internet Standard.

A série sempre reuniu materiais com funções diferentes. Confundir publicação com força normativa apaga precisamente a variedade que o arquivo foi criado para manter.

Até a mensagem subliminar precisava negociar entrada

O esqueleto técnico vem do Telnet verdadeiro. A RFC 854 define uma comunicação bidirecional orientada a bytes, com o NVT como base comum e opções propostas entre as duas pontas. Uma ponta pode aceitar ou rejeitar; uma opção desconhecida pode ser recusada sem destruir a sessão.

A RFC 855 divide opções parametrizadas em duas fases. DO/WILL estabelece que a conversa pode ocorrer. Só depois a subnegociação leva dados. DON'T/WON'T encerra a capacidade.

RFC 1097 segue essa estrutura. WILL pede permissão ou confirma disposição para exibir; WON'T recusa. DO pede que o outro lado exiba ou lhe concede permissão; DON'T exige que não exiba. O estado padrão é WON'T/DON'T: nenhuma mensagem.

O servidor, portanto, não adquire a tela só por existir uma conexão. Primeiro precisa obter do cliente uma capacidade limitada e revogável. A negociação não resolve a questão humana, mas mantém separadas a solicitação e a autoridade técnica adquirida.

O número 257 ficava além da tabela comum

O registro atual da IANA mostra o espaço ordinário das opções Telnet até 255. Esse último valor pertence a Extended-Options-List; não existe hoje uma linha 257 para SUBLIMINAL-MESSAGE.

A RFC 861 fornece o contexto. EXOPL, no código 255, foi criado para abrir outro conjunto de 256 opções por meio de negociação encapsulada. RFC 1097 escolhe 257, mas seus exemplos permanecem na notação simbólica IAC DO/WILL/SB SUBLIMINAL-MESSAGE e não expõem o enquadramento EXOPL.

É seguro dizer que o número foi colocado logo após o espaço convencional, ao lado de um mecanismo real de extensão. Não é seguro inventar um registro IANA, bytes observados ou interoperabilidade. O número impresso e a atribuição oficial são provas diferentes.

A concordância aconteceu entre programas

Depois de DO/WILL, o emissor fornecia dois valores de 16 bits e uma cadeia. Um definia a duração em milissegundos; o outro, o intervalo em segundos. O cliente deveria aceitar a subnegociação e tentar exibir imediatamente e de modo repetido. Posição e renderização ficavam sob decisão local. Um byte 255 era duplicado conforme a regra de escape do Telnet.

Os exemplos substituem uma mensagem por outra e usam dois zeros mais cadeia vazia para parar. A motivação diz que avisos comuns não persuadiam usuários a atualizar o Telnet e cita REMOTE-FLOW-CONTROL. A verdadeira RFC 1080 havia descrito essa opção 33 pouco antes, também exigindo DO/WILL antes de comandos de controle.

Mas o sujeito que “concordou” em RFC 1097 é o cliente. O documento não descreve explicação ao usuário, escolha do conteúdo ou autorização da finalidade. Um padrão automático, um administrador ou o autor do programa poderia produzir WILL. Um estado de protocolo não se converte sozinho em consentimento humano.

O emissor decide conteúdo e tempo; o cliente decide como renderizar; a pessoa controla a própria atenção, mas nem aparece no handshake. Chamar tudo isso de “o usuário aceitou” desloca a decisão para o ator errado.

A tentativa ainda estava longe de qualquer resultado humano

A subnegociação pode comprovar a chegada de parâmetros. Um registro local pode comprovar que uma rotina foi chamada. Outra observação é necessária para confirmar que a tela realmente produziu um pulso visível. Depois ainda seria preciso saber se alguém estava presente, olhando, percebeu, interpretou e agiu.

O memorando afirma que uma implementação da CMU ajustava o tempo à velocidade da linha, aos recursos de vídeo e à persistência do fósforo, e que outra usaria código morse no LED Caps Lock. Como as frases pertencem à sátira, elas são evidência do que o texto alegou, não de software distribuído ou efeito observado.

A sequência correta é: texto arquivado, status oficial, capacidade negociada, parâmetros recebidos, tentativa local, apresentação física, percepção, persuasão e ação. Cada avanço precisa de uma prova nova.

Fontes