[IPP] Request for Consideration: Updates to IPP INFRA Job Handling

[IPP] Request for Consideration: Updates to IPP INFRA Job Handling

Soemin Tjong stjong at exchange.microsoft.com
Wed Aug 13 19:18:56 UTC 2025


Dear PWG IPP Workgroup,

Thank you for your ongoing work on the IPP INFRA specification. We greatly value the workgroup's commitment to robust standard. We'd like to raise two challenges we've encountered with the current IPP INFRA specification and propose updates for your consideration that could improve flexibility and resilience in job handling workflows.

Challenge 1: Strict Ordering of Acknowledge-Job Before Fetch-Document

Current Behavior:
Section 5.3 of the IPP INFRA specification can be interpreted as requiring that Acknowledge-Job be called before Fetch-Document. If a job is already assigned to another Output Device, any subsequent Fetch-Document request results in a client-error-not-possible status.

Use Case:
We are exploring workflows where an Output Device may wish to defer acknowledgment until after the document has been retrieved and optionally reviewed by a human operator (e.g., at the printer's control panel). This allows for inspection of job content, size, or security compliance before committing to print.

Proposed Update:
We suggest clarifying and extending the specification to support deferred job acknowledgment, allowing Fetch-Document before Acknowledge-Job.
1.        Amend Figure 4 with a note clarifying that implementations MAY support workflows in which Acknowledge-Job can occur after Fetch-Document.
2.        Amend Section 5.3 with a note that while Acknowledge-Job remains the required operation to formally assign a job to an Output Device, a compliant Infrastructure Printer MAY allow the Output Device to perform Fetch-Document for unassigned jobs prior to acknowledgment, for the purpose of job inspection or deferred commitment.


Challenge 2: No Mechanism to Release Acknowledged Jobs

Current Behavior:
Once a job is acknowledged, it is irrevocably assigned to that Output Device, even if the device never prints it. This can lead to stalled jobs or confusion, especially in pull-print environments.

Use Case:
We've identified scenarios where a job may need to be released after acknowledgment but before printing is completed, such as when the device encounters compatibility issues or experiences operational problems.

Proposed Update:
We propose introducing a new operation: Unacknowledge-Job, to allow an Output Device to release a previously acknowledged job.
1.        Add new OPTIONAL operation: Unacknowledge-Job
o   MAY be supported by the Infrastructure Printer.
o   MUST only succeed if:
?  The requesting device is the one that acknowledged the job.
?  The job is not in a final state.
o   Upon success, the job returns to the unacknowledged state and becomes eligible for reassignment.
2.        Amend Section 5.3 with a note that if supported, the Infrastructure Printer MAY also allow the Output Device to call Unacknowledge-Job before printing has completed, to release the job back for reassignment. This enables user-driven or device-driven cancellation scenarios without stalling the print job.

We welcome any feedback or alternative suggestions the PWG Workgroup may have.  Thank you for considering these enhancements to better support flexible and user-centric printing workflows. We believe these updates could benefit the community.

Thanks,
Soemin
Universal Print, Microsoft

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20250813/4c7f70fb/attachment.html>


More information about the ipp mailing list