Resumo

  • A RFC 1921 colocou tela, impressora e impressão da cópia de tela em três endereços TNVIP; cada endereço podia manter apenas uma solicitação pendente.
  • Se outro pedido chegasse no mesmo endereço antes da resposta, era apagado. A resposta PROTOCOL-VIOLATION só podia vir depois da resposta anterior, preservando a identidade por ordem.
  • EOR fechava um registro, e Terminal-Type escolhia uma apresentação. Nem eles nem ACK, BUSY, READY ou Mailbox provavam usuário autorizado, resultado no host ou página impressa.

Ocupado era uma decisão de descarte

Sistemas atuais acostumaram operadores a ler “ocupado” como “aguarde”. A palavra sugere que existe uma fila, que o trabalho está guardado e que o dispositivo o executará quando puder. TNVIP não fazia essa promessa.

Na RFC 1921, publicada como Informational em março de 1996, um novo pedido de dados para impressora podia ser apagado enquanto o pedido anterior ainda não terminara. O cliente respondia BUSY. O remetente precisava saber que os bytes não estavam esperando em algum buffer invisível.

O protocolo atendia terminais VIP da Bull sobre Telnet. Esses terminais trabalhavam em modo de bloco e podiam combinar tela e impressora. Um servidor TNVIP normalmente funcionava como ponte para um Terminal Manager DSA e para aplicações do host. O desafio não era apenas transportar caracteres: era conservar a situação de dispositivos diferentes dentro da mesma conexão.

O cabeçalho escolhia a pequena máquina de estados

Cada mensagem trazia dois octetos obrigatórios antes dos parâmetros e de IAC EOR. O primeiro selecionava o fluxo: tela 0x60, impressora 0x68 ou cópia de tela 0x69. O segundo trazia comando e tipo.

Indication não aguardava resposta. Request abria uma espera. Response fechava a espera daquele endereço. Response-and-request confirmava positivamente o pedido atual e criava um novo pedido. Portanto, a interpretação não morava na conexão inteira nem no código isolado. Morava na combinação de endereço, tipo e pedido corrente.

A tela podia aguardar um resultado enquanto a impressora mantinha outro estado. O protocolo restringia novo pedido no mesmo endereço; não declarava uma trava única para toda a sessão. Três pequenos registros substituíam um grande livro de transações.

A infração precisava ficar atrás da primeira resposta

Sem um ID geral de operação, TNVIP dependia de uma invariável simples: por endereço, apenas um request ainda sem response. Quem enviasse o segundo cedo demais violava a regra.

O receptor apagava esse segundo pedido. Em seguida, esperava. Primeiro entregava a resposta pertencente ao pedido que já estava aberto; só depois enviava PROTOCOL-VIOLATION sobre o pedido apagado.

Se o erro passasse na frente, o remetente teria duas perguntas possíveis e uma resposta sem número. Poderia atribuir a violação ao primeiro pedido. Se o receptor guardasse o segundo para depois, inventaria uma fila e ocultaria a perda. A ordem escolhida preservava dois fatos: o primeiro pedido ainda merecia sua resposta, e o segundo jamais fora admitido.

LDAP resolveu um problema de concorrência de outra maneira, numerando operações para permitir respostas intercaladas. TNVIP limitou a concorrência por dispositivo. A comparação mostra uma escolha de custo: mais identificadores e liberdade de intercalar, ou menos estado compartilhado e disciplina de espera.

Negociar um modelo não autenticava o terminal

Antes das mensagens TNVIP, os lados precisavam aceitar Terminal-Type e End-of-Record. A string de terminal trazia um modelo e, opcionalmente, @Mailbox-name. O Mailbox selecionava um ponto de acesso específico no servidor; sem ele, havia acesso genérico. Em uma ponte DSA, o nome tinha até doze caracteres e letras minúsculas eram tratadas como maiúsculas.

O campo permitia escolher uma declaração lógica, inclusive uma estação com impressora. Não era credencial. RFC 1091 define como anunciar o tipo de terminal; não prova equipamento ou usuário. A seção de segurança da RFC 1921 disse que segurança não fora tratada e apontou a autorização para usar um terminal como problema futuro de autenticação.

Quando a apresentação exigia oito bits, os pares podiam negociar Binary Transmission de RFC 856. Quando o envio não precisava do GA para acompanhar o turno DSA, podiam usar Suppress-Go-Ahead de RFC 858. Essas opções definiam bytes e ritmo. Não concediam mandato ao usuário.

Um bloco completo ainda podia desaparecer

VIP era orientado a blocos. TNVIP usou o End-of-Record de RFC 885 sobre o Telnet da RFC 854 para fechar cada mensagem.

O marcador mostrava onde o registro terminava. Depois vinham admissão e processamento. A tela podia estar em estado LOCAL; a impressora podia continuar ocupada; um purge podia interromper o pedido; um comando podia ser desconhecido. Em todos esses casos o enquadramento continuava correto.

Havia até uma ambiguidade dentro do bloco. Comandos Telnet, exceto IAC IAC, podiam ser processados imediatamente ou apenas depois da mensagem TNVIP. Por isso a RFC recomendava mandá-los entre mensagens. O envelope possuía fronteira, mas não controlava sozinho o instante de todo comando colocado nele.

Cada resposta precisava de endereço e antecedente

ACK na tela podia significar dados bem processados ou confirmação do pedido LOCAL. BUSY na tela dizia que dados foram apagados porque o terminal estava LOCAL. Na impressora, BUSY dizia que o pedido anterior ainda estava em impressão e o novo fora apagado. READY respondia a uma consulta de estado; não confirmava um pedido de dados.

Outras respostas separavam outros acontecimentos: ERROR, ABORTED, PURGED, NOT-AVAILABLE, PROTOCOL-VIOLATION e UNKNOWN-COMMAND. Uma indication desconhecida podia ser apagada sem resposta. Um request desconhecido precisava fechar a espera que abrira.

Essas diferenças tornam perigoso um painel que soma tudo em “falhas do terminal”. Um estado útil deve dizer qual endereço, qual pedido, qual direção e qual transição produziram o código.

LOCAL suspendia a descida, não a conexão inteira

O cliente podia entrar em estado LOCAL para testes ou configuração. Antes disso enviava LOCAL-STATE. O servidor reconhecia e suspendia dados de tela e impressora até receber ONLINE-STATE.

Se o servidor continuasse enviando, o cliente apagava os dados. Um request de tela recebia BUSY. A conexão permanecia estabelecida e o EOR podia estar perfeito; a política local recusava o efeito.

Mensagens originadas pela tela cliente e fluxos de outros endereços continuavam permitidos. “Terminal local” não era sinônimo de “sessão morta”. O estado tinha sentido e escopo específicos.

A cópia de tela separava licença e conclusão

Como servidor e usuário podiam compartilhar a impressora, o cliente pedia autorização antes de imprimir uma cópia da tela. Enviava COPY-REQ pelo terceiro endereço. O servidor respondia LOCAL-COPY quando permitia.

LOCAL-COPY era response-and-request. Fechava a pergunta “posso começar?” e abria “qual foi o resultado?”. O cliente ainda devia responder ACK, ERROR, BUSY, ABORTED, PURGED ou NOT-AVAILABLE.

Permissão não era impressão. Um resultado de protocolo ainda não era uma testemunha diante do papel. A matéria existente sobre RFC 1318 já possui a fronteira entre sinais físicos da porta paralela e documento impresso; TNVIP possui outra: admissão, ordem e resposta do pedido remoto.

Depois da resposta, purge perdia autoridade

Tela, impressora e cópia possuíam indicação PURGE. Se ainda não houvesse resposta, o receptor tentava abortar o processamento e devolvia PURGED. Se já tivesse respondido, apagava e ignorava a indicação.

A mensagem atrasada não reescrevia a história. Tampouco prometia desfazer qualquer ação física que já passara do ponto controlado pelo protocolo. Cancelar estado pendente e reverter o mundo eram operações diferentes.

A formulação posterior de Running-Code Primacy ajuda a manter essa separação, sem fingir que explica a intenção dos autores: documento, código em execução e resultado observado são registros relacionados, não intercambiáveis.

O que 1996 não deixou comprovado

A RFC 1921 documenta formato e regras. RFC 1576 registra práticas de TN3270, tema de outro Artigo, e serve apenas para marcar a diferença entre perfis. Nenhuma dessas fontes informa quantidade de instalações, produto Bull compatível, incidente real ou uso atual.

Também não há prova de usuário, autorização, tela alterada, aplicação concluída ou papel entregue. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption oferece uma lente atual: especificar em comum apenas o necessário para validar a troca e deixar decisões posteriores com quem executa e observa.

TNVIP fez exatamente o tipo de afirmação que pode ser auditada. O segundo pedido não estava “a caminho”. Foi apagado. O erro não era a resposta anterior. Teve de esperar. Essa precisão vale mais do que uma luz verde para a sessão inteira.