Resumo

  • O Network Virtual Terminal definiu uma gramática mínima entre máquinas diferentes: CR LF fazia nova linha, CR NUL fazia apenas o retorno de carro e CR isolado ficava fora do NVT ASCII padrão.
  • O segundo byte encerrava uma decisão que o primeiro não conseguia carregar; cada ponta podia verificar a ação e traduzi-la para sua convenção local.
  • A RFC 1123 esclareceu a tecla Enter, Binary retirou o processamento de fim de linha e Net-Unicode manteve CRLF enquanto passou a desaconselhar CR NUL.

Quando não agir era a informação

Na impressora do NVT, CR leva a posição de escrita à margem esquerda da linha atual. LF desce para a próxima linha sem mudar a coluna. CR seguido de LF produz a função combinada: início da linha seguinte.

Os terminais reais não partilhavam essa mecânica. Alguns separavam os movimentos, outros os acoplavam; sistemas operacionais usavam CR, LF, ambos ou registros que não dependiam desses caracteres. Se o receptor executasse CR imediatamente, poderia aplicar LF depois como outra operação. Se esperasse, precisava saber como terminava um retorno de carro solitário.

A RFC 318 propôs em 1972 que o receptor segurasse CR até examinar o caractere seguinte. LF selecionava nova linha. Para selecionar só retorno de carro, o emissor usava CR NUL. Como NUL era uma no-operation para a impressora, ele não adicionava movimento; ainda assim, concluía a sintaxe.

Não se tratava de preencher espaço. Naquele ponto, NUL provava que o CR não esperava um LF.

Uma representação intermediária, não um terminal universal

A RFC 854 estabeleceu o Network Virtual Terminal como estado inicial de uma conexão Telnet. Cada host convertia o dispositivo ou processo local para um repertório comum e fazia a conversão inversa na recepção. Não precisava conhecer toda a máquina remota.

O centro compartilhado permanecia estreito. NUL não movia a impressora; LF movia verticalmente; CR voltava à margem. Largura, paginação, buffering e regras do sistema operacional continuavam locais.

Para o caso ambíguo, porém, a norma era obrigatória. CR LF devia ser tratado como um único caractere de nova linha; CR NUL representava retorno de carro isolado; CR devia ser evitado em outros contextos no NVT ASCII padrão. A regra valia nas duas direções.

Ao receber CR NUL, Telnet removia NUL antes de mapear a ação para o conjunto local. Aquele byte pertencia ao contrato de representação. Uma biblioteca que sempre o entregasse à aplicação confundiria camadas; uma biblioteca que sempre o removesse cometeria o erro oposto em outros modos.

Enter reabriu a diferença entre tecla e ação

A semântica de saída não resolvia inteiramente a entrada humana. Quando alguém pressionava Return ou Enter, o cliente deveria pedir a função de nova linha ou transmitir o CR do teclado?

A RFC 1123 registrou que clientes haviam seguido dois caminhos: CR LF ou CR NUL. Servidores ASCII corretos deveriam produzir o mesmo efeito da tecla local de fim de linha para os dois pares quando fossem entrada de terminal. Em hosts não ASCII, porém, aceitar CR NUL como Enter podia impedir a entrada de um CR literal.

A correção passou a nomear contexto e papel. Um User Telnet precisava conseguir enviar CR LF, CR NUL e LF. Em host ASCII, devia preferencialmente oferecer escolha controlada pelo usuário e adotar CR LF como padrão para a tecla de fim de linha. Na saída do servidor e em dados de outro protocolo carregado por Telnet, o fim de linha tinha de ser CR LF.

O server ainda traduzia para seu terminal local. Em modo raw, podia entregar CR ao programa. Em modo formatado, aplicava a convenção de linha do host. O requisito preservava o efeito na fronteira; não obrigava todos os buffers internos a conter os mesmos octetos.

Binary trocava a autoridade de interpretação

Segundo a RFC 856, Binary é negociado de forma independente em cada direção. Só passa a valer quando um lado pede e o outro confirma. Os octetos comuns se tornam dados de oito bits, embora IAC continue introduzindo comandos e precise aparecer duas vezes para representar 255 como dado.

A RFC 1123 deixa o limite claro: no modo Binary não existe processamento de fim de linha. O Telnet não pode substituir CR por CR NUL ou CR LF.

Logo, Binary não é apenas NVT com mais um bit. Ele entrega CR, LF e NUL ao domínio da aplicação. Um normalizador que descarta NUL por reconhecer a forma antiga corrompe o fluxo; inserir NUL por precaução também corrompe.

Diagnóstico exige a captura dos bytes, da direção e do estado negociado. Texto já renderizado não basta para provar quem tinha direito de interpretar a sequência.

Linemode aproximava a edição sem capturar a saída

A RFC 1184 permitiu que o cliente editasse a linha localmente, reduzindo viagens por caractere em links lentos. Com EDIT ativo, o terminador local normal era enviado como CR LF.

Com EDIT inativo, carriage return ia como CR NUL, line feed continuava LF e uma tecla especial que significasse conclusão da linha virava CR LF. O servidor seguia responsável pela própria saída: CR LF para nova linha, CR NUL para retorno sem descida e LF para descida sem retorno.

Mover edição e buffering por eficiência não deslocava a autoridade sobre o sentido dos dados produzidos pelo servidor. A otimização permanecia compatível com o contrato comum.

O texto Unicode herdou a linha, não a impressora inteira

A RFC 5198 retomou a herança do NVT ao definir Net-Unicode. Escolheu UTF-8, manteve CRLF como representação de fim de linha e preservou a restrição de que CR deve vir imediatamente antes de LF ou NUL.

Ao mesmo tempo, recomendou evitar CR NUL. Composição e marcação modernas reduziram a utilidade de movimentos de impressora, enquanto NUL pode encerrar strings em certas linguagens. O mecanismo que antes expressava sobreposição ou retorno isolado passou a trazer mais risco para textos comuns.

Isso mostra evolução de escopo. CR NUL solucionou uma decisão real no NVT; CRLF sobreviveu como parte instalada da representação de linhas; a exceção perdeu centralidade.

O registro IANA de opções Telnet mantém Binary, Linemode e opções de disposição. Ele prova números e referências, não quantidade de uso nem conformidade atual.

O byte descartado não volta na auditoria

O arranjo distribuía autoridade sem um árbitro central. O emissor escolhia uma ação NVT; o receptor lia o byte adjacente e verificava; cada host traduzia localmente; uma mudança de intérprete exigia negociação.

Os atalhos quebram essa ordem. Gateways normalizam antes de ler o modo, APIs terminam a string em NUL, clientes confundem Enter com toda forma de retorno e logs conservam apenas a tela final. Depois que o discriminador some, intenção humana não recompõe a evidência perdida.

Fontes e limites de evidência

Os documentos sustentam o modelo, as correções e as exceções negociadas. Não medem adoção contemporânea, não certificam produtos e não mostram uniformidade de todas as implementações históricas. CR NUL é analisado apenas dentro do modo, direção e função que lhe dão sentido.