Resumo

  • A RFC 2351 mapeou para TCP/IP dois tráfegos com falhas diferentes: o Type A admitia descarte e repetição após silêncio; o Type B exigia proteção, múltiplos destinatários e quatro prioridades.
  • Conexão TCP e sessão MATIP aceita comprovavam compatibilidade de transporte. Não comprovavam reserva feita, bilhete emitido, repetição inofensiva nem responsabilidade transferida para uma mensagem específica.

Em 1998, o custo da rede mudava mais depressa que o software das companhias aéreas. Pilhas TCP/IP se tornavam baratas e as intranets se espalhavam, mas milhares de escritórios ainda dependiam de terminais P1024B ou P1024C e de aplicações centrais construídas sobre protocolos muito anteriores.

A RFC 2351 respondeu com o MATIP, Mapping of Airline Traffic over Internet Protocol. Em vez de reescrever reservas, emissão e mensageria, padronizou a camada entre TCP e a aplicação aérea. A escolha reduzia a dependência de gateways proprietários incompatíveis e, ao mesmo tempo, mantinha no aplicativo aquilo que o transporte não podia saber.

O Type A transformava silêncio em decisão de repetir

O Type A incluía a conversa entre agência ou escritório e o computador central de reservas e bilhetes. Era interativo, prioritário e pouco protegido. Podia ser descartado. Se a perda produzisse ausência de resposta, dizia o RFC, o usuário podia duplicar o pedido.

Isso não tornou toda operação idempotente. Repetir uma consulta de disponibilidade não equivale a repetir uma venda. A especificação não criou identificador transacional universal, registro de deduplicação ou conciliação para cada sistema. A aplicação continuava responsável por decidir se o novo pedido era reposição, duplicata ou outra ordem legítima.

O MATIP preservava o contexto que levava o tráfego até essa decisão. A abertura negociava subtipo, codificação, apresentação, cabeçalho e multiplexação. H1, H2, A1 e A2 podiam identificar um conjunto de terminais sem depender do endereço IP; o tráfego host a host podia usar Flow ID. Eram seletores de protocolo, não prova de identidade humana, autoridade de reserva ou gravação final no host.

O Type B carregava uma obrigação diferente

O Type B era mensageria. Não dependia da mesma urgência, mas precisava de alta proteção, múltiplos endereços e quatro níveis de prioridade. A arquitetura colocava o BATAP acima do MATIP como protocolo de aplicação a aplicação para proteger esse fluxo.

Na Session Open do Type B, PROTEC indicava o protocolo de transferência de responsabilidade de ponta a ponta. Se os mecanismos não combinassem, Open Confirm podia recusar a sessão. HLDs identificavam remetente e destinatário, ou o par de endereços IP podia representar os sistemas.

Compatibilidade não era recibo. Concordar em PROTEC mostrava que os lados entendiam o mesmo mecanismo; não mostrava que uma mensagem concreta fora aceita pelo BATAP, entregue a todos os destinatários ou transferida de custódia. Era necessário o reconhecimento da aplicação e o estado posterior.

Portas separavam os fluxos, não encerravam o negócio

O Type A usava a porta TCP 350 e o Type B, 351. Cada conjunto de parâmetros exigia conexão e sessão próprias. Session Open apresentava características; Open Confirm aceitava ou recusava; Session Close encerrava o MATIP. Não havia keep-alive nessa camada, e o timeout dependia de TCP.

Os ciclos de vida se cruzavam sem se confundir. MATIP precisava de TCP ativo, porém fechar MATIP não exigia fechar TCP. Assim, TCP conectado não comprovava sessão aérea utilizável; MATIP aceito não comprovava transação encerrada.

A RFC 793 definia para TCP um fluxo de bytes confiável e ordenado entre processos. A RFC 1122 fixava obrigações dos hosts nas camadas de comunicação. Nenhuma delas via o estoque de assentos, o número do bilhete ou a aceitação final de uma mensagem Type B.

A cadeia útil deve separar caminho de rede, estabelecimento TCP, Session Open, Open Confirm, ASCU ou HLD permitido, dados entregues, reconhecimento do aplicativo, transferência de responsabilidade, estado comercial gravado e conciliação de duplicatas. Encurtar a cadeia concede ao transporte uma autoridade que ele não tem.

O alerta de segurança revelou o preço da ponte

A RFC 2351 admitia configuração estática do ASCU ou usuário e senha, filtragem por firewall e IPsec ESP ou AH opcional. Hoje o RFC Editor anexa um alerta: identificadores estáticos e senhas aparentemente em claro não fornecem segurança sólida, enquanto a proteção forte por IPsec ficou facultativa.

O alerta delimita o MATIP. A ponte resolvia migração e interoperabilidade, mas não transformava um rótulo legado em autorização criptográfica. A RFC 4301 depois descreveu políticas e Security Associations para IPsec. Mesmo com essa capacidade, só o registro da operação demonstra que a troca concreta recebeu a proteção esperada.

A importância histórica da RFC 2351 está nessa contenção. A rede podia ser comum; o significado de silêncio, confirmação e conclusão continuava pertencendo à camada que enxergava o fato.

Fontes