Summary

  • RFC 3380 treated a supported Set-Job-Attributes request as one proposed state, not a list of fields the printer could partly accept.
  • An unsupported or conflicting value meant rejection of the whole request and no change to the Job—not cancellation of the print job and not proof about physical output.

In September 2002, Internet printing was gaining a more explicit administrative edge. IPP 1.1 could create and inspect jobs, but an end user or operator might discover a missing finishing instruction after submission. RFC 3380 offered an optional alternative to canceling and resubmitting: change attributes on the existing Job object.

That convenience had a sharp boundary. The printer evaluated the proposed attributes together with the job attributes the client left alone. RFC 3380 asked a counterfactual question: would a new job with this complete resulting set have been accepted with ipp-attribute-fidelity=true? If yes, the set operation had to be accepted. If no, the printer had to reject it and leave the existing Job unchanged. An unsupported attribute, a value the implementation could not set, or a conflict with another attribute could not be quietly salvaged by applying only the easy fields. The request was all or none.

This was more than a convenient error response. It kept the client from mistaking a partially changed job for the state it had requested. It also made the boundary observable: the response could identify attributes that failed validation, while the Job itself remained the prior state. Authorization was a separate check. The authenticated requester had to be the Job owner or an operator or administrator; permission to ask did not make an invalid combination valid.

The same document made printer-configuration changes atomic and added Get-Printer-Supported-Values to discover values a printer would accept for certain settable attributes. It also let printer-xri-supported update related URI, authentication and security descriptions together. But RFC 3380 marked the Set operations optional. A standards document describing a safe transition does not prove that a particular printer implemented it, that a client used it, or that a physical job reached paper.

The distinction matters beside RFC 3196. That guide's later verified erratum concerns when a printer may return a final response after receiving document data. RFC 3380 concerns changing a Job's attributes. Neither an accepted attribute update nor a rejected one says the document was completely received, processed, or printed. The protocol event is a receipt about state mutation, not a receipt from the machine room.

Read the primary texts: RFC 3380, IPP/1.1 Model and Semantics, RFC 2911, and RFC 3196. RFC 3380 was an optional extension; those specifications establish the contract, not deployment or interoperability.

Sources