Resumen

  • RFC 2351 definió MATIP entre TCP y las aplicaciones de aerolíneas para acordar tipo de tráfico, multiplexación, cabeceras, presentación y terminales configurados.
  • Open Confirm podía aceptar una sesión completa o parcialmente, pero no certificaba una reserva, la emisión de un billete ni la entrega final de un mensaje.
  • Ante una consulta Type A sin respuesta, el usuario podía repetirla; esa posibilidad no aclaraba si la primera operación no llegó o si ya había producido un efecto.

Una pantalla silenciosa obliga a actuar con menos información de la que parece. RFC 2351 explica que el tráfico Type A podía descartarse y que, si no había respuesta, el usuario podía duplicar la petición. El segundo envío era una conducta de recuperación, no una prueba forense sobre el primero.

La petición inicial pudo perderse. También pudo llegar al sistema central, cambiar el inventario y perder solo la respuesta. Pudo ser rechazada antes del compromiso, o quedar en una etapa intermedia. La ausencia visible era la misma; la realidad operativa no.

MATIP se diseñó para otro problema. Las aerolíneas conservaban terminales, hosts y protocolos creados mucho antes de la expansión de TCP/IP. Migrar todas las aplicaciones a la vez era costoso. Usar una capa de correspondencia común permitía aprovechar redes IP sin imponer una sustitución completa del sistema de reservas.

El transporte común no absorbió el significado

RFC 2351 separa Type A, usado para conversación interactiva y tráfico host a host, de Type B, dedicado a mensajería con varias prioridades y destinatarios. Los formatos comerciales seguían definidos por reglas de IATA y acuerdos entre las partes. El RFC describía cómo transportar, no cómo vender un asiento.

MATIP ocupaba el espacio entre TCP y la aplicación. Los puertos 350 y 351 identificaban Type A y Type B. Tras establecer TCP, Session Open y Open Confirm acordaban el subtipo, la multiplexación, el tratamiento de cabeceras, la codificación y, en ciertos casos, la lista de ASCU. Cada conjunto de parámetros necesitaba su propia sesión.

La ficha del RFC Editor lo clasifica como Informational. No era un estándar de Internet obligatorio ni el informe de una implantación. Era una interfaz para que sistemas distintos reconocieran la misma envoltura de comunicación.

Esa interfaz mantenía varias verdades separadas. TCP podía estar conectado y MATIP cerrado. MATIP podía aceptar la sesión y rechazar algunas ASCU. Una ASCU configurada podía carecer de permiso para una acción. Una aplicación podía recibir la solicitud sin haber confirmado aún el asiento o el billete.

Confirmar la apertura no es confirmar la venta

En Type A conversacional, Open Confirm podía aceptar, rechazar o aceptar con exclusiones. Informaba qué unidades quedaban configuradas. Eso era evidencia útil de que la sesión tenía parámetros coherentes.

No contenía una identidad universal de reserva, una versión del inventario, una garantía de tarifa o una anotación de contabilidad. El payload conservaba el significado del sistema aéreo al que pertenecía. El protocolo podía preservar los bytes y la identificación del terminal sin saber si la operación comercial era válida.

Además, un nuevo Session Open recibido sobre una sesión abierta borraba la configuración asociada y la sustituía. La conexión TCP podía seguir viva mientras cambiaba el perímetro operativo de la sesión. La continuidad del cable lógico no probaba continuidad de terminales ni de transacciones.

Type B ofrecía el mismo límite desde otro ángulo. La apertura verificaba que ambos sistemas podían comunicarse con características compatibles. El mensaje todavía debía cumplir las reglas del servicio Type B. Aceptar el canal no era entregar a todos los destinatarios ni completar el proceso posterior.

La fiabilidad tiene un objeto concreto

RFC 793 hizo de TCP un flujo ordenado y fiable entre procesos. Esa fiabilidad se refiere a bytes. No convierte el acuse del extremo remoto en una decisión sobre inventario, autorización o contabilidad.

Tras una desconexión, el extremo remoto puede haber acusado los bytes sin que la aplicación los comprometiera. O la aplicación puede haber comprometido la operación antes de que se perdiera la respuesta. Resolver la diferencia exige un identificador comercial persistente, estado durable y una consulta posterior. Una dirección IP, una ASCU o un identificador MATIP no cumple automáticamente esa función.

La seguridad tampoco elimina la distinción. RFC 2351 menciona configuración estática, usuario y contraseña, cortafuegos e IPsec opcional; su descargo de seguridad advierte que el protocolo no incorpora protección suficiente. Cifrar el trayecto, autenticar un terminal, autorizar una operación y demostrar su resultado siguen siendo actos diferentes.

La historia permite ver el límite, no inventar adopción

El documento no demuestra que una aerolínea concreta desplegara MATIP ni que siga siendo común en 2026. Tampoco informa de un incidente real. Demuestra que una transición a IP podía conservar aplicaciones existentes sin transferir su autoridad a la red.

La defensa de Lu Heng de la primacía del código en funcionamiento ofrece una lectura útil: un estado compartido vale por lo que implementaciones independientes pueden comprobar. Convertir “sesión aceptada” en “reserva completada” concede al símbolo un poder que su ejecución no sostiene. Su idea de una especificación inicial mínima refuerza el diseño: normalizar lo necesario para interoperar y dejar las decisiones locales en el sistema que soporta sus consecuencias.

RFC 2351 abrió una carretera IP para terminales antiguos. El inventario de asientos no viajó al puesto de peaje.