-
Notifications
You must be signed in to change notification settings - Fork 80
Release Printing with INFRA
One common enterprise printing configuration is to have a central print service that fans out to many, often identical, large MFPs. Print jobs are automatically held until the user goes to a convenient/nearby MFP to release the job for printing. Aside from the physical security this offers, it also appears to reduce the amount of waste prints (that are printed but never collected) which has both an environmental and financial benefit to the enterprise/planet. The PWG calls this "Release Printing" and the use case is part of the current IPP Enterprise Printing Extensions v2.0 (EPX) specification.
Such services are typically implemented using proprietary hardware and software. The purpose of this page is to collect ideas/wisdom for standardizing this functionality using a combination of the IPP Enterprise Printing Extensions v2.0 (EPX) and the IPP Shared Infrastructure Extensions v1.0 (INFRA) specifications, with potential implications for the IPP System Service v1.0 (SYSTEM) specification. Longer term this should yield appropriate content to go into errata updates of INFRA and SYSTEM as needed.
EPX defines Release Printing thusly:
Release Printing: A workflow where Release Jobs are submitted to a print service and held until the End User provides necessary information to release the Job into the 'processing' state. The nature of the necessary information can depend on the solution but might include information such as a username and password, swiping an identification card or credit card in a card reader on the Printer, or simply pushing a button. The print service can be hosted on a Physical Device or a Logical Device such as a centralized print service or print service provider.
TL;DR: new Jobs are held by default and need to be released by an End User to print them.
When all processing happens on the Printer, the Administrator can configure the Printer for this mode and the Printer will present UI (on a web interface, console, etc.) for the End User to release their Job(s) for printing. No additional IPP attributes are needed as the configuration of the Printer for Release Printing happens out-of-band.
For Infrastructure Printers, the Proxy has to know it needs to present UI, release jobs, and so forth. The current specification acknowledges this use case but does not define how the Proxy is configured - to print every "fetchable" Job as soon as they are available, or to wait for the End User to choose which Job(s) to fetch/print. Moreover, the current specification does not specify what to do about pending-held Jobs on the Infrastructure Printer - are they fetchable, does releasing a held Job assign it to the Proxy's Output Device?
We don't have a great story for how a Proxy discovers and/or provisions an Infrastructure Printer. For INFRA you just point the Proxy at a Printer URI ("ipps://printer.example.com/ipp/print"). SYSTEM adds the Register-Output-Device operation, so if you point the Proxy at a System URI ("ipps://server.example.com/ipp/system") the Proxy can send that request to get back the Printer URI to use. And the System Discovery registration document adds a DNS-SD service that can be looked up, so the Administrator can pick the System from a list which is a better UX.
What is missing is standardizing how the Infrastructure Printer/System validates the Proxy access (we have lots of choices) so that you don't attach some random Printer/malicious code masquerading as a Printer to the enterprise print service, giving an attacker unauthorized access to Job and Document data. We've been talking a little about this with the IPP OAuth Extensions specification work, but we need this to make the "onboarding" process interoperable and secure.
This is the current state of the art. If a Printer implements a Proxy then it must have a configuration option for running in "Release Printing" mode, or that must be the only mode, i.e., the vendor only implements the Release Printing mode when talking to/pulling jobs from an Infrastructure Printer. You could argue that this mode is the only one that makes sense for enterprise printers, but it limits what can be done to support printing in different network architectures and not every enterprise uses release printing.
Manual configuration also has scaling issues, and it would be nice if all vendors provided the same set of core functionality when supporting INFRA.
If the Infrastructure Printer provided an attribute describing the desired printing mode, the Proxy could query this to determine which mode to operate in. Thus, configuration would consist of only setting up the connection between Proxy and Infrastructure Printer - the Proxy (and Printer behind it) could then participate in the local enterprise printing solution fully without additional fiddling.
Proposal:
- "printer-mode-configured (type2 keyword)" and "printer-mode-supported (1setOf type2 keyword)" Printer Description attributes
- 'immediate' means Jobs are scheduled immediately unless explicitly held - this is the standard printing mode implemented by all/most Printers
- 'release-printing' means Jobs are held by default until released - this is Release Printing mode
The IPP Sample Software implements IPP Everywhere™, IPP 3D, and many other IPP standards and extensions.