Resumo

  • RFC 2351 colocou uma sessão MATIP acima de TCP para combinar tipo de tráfego, multiplexação, cabeçalhos, apresentação e terminais configurados.
  • Open Confirm comprovava o acordo da sessão, não a reserva do assento, a emissão da passagem ou a entrega final de uma mensagem Type B.
  • A orientação para repetir uma consulta Type A sem resposta deixava uma pergunta em aberto: a primeira tentativa falhou ou apenas sua resposta desapareceu?

O detalhe mais atual de RFC 2351 vem de uma prática antiga. O tráfego Type A de consulta e resposta podia ser descartado. Sem resposta, o usuário podia duplicar a solicitação. A ação ajudava a continuar o trabalho, mas não determinava o que já havia ocorrido.

A ida poderia ter falhado. O sistema central poderia ter recusado o pedido. A reserva poderia ter sido gravada e a resposta perdida. O mesmo silêncio cobria situações diferentes. Repetir poderia recuperar uma operação ausente ou tentar de novo uma operação já comprometida.

MATIP não foi concebido para resolver toda essa incerteza. Seu objetivo era permitir que numerosos terminais e aplicações de companhias aéreas, construídos antes da difusão de TCP/IP, usassem um transporte comum e mais econômico sem exigir substituição imediata.

Preservar a aplicação, trocar a estrada

O Type A atendia conversas em tempo real e comunicação entre hosts, incluindo reserva e emissão. O Type B carregava mensagens sem exigência de tempo real, com proteção maior, múltiplos destinos e prioridades. A semântica detalhada continuava nas normas da IATA e nos acordos bilaterais.

MATIP ficava entre TCP e a aplicação. As portas 350 e 351 separavam os tipos. Depois da conexão TCP, Session Open e Open Confirm definiam subtipo, multiplexação, cabeçalho, codificação e escopo de ASCU. Conjuntos diferentes de parâmetros precisavam de sessões separadas.

O registro do RFC Editor classifica o documento como Informational. Ele não transformou um desenho de migração em obrigação global. Criou uma maneira interoperável de anunciar como o tráfego legado atravessaria IP.

Isso gerava vários estados legítimos. TCP podia estar conectado sem MATIP aberto. MATIP podia aceitar a sessão e excluir certas unidades. Uma unidade configurada podia não estar autorizada a executar a operação. A aplicação podia receber o payload e ainda não ter alterado seu livro de reservas.

Um aceite condicional tem objeto limitado

No Type A conversacional, Open Confirm podia recusar, aceitar ou aceitar com condições, listando ASCUs configuradas ou rejeitadas. Esse retorno comprovava que os pares haviam estabelecido uma sessão coerente.

Não era um comprovante de reserva. Não carregava um identificador universal de transação, versão de estoque, garantia de tarifa ou lançamento de bilhete. O conteúdo da aplicação mantinha seu significado próprio. O envelope não adquiria autoridade sobre o que transportava.

Há ainda uma mudança sem corte aparente: novo Session Open em sessão já aberta elimina a configuração anterior e instala outra. TCP pode continuar conectado enquanto muda o conjunto operacional de terminais. Continuidade de conexão não é continuidade de sessão; continuidade de sessão não é continuidade de negócio.

No Type B, a abertura verificava características compatíveis. A mensagem ainda precisava obedecer ao serviço acessado. O aceite da sessão não era prova de entrega a todos os destinos, muito menos de tratamento pelo sistema comercial seguinte.

TCP entrega bytes, não decisões

RFC 793 descreve um fluxo confiável e ordenado entre processos. A confirmação TCP informa que bytes chegaram à outra pilha. Não informa se a aplicação autorizou, registrou ou reconciliou a operação.

Em uma falha ambígua, o receptor pode ter confirmado bytes antes do compromisso da aplicação. A aplicação também pode ter comprometido o resultado antes de a resposta se perder. Execução efetivamente única depende de ID durável de negócio, estado persistente e leitura posterior. Endereço IP, ASCU e sessão MATIP ajudam a localizar o tráfego, mas não viram automaticamente chave idempotente.

A segurança mantém outra fronteira. RFC 2351 cita configuração estática, usuário e senha, firewall e IPsec opcional; o aviso de segurança diz que o protocolo não trata adequadamente essas preocupações. Proteger o canal, admitir o terminal, autorizar uma ação e provar o resultado são quatro verificações.

O passado não autoriza suposições sobre o presente

As fontes não provam que uma companhia específica implantou MATIP, que o protocolo continua comum em 2026 ou que houve um incidente real. Elas mostram uma migração capaz de padronizar transporte sem deslocar a responsabilidade da aplicação.

O argumento de Lu Heng sobre a primazia do código em execução ajuda a medir o alcance: um sinal comum vale pelo que implementações independentes conseguem observar. Se “sessão aceita” vira “passagem emitida”, o rótulo ganha autoridade sem execução correspondente. A especificação inicial mínima oferece a disciplina complementar: padronizar o necessário à interoperabilidade e deixar decisões locais com quem suporta seus efeitos.

RFC 2351 levou a conversa aérea antiga para a estrada IP. O registro do assento permaneceu no destino.