Uli,
> On Mar 1, 2024, at 3:59 PM, Uli Wehner <ulrich.wehner at ricoh-usa.com> wrote:
>> Mike,
>> Here are my thoughts.
>> Since this is just release printing rather than pull printing, it is essentially a form of direct printing. (direct as in from a workstation to the printer). I see no need to define multiple "printers".
The IPP definition of "Release Printing" is broader than the typical vendor feature and includes traditional "push" PIN printing and "pull" printing from a print server. One of the goals of INFRA has always been to standardize the "pull printing" interface between printers and print servers, as the various providers of such solutions have needed to implement a variety of hacks to support heterogeneous environments...
Historical background: At least one IPP-based release printing implementation, for reasons of backwards-compatibility with the original CUPS/AirPrint "de-spool one job at a time" implementation, will accept jobs from the Client and then move them to the 'completed' state once they are transformed/queued up for printing on an Output Device. The goal there is to get all of your documents in the print queue ready on the print server, then walk over to the printer and release the jobs for printing.
The EPX update at least allows the Client to know that release printing is being used and to proceed to the next document in the local queue when it sees the remote job on the Printer is in the 'pending-held' state. Theoretically that should also be enough for the Proxy, and the 1.1 update of INFRA allows held jobs to be fetched for this to work, but that is the question this thread is attempting to answer ("Is it enough for the Proxy to see a Job is held to know not to immediately print it?")
> As such, I feel the user should be able to choose if they need the job to print before they get there, say when it is a large job or if there are many, just to keep the time waiting at the printer down.
Every site has different requirements or goals. Release ("pull") printing where the user has to go to a printer to release and collect their printouts has long been marketed as both a security and a cost saving solution, and sites that adopt such a solution will not want users overriding the settings and/or directing a job to a specific printer.
> If security or privacy is a concern, then release printing would be appropriate. Maybe with a default set by the admin. My choice would be to hold the job.
> I feel the job should be held at the printer, rather than at the workstation, just to make sure the job can be released if the user closes the lid on their laptop, for example. Provided the printer has the resources to do that.
> For cheaper printers it may be necessary to hold the job at the workstation.
For EPX the Client sends a Job to a Printer and it will hold it for the user if requested (job-release-action and/or job-password/-encryption).
For INFRA the Client sends a Job to an intermediate print server (the Infrastructure Printer), which either holds the Job or allows it to be fetched by the Proxy/Output Device for immediate printing.
In both cases the Client has sent the Job off-device so it doesn't matter whether the lid is closed, etc. (although at least for macOS/iOS that really doesn't affect things due to how printing is implemented there...) In both cases the Client will know whether know that the Job will be explicitly held (job-release-action, job-password/-encryption and the corresponding default and supported values).
The question for INFRA is how we want to configure the desired operating mode of the Infrastructure Printer and Proxy - immediate printing, optional release ("pull") printing, or mandatory release printing? Option 1 adds another attribute, option 2 relies on the Job state and job-release-action/job-password values.
________________________
Michael Sweet