Cos (cos) wrote,
Cos
cos

"Rejected messages will not be rejected."

That's a quotation from the Systems and Communications Reference Manual, which defines several of the airline industry's communications protocols. Or would, if it made any sense. And if the parts that do make some sense were readable.

For example, one protocol it describes has a field called a "TPR". A TPR is an arbitrary 3-20 character string that starts with either P or Q: It starts with P when it's created by the system sending the initial query, Q when it's created by the responding system. Simple enough, right? Too simple for the SCR. Instead, we get a table like this:

    OCTET 1 FORMAT:
    BitFunctional assignment
    (B)  
    b7b6b5101 always, for translation purposes
     
    b4-b10000 TPR created by querying system
    0001 TPR created by responding system
    0010
    through
    1010
     reserved


    OCTET 2-N FORMAT:
    Any translatable bit combinations. Embedded Separator or Ender characters within the TPR fields are prohibited.

"Octet 1" means the first character. "Octet 2-N" means the rest. In 7-bit ASCII, 101 0000 is "P" and 101 0001 is "Q".

This bit of obfuscation is typical of the description of one of the most commonly used message transport protocols in the airline industry, HTH - "Host To Host Protocol". One of the other most common message transport protocols is BATAP, "type B Application To Application Protocol".

Actually, HTH is an application to application protocol, because it handles getting messages to specific applications. (For the networking geeks: HTH actually has separate headers for each of OSI layers 4, 5, 6, 7. Yeah, OSI isn't as dead as I thought :/) BATAP, on the other hand, isn't an application to application protocol, or even a host to host protocol - it has no addressing at all, it's just a point-to-point protocol.

BATAP got its name, I think, from the fact that it's generally used to transport teletype messages, and teletype messages have addresses inside them that can be used to route them to specific applications. So even though BATAP is not at all an application to application protocol, it's usually used for application to application messaging. *sigh*

"Teletype" - huh, you may think, where have I seen that term before? Or if you're old enough, you probably know right away: a teletype was one of these things. Think "telephone", "television", ... "teletypewriter". Early TTYs appeared in the 1920s, and computers and printers made them obsolete around the 1970s.

This is not a coincidence: those "teletype" messages airlines send were designed for actual Teletype machines. They're still in all caps, with lines limited to 69 characters, and a compact format full of few-letter codes that makes them read sort of like newspaper personals. These messages are how airline computers tell each other about availability of seats on flights, communicate schedule changes, make flight reservations on each others' flights, and many other things. Yes, today.

Early airlines designed these messages for humans who handled reservations before they had computers to do it, and they used teletypes to communicate with their booking offices. People at these offices processed computer-like workflows by hand until IBM met American Airlines and automated it. But even now, when most of this stuff is handled by software, there are places in the protocols where it explains under what conditions a human who has just received one of these teletype messages needs to pick up the phone to call some other airline's booking office. Once they relay the information, that other airline's agent will type it in, which may cause a new teletype message to be sent somewhere.

What we have here are messages designed for computers pretending to act like humans who are pretending to act like computers.
Tags: geek, jobs
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 11 comments