Summary

  • In the June 1987 RFC 1013, an X11 client opened its connection with one byte: octal 102, the letter B, for most-significant-byte-first, or octal 154, lowercase l, for least-significant-byte-first. Ordinary 16- and 32-bit protocol values followed that client-selected order.
  • Images took the server's format, including its image byte order. The server performed ordinary protocol-field swapping when needed; a client with different native image order had to swap image bytes. The connection could therefore agree about window commands and still require separate care for pixels.

Suppose an application on one workstation wants to open a window on a display attached to another. It sends a connection request, then numbers for dimensions, resource IDs and other commands. The machines may store multi-byte numbers in opposite orders. Without a rule, a width can arrive looking like a different width, and the screen has no reason to guess which end of the number the sender meant. In 1987, the X Window System made the first byte of the conversation settle the matter for almost everything.

The version 11 alpha update published as RFC 1013 allowed remote clients over any reliable byte stream. For TCP it described a server for display N accepting connections on port 6000 plus N. Before the client sent version and authorization fields, it sent a byte identifying the order of 16- and 32-bit protocol values. The RFC wrote the two byte values in octal: 102 meant ASCII B, most significant byte first; 154 meant ASCII l, least significant byte first. The octal notation makes those letters the whole trick: one byte assigns the reading order for everything that follows.

For ordinary protocol fields, the client set the order and the server did the necessary swapping. Returned multi-byte values used the same chosen order, unless the protocol explicitly said otherwise. This spared an application from learning the server machine's native way of storing every number before asking for a window. It also gave the server a predictable conversion job. The first letter of the session was less a greeting than a contract about arithmetic.

Then image data arrived, and the contract changed hands. RFC 1013 assigned byte order for pixmaps and bitmaps to the server. In its setup reply the server described image-byte-order, bitmap scanline units and padding, and supported pixmap formats. The image-byte-order applied to each scanline unit in XYFormat and to each pixel value in ZFormat. A client whose native image order differed had to swap bytes to match the server's advertised format. The machine that displayed the picture got to specify how the picture traveled.

The split was practical. Ordinary command fields flowed in the client's chosen order, so the server could absorb heterogeneity at the protocol boundary. Image payloads depended on the display's actual format, so clients prepared pixels for that destination. A careless implementation could parse a window request perfectly and still send the image in the wrong order. The specification makes the hazard visible by assigning two different conversion jobs in one connection.

Byte order was only one part of the opening exchange. After the initial B or l, the client sent the X protocol version it expected and an authorization name with associated data. The server replied with its supported version, success or failure and, on acceptance, details about resources and images. The core document left valid authorization mechanisms to other arrangements. That separation matters here because the byte-order letter made the conversation readable; the server's reply told the client how to construct image data. Neither step could be guessed from the other.

The joke is that both sides were right in their own department. The client was allowed to set the grammar of the commands; the server was allowed to set the grammar of the pixels. The useful engineering question was who would do the translating. RFC 1013 answered it twice, with different workers: server for routine protocol values, client for image values. A networked window could be drawn only after each knew which part of the page belonged to the other's rules.