From TTY to EDIFACT: Structuring Airline Messages

Deep Dive: TTY, Type A, Type B & Modern Equivalents

Let us walk through the evolution calmly and systematically, removing any mystery – just clear building blocks you can implement and test.

Type A vs Type B (Why we cared)

Dimension	Type A	Type B (TTY style)	Modern API (Reference)
Primary Use (classic)	Interactive host queries, confirmations	Operational notices, passenger lists, schedule messages	Shopping, offer management, order servicing
Transport	Real-time session / switched network	Store-and-forward network (queued)	HTTP(S), MQ, event streams
Structure	Field oriented	Free-form lines + coded blocks	Schema (XSD/JSON Schema)
Latency Expectation	Seconds (interactive)	Minutes (acceptable historically)	Sub-second to seconds
Error Handling	Immediate code/ack	Non-delivery notices / manual follow-up	HTTP codes + structured errors
Extensibility	Limited	Ad hoc free text risky	High (versioned fields)

Anatomy of a Type B / TTY Message

Think of it like an old postcard you drop in a box; it finds the route. Components typically:

1. Address line(s): Destination(s) (SITA addresses, e.g., AAAAPXH). Multiple lines if multi-cast.
2. Origin/Date-Time stamp: Often auto-added.
3. Message type indicator: e.g., PNL, ADL, SSM.
4. Body: Coded lines (segments, SSR/OSI elements).
5. Ending: Sometimes // or a blank line; network-specific.

.QXHAA4D
/DELAAA
  PNL 1234/25MAY DELCOK 25MAY
  001 SMITH/JOHNMR
  002 LEENA/PRIYAMSMRS SSR WCHR
//

Note: Formatting varies by carrier/GDS and network gateway. Uppercase prevailed because of teleprinter limitations.

Classic Common Type B (AirIMP) Message Codes (Sample)

About PAOREQ / ITAREQ / HWPREQ (Important Disclaimer)

These label styles (REQUEST/RESPONSE pairs like PAOREQ/PAORES, ITAREQ/ITARES, HWPREQ/HWPRES) appear in several internal airline ICDs or vendor-specific EDIFACT/PADIS profiles. They are not universal AirIMP codes. What follows is an illustrative template to understand structural patterns. Validate naming and exact segment usage with your host provider and the specific PADIS version you implement.

First we show a simplified “TTY-like” representation, then an EDIFACT version, then a modern JSON analogy for mapping clarity.

1. PAOREQ / PAORES (Illustrative “Pricing & Availability Offer”)

Legacy TTY-Style (Conceptual)

.QXHAA4D
/BOMXYZ
PAOREQ
REF 7K3H82
ORIGIN BOM
DEST DEL
DATE 25MAY
PAX 01
CABIN Y
RBD  Y,M,H
CORP CODE ACME01
//

EDIFACT-Like PAOREQ (Illustrative)

UNA:+.? '
UNB+IATB:1+AIRLINECODE+SELLERID+240125:1045+000012345'
UNH+0001+PAOREQ:D:24A:UN:IATA'
MSG+1'
ORG+179+BOM'
DST+179+DEL'
DTM+710:20240525:102'
PTY+1+ADT'
RBD+Y:M:H'
CUX+2:INR'
RPI+1+CORP:ACME01'
RCI+PREF:Y'
UNT+11+0001'
UNZ+1+000012345'

Segment Notes (Simplified):

• UNH identifies message and version.
• ORG/DST used here as stand-ins (real implementations may use LOC segments).
• DTM sets travel date.
• RBD may appear differently depending on spec (sometimes within FLI/FTI context).

EDIFACT-Like PAORES (Response)

UNA:+.? '
UNB+IATB:1+AIRLINECODE+SELLERID+240125:1045+000012346'
UNH+0002+PAORES:D:24A:UN:IATA'
MSG+1'
RFF+CR:7K3H82'
DTM+329:20240525:102'
CUX+2:INR'
AVL+1+Y:Y9+M:M4+H:H2'
FLI+1+AI402+BOM:DEL+20240525T0700+20240525T0905'
FAR+1+Y:INR:5600'
FAR+2+M:INR:4500'
FAR+3+H:INR:3900'
TTL+P:01+INR:4500'
UNT+15+0002'
UNZ+1+000012346'

Key idea: Availability (AVL) lists RBD counts (Y9 means 9 or more). Fares (FAR) tie price to booking class. Actual specs may prefer different segments or qualifiers.

Modern JSON Analogy

{
  "requestId": "7K3H82",
  "origin": "BOM",
  "destination": "DEL",
  "date": "2024-05-25",
  "pax": [{"type": "ADT", "count": 1}],
  "consideredRBD": ["Y","M","H"],
  "currency": "INR",
  "corporateCode": "ACME01"
}

{
  "requestId": "7K3H82",
  "itineraries": [{
    "flightNumber": "AI402",
    "origin": "BOM",
    "destination": "DEL",
    "dep": "2024-05-25T07:00+05:30",
    "arr": "2024-05-25T09:05+05:30",
    "availability": {"Y": 9, "M": 4, "H": 2},
    "fares": [
      {"rbd": "Y", "amount": 5600, "currency": "INR", "brand": "Flex"},
      {"rbd": "M", "amount": 4500, "currency": "INR", "brand": "Standard"},
      {"rbd": "H", "amount": 3900, "currency": "INR", "brand": "Saver"}
    ],
    "lowestOffered": {"rbd":"H","amount":3900,"currency":"INR"}
  }],
  "pricingSource": "HOST",
  "timestamp": "2024-01-25T10:45:52Z"
}

2. ITAREQ / ITARES (Itinerary Request/Response – Illustrative)

Assume we already shortlisted flight numbers and now request enriched itinerary details (equipment, terminals, married segment validation) step by step.

TTY-Like ITAREQ

.QXHAA4D
/MAAABC
ITAREQ
REF J9LM55
FLT AI402 25MAY BOM DEL
NEED EQPT TERM RBDMAP
//

EDIFACT-Like ITAREQ

UNA:+.? '
UNB+IATB:1+SELLERID+AIRLINECODE+240125:1110+000045671'
UNH+1001+ITAREQ:D:24A:UN:IATA'
RFF+CR:J9LM55'
FLI+1+AI402+BOM:DEL+20240525T0700+20240525T0905'
RQI+EQP:TRM:RBD'
UNT+6+1001'
UNZ+1+000045671'

EDIFACT-Like ITARES

UNA:+.? '
UNB+IATB:1+AIRLINECODE+SELLERID+240125:1110+000045672'
UNH+1002+ITARES:D:24A:UN:IATA'
RFF+CR:J9LM55'
FLI+1+AI402+BOM:DEL+20240525T0700+20240525T0905'
EQP+32N'
TRM+DEP:T2+ARR:T3'
RBD+Y:M:H'
OPS+ON:20240525T0652+IN:20240525T0909'
UNT+9+1002'
UNZ+1+000045672'

Notes: EQP shows equipment (e.g., 32N for A321neo). TRM gives terminal info. OPS illustrative. Real specs often use DTM with qualifiers for operational times.

JSON Analogy

{
  "requestId": "J9LM55",
  "flights": [{
    "flightNumber": "AI402",
    "date": "2024-05-25",
    "departure": {"airport":"BOM","timeLocal":"07:00","terminal":"T2"},
    "arrival": {"airport":"DEL","timeLocal":"09:05","terminal":"T3"},
    "equipment": "32N",
    "rbdApplicable": ["Y","M","H"],
    "operationalTimes": {
      "offBlock":"2024-05-25T06:52+05:30",
      "inBlock":"2024-05-25T09:09+05:30"
    }
  }]
}

3. HWPREQ / HWPRES (Hold With Payment – Illustrative)

This models: “Hold itinerary and price; confirmation (payment or ticketing) will follow.” A booking shell or provisional PNR with a time limit is often created.

TTY-Like HWPREQ

.QXHAA4D
/BLRAC1
HWPREQ
REF Q2ZR77
PAX 1 ADT
ITIN AI402 25MAY BOM DEL RBD H
FARE INR3900 TAX INR812 TOTAL INR4712
PAY HOLD TL 25JAN 1800 IST
SSR FQTV AI 1234567890
//

EDIFACT-Like HWPREQ

UNA:+.? '
UNB+IATB:1+SELLERID+AIRLINECODE+240125:1130+000078900'
UNH+2001+HWPREQ:D:24A:UN:IATA'
RFF+CR:Q2ZR77'
PTY+1+ADT'
PAX+1'
FLI+1+AI402+BOM:DEL+20240525T0700+20240525T0905'
RBD+H'
PRI+H:INR:3900'
TAX+INR:812:TT'
MOA+TT:4712:INR'
TMD+HOLD:20240125T1800+Asia/Kolkata'
FQTV+AI:1234567890'
UNT+13+2001'
UNZ+1+000078900'

EDIFACT-Like HWPRES (Hold Confirmation)

UNA:+.? '
UNB+IATB:1+AIRLINECODE+SELLERID+240125:1130+000078901'
UNH+2002+HWPRES:D:24A:UN:IATA'
RFF+CR:Q2ZR77'
PNR+LOC:AB3X9Q'
STS+HOLD'
DTM+203:20240125T1800'
PRI+H:INR:3900'
MOA+TT:4712:INR'
RCF+OK'
UNT+10+2002'
UNZ+1+000078901'

JSON Analogy

{
  "requestId": "Q2ZR77",
  "action": "HOLD",
  "itinerary": [{
    "flightNumber":"AI402",
    "date":"2024-05-25",
    "rbd":"H",
    "price":{"base":3900,"tax":812,"total":4712,"currency":"INR"}
  }],
  "pax":[{"type":"ADT"}],
  "fqtv":[{"carrier":"AI","number":"1234567890"}],
  "timeLimit":"2024-01-25T18:00:00+05:30"
}

4. Error / Rejection Patterns

Legacy TTY often returned short text rejections. EDIFACT enables structured error codes; modern JSON can add detail and remediation hints.

TTY Error Example

PAORES
REF 7K3H82
REJECT CLASS CLOSED
ALT M H ONLY
//

EDIFACT Error Snippet

UNH+0003+PAORES:D:24A:UN:IATA'
RFF+CR:7K3H82'
ERC+911:CLASS CLOSED'
RBD+M:H'
UNT+5+0003'

JSON Error Analogy

{
  "requestId": "7K3H82",
  "status": "REJECTED",
  "errors":[
    {"code":"CLASS_CLOSED","detail":"Requested RBD Y not available"},
    {"code":"ALTERNATIVES","detail":"Try M or H"}
  ],
  "alternatives":["M","H"]
}

5. Mini Mapping Cheatsheet

6. Practical Implementation Tips

• Explicit Parsing: Avoid brittle substring offsets for TTY; use regex plus a dictionary of recognized prefixes.
• Normalise Early: Convert TTY to an internal canonical object model first; then render EDIFACT / JSON.
• Round-Trip Tests: Canonical → EDIFACT → parse back → compare objects to catch field loss.
• Latency Budget: Log each stage (parse, validate, price, compose) with timing.
• Content Validation: Enforce a schema (JSON Schema) on the canonical model even if source is free text.
• Semantic Versioning: Add version headers; allow backward-compatible additions.
• Error Transparency: Map internal errors to stable external codes; keep a translation table.
• Message Archive: Store raw original + parsed canonical with correlation IDs for audit.

7. Validation Checklist (Quick Pass)

• Address Validity: Outgoing Type B addresses active and correct?
• Segment Conformance: EDIFACT validated against current PADIS dictionary automatically?
• State Synchronisation: Hold responses always include locator before time limit countdown?
• RBD Consistency: Returned RBDs exist in inventory mapping for travel date.
• Currency Source: Currency selection rule documented and deterministic?
• Clock Discipline: Internal UTC; local times only at presentation edges.

8. Summary

9. Disclaimer & Sources

Disclaimer: The PAOREQ/PAORES, ITAREQ/ITARES, HWPREQ/HWPRES examples are illustrative composites for learning. Real-world segment names, qualifiers, and mandatory elements differ by PADIS version, host, and bilateral agreements. Always consult:

• IATA PADIS Implementation Guides (current version for your program).
• AirIMP documentation for legacy TTY code semantics.
• Vendor (GDS/host) Interface Control Documents (ICDs).

---

Back to all blogs

Extended examples prepared for educational purposes; verify against authoritative IATA and vendor specs before production use.