Summary

  • RFC 3381 added optional IPP attributes for job progress, but every value depended on a scope: the whole job, the current document, the current copy or the sheet currently being stacked.
  • Collation changed the order in which those values advanced and reset. Even “completed” could mean processed rather than physically stacked when a device could not observe the output boundary directly.

Imagine watching a remote print job whose total impression count climbs from two to three while its current-copy count falls from three to one. Nothing has necessarily gone backward. The device may have finished one copy and started another. Change the collation mode and the same sequence of integers can locate the job somewhere else entirely.

That was the problem RFC 3381 tried to make legible. Published in September 2002 on the Standards Track, it defined four optional Job Description attributes for IPP/1.0 and IPP/1.1: job-collation-type, sheet-completed-copy-number, sheet-completed-document-number and impressions-completed-current-copy. It also defined sheet-collate, a Job Template attribute that let a client request collated or uncollated sheets.

The extension did not invent a universal percentage-complete gauge. It did almost the opposite. It exposed enough of the printer's execution model to show why one scalar was insufficient. The overall job-impressions-completed count could rise monotonically while the counter for the current document copy reset. Copy and document ordinals advanced in different orders depending on how output was assembled.

RFC 3381 drew the attributes from the PWG Job Monitoring MIB in RFC 2707. It also anticipated their use in notification content, later specified through the IPP event-notification and subscription work in RFC 3995 and RFC 3996. Moving a counter into a notification did not change its meaning. The receiver still needed the scope and ordering rules that made the value interpretable.

The document illustrated three collation regimes with the same job: three copies of two documents, each document containing three impressions. Under uncollated-sheets, one sheet was replicated through all three copies before the next sheet. Under collated-documents, the first copy of each document was completed before the second copy began. Under uncollated-documents, all copies of the first document were completed before any copy of the second.

All three paths eventually produced eighteen impressions. Their intermediate states were different. After four impressions, the current-copy counter could mean the second impression of the first document's first copy, the first impression of the second document's first copy, or the first impression of the first document's second copy. “Four have been completed” was true in every case and adequate in none of them for locating the work.

The sheet-collate attribute supplied one part of this grammar. With collated sheets, each copy kept its sheets in sequence. With uncollated sheets, copies of one sheet were produced before the next sheet. Its interaction with multiple-document-handling created logical “sets,” and some combinations were nonsensical enough that a printer had to reject the job with conflicting attributes.

Physical machinery could create another difference between monitored state and user-visible result. RFC 3381 observed that an output-bin collator might make sheets appear collated to the user even when the printing device's job-collation type was uncollated-sheets. To a monitoring application, a device with that output-bin collator could be indistinguishable from one without it. The counter described the monitored production path, not everything the user would find in the tray.

The word “completed” had its own boundary. For impressions and sheets, it normally meant stacked. But if an implementation could not detect when each sheet was stacked, the RFC allowed it to approximate stacking at the moment processing of that sheet completed. The protocol value could therefore be exact as an integer and uncertain as a physical claim. A counter of ten did not always prove that ten sheets were already present in an output bin.

This was a deliberate accommodation to observability. A specification cannot force a sensor into a device that lacks one. It can, however, state where the approximation occurs. The distinction is operationally important when a jam, finishing stage, transport path or output mechanism lies between image processing and the final stack.

The per-copy attributes made reset boundaries explicit. sheet-completed-copy-number identified the copy being stacked for the current document. sheet-completed-document-number identified the current document and was discouraged for devices that supported only one document per job. impressions-completed-current-copy counted impressions in the current copy and had to reset to zero for every new document and every new document copy.

That reset rule prevented a local counter from pretending to be a lifetime total. It also created an audit requirement. A monitoring system that stored only the integer and timestamp could mistake a valid reset for lost work. It needed the job identifier, document ordinal, copy ordinal, collation type and state transition that surrounded the sample.

RFC 3381 also preserved ignorance as a valid result. If a copy or document number was unknown, the printer returned IPP's unknown out-of-band value instead of importing the numeric minus-two convention used by some management information bases. Unknown was not zero. Zero described the initial state before the first relevant sheet; unknown said the observation was unavailable.

The difference matters because zero participates in arithmetic while unknown interrupts it. Replacing unknown with zero can fabricate a reset, a stalled job or a false starting point. Good telemetry systems keep absence, inapplicability, initial state and measured zero separate even when a dashboard would prefer one clean line.

Every attribute in RFC 3381 was optional. Clients and printers could implement any combination. A client could see the overall impression total but not the current document, or know the collation type without receiving every per-copy counter. Partial visibility was conformant. It was not permission to fill missing state with inference and report the result as observation.

The RFC updated the IPP/1.1 encoding and transport document, RFC 2910, while relying heavily on the model and semantics in RFC 2911. RFC 3196 supplied implementation guidance around that base protocol. RFC 3380, published beside it, addressed a different boundary: whether a requested set of job-attribute changes was accepted atomically. Successful mutation and observable progress were separate questions.

RFC 3381 is now obsolete, with RFC 8011 consolidating the IPP/1.1 model and semantics and RFC 8010 consolidating encoding and transport. That later status is part of the specification history. It does not prove which printers implemented the 2002 attributes, how often they used processing as a stacking approximation, or whether any named product produced correct physical output.

The older IPP design documents help locate the ambition. RFC 2567 described the needs of end users, operators and administrators. RFC 2568 explained why IPP separated objects, attributes and operations. Progress monitoring belonged in that object model: not a magical external truth, but a set of statements made by a Printer object about a Job object at defined points.

Lu Heng's minimum-initial-specification lens explains why the extension remained optional and composable. It added a vocabulary for a real monitoring problem without requiring every printer to expose every counter. His reality-layers lens supplies the warning: requested collation, internal processing, counter update, sheet movement, physical stacking and user possession are related stages, not interchangeable facts.

RFC 3381's lasting contribution was not the number three. It was the context that stopped three from lying. A counter becomes useful evidence only when the observer also knows what is being counted, where the count resets, how output is ordered and which physical boundary the device can actually see.

Sources