Summary

  • RFC 1179 documented LPD as existing Internet practice: a TCP daemon on port 515 accepted commands about named print queues, including a command to start printing waiting jobs.
  • During Receive job, the daemon acknowledged a file subcommand, the client marked its stated byte sequence complete with a zero octet, and a second acknowledgement followed. That chain established controlled file-exchange progress; it did not establish a rendered or physically printed result.

One word was covering three events

A print job seems straightforward when viewed from the client. Select a queue. Submit a document. Wait for a success indication. Yet the networked system contains several actors that do not share one clock: the submitting program, the daemon that receives a job, the queue that holds it, the process that starts work, the formatter that interprets it, and the output device that may or may not be ready. Treating their separate transitions as one event makes a dashboard pleasant and an investigation unreliable.

RFC 1179, published in August 1990, did not try to create a general theory of successful printing. It described an existing line printer daemon protocol widely used on the Internet. The document is Informational, not an Internet Standard. Its modest scope is exactly what makes its state boundaries useful. A collection of hosts asked a daemon process on another host for services related to print jobs. The protocol named messages, file formats and acknowledgements; it did not offer a magic receipt for every downstream fact someone might wish to know.

LPD used TCP, with a daemon listening on port 515. Each daemon command took a fresh connection. A binary command code came first, followed by an ASCII printer-queue name and, when necessary, further operands. That framing tells a daemon which operation a client requests. It does not say that the operation has occurred. RFC 1179 is unusually candid about the grammar of imperatives: its command names should be read as statements made to the daemon.

The distinction matters immediately for the command called Print any waiting jobs. It starts the printing process if it is not already running. An imperative to start is neither a claim that a particular file has been selected nor a report that a device accepted toner, rendered a page or exposed output to a person. The command belongs to a different stage from the receiving of files. Keeping the verbs separate keeps their evidence separate.

Receiving a job had two acknowledgement points

The receive-job exchange made that restraint concrete. After the client gave the receive-job command, it could send subcommands for a control file and a data file. RFC 1179 required the client to wait for a daemon acknowledgement after a subcommand. A zero octet was positive; any other octet pattern was negative. This was a local response to a local instruction: the daemon had accepted or rejected that next step in the exchange.

The file itself introduced another boundary. A receive-control-file subcommand carried a byte count and a file name. The client then put the stated number of bytes on the same TCP connection. Once it had delivered those bytes, it sent a zero octet to say that the transmitted file was complete. At that point, a second acknowledgement had to occur. Receive-data-file used the same arrangement when it supplied a length.

The protocol therefore made three observations visible without merging them. First, the daemon answered the subcommand. Second, the client asserted that it had completed the declared byte sequence. Third, the daemon answered after that declaration. A positive second acknowledgement was stronger evidence than merely opening a socket or beginning a transfer. It still had a bounded object: the daemon’s handling of a specified file exchange on this connection.

It did not turn the count into an independent measure of the document. A count says how many octets the sender claimed to transmit under that subcommand. It does not say that the bytes were a valid print description, that every byte carried the intended semantic content, or that the daemon had rendered them. In the data-file case, RFC 1179 is explicit that interpretation comes from the corresponding control file. Bytes and meaning are related, but neither substitutes for the other.

The control file kept the job from being only a blob

LPD’s control file gave the daemon instructions about the data rather than treating any arriving bytes as a finished document. Its lines could identify a host, a requested user identification, a source-file name, an intended print format and further attributes. A data file could contain any 8-bit values. The control file told the daemon how to interpret the corresponding data file.

This design created another useful limit. A control-file field might name a user or a host, but the field is protocol input, not a verified biography. A job number distinguished jobs within the document’s bounded model; it did not become a permanent global identity. An M control line could request mail when printing occurred, but a requested notification is still not a proof that it was sent, received or acted on. The RFC specifies the command language, not the truth of every assertion carried inside it.

The same caution applies to queue visibility. A short or long queue-state command could report daemon state to a client, and a remove-jobs command had rules involving an agent name, user names and job numbers. Those mechanisms are useful for administration. They do not make LPD a general access-control or audit system. The RFC even confines deletion privilege in a specific way: a non-root agent cannot remove a job not owned by that user. That local command rule is not a universal account of who may see, print, release or possess a document.

A queue is a promise to try, not a page in hand

The historical lesson is less about old printers than about distributed work. A protocol designer can expose intermediate transitions so that clients do not have to imagine them. RFC 1179 exposed a receive subcommand, a declared file boundary, a daemon acknowledgement and a later command to start queue processing. Those transitions let a client diagnose where a conversation stopped.

They also demand discipline from anyone who consumes the record. A first positive acknowledgement does not prove that the promised bytes have followed. A client’s completion octet does not prove that the daemon accepted the completed file. A second positive acknowledgement does not prove that a waiting job was printed. A command to start printing does not prove device availability, document formatting, pages produced, physical collection or a business process completed.

The ordinary temptation is to hide this chain behind a single green state. The better historical reading is to keep the states joinable but distinct. A useful evidence system can say: the daemon accepted this subcommand; this sender declared this file complete; the daemon later acknowledged it; a print process was asked to begin; a separate observer saw an output event. Each sentence has an object, actor and boundary. None needs to impersonate the next one.

Sources