Resumo

  • O RFC 2126 preservou o TPKT versão 3 para interoperar com o RFC 1006, embora o número já não comprovasse acordo sobre Class 0, Class 2 ou opções expressas.
  • Classe selecionada, segundo canal, ordem entre canais e entrega remota eram estados diferentes; até um desligamento “normal” precisava de informação adicional para definir sua obrigação.

O fim da conexão é um bom lugar para começar. O RFC 2126 chamava de normal tanto o desligamento disruptivo quanto o não disruptivo. O que mudava não era a aparência do reason code, mas o destino dos TPDUs já entregues ao provedor local.

Essa ambiguidade controlada repetia a decisão central do documento. Publicado em março de 1997, ele refinou o transporte ISO sobre TCP em IPv4 e IPv6, acrescentou Class 2 e manteve o TPKT versão 3 para proteger implementações RFC 1006.

O mesmo número já não descrevia a mesma capacidade

Alguns peers antigos não negociavam classe. Um iniciador podia pedir Class 2 sem alternativa e receber um Connect Confirm Class 0. O TCP estava aberto e a mensagem era válida, mas deveria ser rejeitada conforme ISO 8073.

A versão comprovava uma moldura reconhecível. O CR registrava a preferência; o CC, a seleção; a decisão local, a compatibilidade entre ambas. Nenhum desses fatos substituía os demais. O reserved field também deveria ser ignorado na entrada para manter interoperabilidade, não reinterpretado como sinal oculto.

Independência e sincronização exigiam escolhas diferentes

Em Class 2, dados expressos podiam seguir in-band. Forward ou Reverse Connection permitia um TCP separado, evitando que um canal normal ocupado bloqueasse o urgente. O segundo TCP precisava ligar o mesmo par de hosts, pertencer a uma única Transport Connection e terminar com ela.

Mesmo assim, a negociação não provava que o canal já existia. No procedimento Forward, o momento de abertura era escolha da implementação. E duas conexões independentes não garantiam ordem comum.

O RFC tratava os requisitos separadamente: Forward/Reverse criava independência; Expedited Data Acknowledgement ou Non-blocking Expedited Data podia criar sincronização. Independência sem sincronização relaxava o serviço ISO e não era consistente com ISO 8072.

Um encerramento começava na custódia local

Class 0 dependia do fechamento TCP e era disruptiva. Class 2 trocava DR e DC. No modo disruptivo, TPDUs ainda na origem não precisavam ser enviados; reason 80 hex. No modo não disruptivo, tudo já entregue ao TS-provider local precisava chegar ao TS-user remoto antes do fechamento; o reason continuava 80, acompanhado de Additional Information 80.

Portanto, aceitar localmente era assumir uma obrigação, não concluir a entrega. Um log que guardasse apenas “normal close” não conseguia dizer qual contrato valera.

Registro e segurança continuavam estreitos

O RFC reservava TCP 102, mas não obrigava toda conexão a usá-lo. A linha iso-tsap da IANA comprova coordenação do número, não um listener, Class 2 ou tráfego real. O documento também não acrescentava segurança: declarou-se nem mais nem menos seguro que TCP e ISO 8073.

Os textos públicos de Lu Heng oferecem uma lente assumida: limitar alegações ao estado do código em execução, preservar decisões futuras fora da especificação mínima e não confundir símbolo com resultado. O RFC 2126 fez exatamente essa cobrança documental.

Seu legado não é uma condenação da compatibilidade. É a regra para torná-la honesta. Quando o identificador externo permanece e a semântica cresce, versão, classe pedida, classe escolhida, aceitação, canal, sincronização, custódia e entrega precisam de recibos separados.

Fontes