Summary

  • RFC 1318 defined managed objects for parallel-printer-like hardware links, including Centronics, Data Products and similar physical connections used beneath higher-level MIBs.
  • Its signal tables name Power, Online, Busy, PaperOut and Fault, record a current state of none/on/off, and count transitions between on and off only where software can detect or assert a signal.
  • A hardware signal or a signal-change counter is evidence about that observed physical control line. It does not establish a document, a spooler decision, a completed print, paper content, a recipient or a human result.

A useful light was still only a light

Printer history is full of invitations to narrate from a visible indicator. PaperOut appears to announce a missing consumable. Online appears to announce availability. Busy appears to announce that the machine is working. Fault appears to announce an explanation. In an ordinary office, those labels are useful shorthand. In an audit, they are not the event itself.

RFC 1318 is a compact reminder of why. It did not define a printer-job protocol, a document queue, page accounting or a reader-facing print receipt. It defined an MIB for parallel-printer-like hardware devices: Centronics, Data Products and other physical links with similar control signals. It located that MIB at the physical layer, beneath higher services such as the Character MIB or PPP MIB. The object model is about a particular connection surface, not about every activity that may depend on it.

This placement makes a difference. A physical link can supply service to another layer without owning that layer's semantics. A character-stream service can have its own interpretation of bytes. A queueing system can have its own decision to submit or retain a job. A printer mechanism can have its own handling of marks on paper. A recipient may have a separate encounter with a copy. The physical MIB observes none of those merely by naming a signal.

The restraint was not a limitation to be repaired. It was the condition under which a manager could know what the data meant. A signal table can be trusted to answer its own question. It becomes untrustworthy only when someone makes it answer five other questions at once.

The model began below the document

RFC 1318 describes a port table and separate input- and output-control-signal tables. A port receives a local index, a hardware type and a count of represented input and output signals. The hardware types include Centronics and Data Products, but an index is not a name for a printer installation, a building, a user or a document. It is a coordinate in the management agent's table.

The separation of tables is deliberate. The input table contains entries only for signals the software can detect. The output table contains entries only for signals the software can assert. That means absence has a carefully bounded interpretation. A missing row need not describe a quiet cable, an offline printer or a false condition. It can mean that the signal is not applicable to that hardware type or not available to the software under this MIB. The first discipline is therefore to distinguish no observed entry from an observed value of off.

This is a familiar but often neglected issue in monitoring. A dashboard may show five possible labels because the MIB names five signal kinds. Yet the RFC does not promise that every port reports every kind. Hardware varies; the model leaves inapplicable objects absent. A report that treats an unrepresented PaperOut signal as “paper is present,” or an absent Fault signal as “there is no fault,” has created evidence that the agent never supplied.

The port itself has no current print-status object. It has an index, a type and counts of signal entries. Its row tells a manager how to navigate to a collection of physical-link observations. It does not say that a job has started, bytes have been accepted, a page has emerged or an application has succeeded.

A signal name did not contain a conclusion

The input and output tables use the same vocabulary: power, online, busy, paperout and fault. Each name identifies a hardware signal. The current state is one of none, on or off. That small enumeration contains an important warning: it is not a prose explanation.

Power on is a state of the named signal, not a proof of a functioning print path. Online on is not evidence that a document was offered, accepted or rendered. Busy on does not say which activity made the device busy, whether it concerns a specified job or whether progress is occurring. PaperOut on does not identify a page, a tray, an order, a user or the moment when an earlier print stopped. Fault on does not establish a diagnosis, a cause, a repair responsibility or a resulting interruption. Conversely, off does not establish a successful paper copy.

The MIB even permits none, which preserves the distinction between a signal not applicable or not reported and a signal observed as on or off. This prevents a common logic error: treating three-valued hardware representation as a binary outcome indicator. “None” is not a reassuring zero. It tells the reader to look at the scope of the port and the agent before making any operational inference.

The words are recognizable because they belong to hardware convention. Recognition is not evidence amplification. A manager who needs to know whether a physical device accepted a file, rendered a page or made a copy available needs records from the relevant queue, driver, device workflow or recipient surface. RFC 1318 offers a lower-layer signal with an owner and a time, not a chain of custody for a document.

Counting changes did not count jobs

RFC 1318 adds paraInSigChanges and paraOutSigChanges: counters for the number of times a signal changes from on to off or off to on. A transition count is a useful maintenance clue. It can make a flapping physical condition visible. It can distinguish a stable state from repeated movement. It can help an operator decide where to correlate more detailed evidence.

It nevertheless counts transitions, not events outside the signal table. Ten changes of Busy do not prove ten documents, ten pages, ten completed jobs or ten users. A PaperOut transition does not identify what paper was used before it, who supplied more paper afterward or whether the link was associated with a printing task at all. A Fault transition does not establish a root cause; it marks an observed signal boundary worth investigating.

The same warning applies to counter direction. The RFC counts both on-to-off and off-to-on changes. The number has no embedded chronology, duration, sequence of causes or relation to application events. A counter must be paired with a reading time and, when required, with separately retained samples of the signal state. Using one accumulated total as a timeline is an invitation to invent an order the object did not preserve.

This is not an argument against counters. It is an argument for attaching them to the right questions. A signal transition is actionable as a hardware observation. It becomes misleading when presented as a proxy for a result owned elsewhere.

Input, output and authority stayed apart

The split between input signals software can detect and output signals software can assert is also a split in control. An input state describes what the agent can see from the hardware connection. An output state describes a line the software can set. Neither direction automatically proves the other direction, and neither proves a higher-level acceptance.

An asserted output signal is a local action at the defined physical interface. It does not demonstrate that the remote hardware honored the intended convention. A detected input signal is a local observation. It does not demonstrate why the device produced it, whether the device was correctly configured or what the rest of a workflow did. The same name in both tables should not erase the direction, source and authority of the record.

That distinction is especially useful in operational disputes. One group may own driver behavior and output assertions. Another may operate a physical device. A third may own the print queue. A fourth may own the document or its distribution. Treating an input signal as proof of a queue decision, or an output assertion as proof of physical completion, lets one surface borrow authority from another. RFC 1318's separate tables make that borrowing visible as a mistake.

Printing was a later and separate fact

The article's title does not say that PaperOut is unimportant. It says that a PaperOut signal changed without establishing that anything had yet been printed. The distinction protects both directions of reasoning. A signal could change in a system with no relevant document. A document workflow could leave evidence at higher layers even when this particular physical signal was not represented. A printed page, if independently observed, would require evidence beyond a link-level signal table.

This boundary also separates RFC 1318 from the broader history of image exchange. A portable file representation, a transmission, host storage, a renderer, a printer mechanism and a paper copy are different stages. RFC 1318 starts lower still: it reports selected hardware control lines on a parallel connection. It cannot say what bytes represented, whether a file crossed the interface, whether a page was composed or whether a reader saw the result.

The right incident record therefore preserves the port index and hardware type, the signal name, whether it came from the input or output table, the observed none/on/off state, the counter reading, the time and the agent. If a claim reaches a job, a page, an archive or a person, add independent records with their own owners. Correlation may produce a useful explanation; substitution produces a fiction.

Sources and evidence limits

This article relies on RFC 1318, Definitions of Managed Objects for Parallel-printer-like Hardware Devices (April 1992). It supports the physical-layer MIB, port and input/output signal tables, signal applicability limits, the Power/Online/Busy/PaperOut/Fault names, none/on/off state and on/off transition counters. It does not establish a live printer, a document, a submitted or accepted job, transferred bytes, a rendered or printed page, paper content, a recipient, delivery, repair or any application outcome.