"Rejected messages will not be rejected."

[cos]

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:


Bit			Functional assignment
(B)
	b7b6b5	101	always, for translation purposes
	b4-b1	0000	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.

Comments

[frobzwiththingz.livejournal.com]

The sad thing about this, is the modern equivalent, in which this simple protocol would be wrapped up in 25k worth of XML, making it perfectly *readable* by any human that looked at it, without making it any more *understandable*.

[yehoshua.livejournal.com]

You seem to assume we don't already do this. :P

[ron_newman]

Is this how pilots and air traffic controllers communicate (when not using voice)?

[cos]

I don't know of any similar protocols used for communicating with computers on the actual planes themselves, and I assume pilot-ATC communication is primarily voice anyway. The computers handling stuff for the airports and airlines on the ground, communicating about things like gate changes and flight delays and passengers checked in and boarded, do use these ancient messaging protocols I deal with.

[formlesspassion.livejournal.com]

You say "Think "telephone", "television", ... "teletypewriter"
My brain says "Teletubby?"
Sorry! I'm Sorry! But it had to be said!
Now I will thank my lucky stars for people who know how to talk to computers.

[ommango.livejournal.com]

like button.

[bike4fish.livejournal.com]

I've always said that software always lasts 10 years longer than it was planned to, and sometimes 10 years longer than it would taking this principle into account.
Shared communications protocols and file formats are even worse.

I wonder how many 80-byte record files are still out there - and how many cram in extra data by using "overpunches", though the keypunches have been gone for 30 years.

[cos]

Various airline protocols come from different times, and they're all being tweaked every few years, but the teletype messages I'm writing about in the second half of this post are from the 1950s. I wonder how long they planned for them to last? Possibly much further into the future; I get the impression that when computers were a new thing, they weren't expected to change and grow obsolete so quickly.

P.S. Did you see my post about airline schedule files?

[bike4fish.livejournal.com]

I used teletypes for access to the University of Michigan's computing systems in the early 1970's, but they were on their last legs then. The low end ascii control codes, which are still around, were from the control sequences on the teletype, which effectively zeroed out the first three bits of the regular function of the key you hit after you hit the ctrl key. ctrl-M = carriage return, ctrl-J = linefeed. The fun characters were ctrl-G(bell) and ctrl-H(backspace).

Yes, I did read the earlier post. I was thinking that it was a lot easier to grep things in a flat, fixed-length record file than it would be to grep for something in the XML equivalent.

And kill bill got a serious chuckle.

[cos]

I think XML is overused and is a big pain for a lot of things it's commonly used for (like config files!). However, I do think mixed case and CSV were both good advances and generally a win over those old mainframe formats :)
(though XML has xpath, and once the tools get more widely deployed and those of us who know regexes well get as comfortable with xpath, maybe it'll be less annoying)

Control characters like those continued in their physical functions well past the teletypes, of course. In the 80s and early 90s there were still plenty of printers that obeyed them, and of course a bunch of them moved on into pre-USB serial communications.

[kirin]

In grad school, I made myself an alarm at my desk by just having a script print a bunch of ctrl-G bells to the terminal after a set length of time. Worked like a charm.