Ulrich,
> On May 23, 2019, at 5:16 PM, Uli Wehner via ipp <ipp at pwg.org> wrote:
> ...
> What we see is that IPP is considerably slower than Socket 9100 printing. Socket 9100 printing allows the server to grab all the jobs and put a @PJL JOB wrapper around the individual documents and essentially prints them as one PJL job.
OK, so just to be clear: are you comparing unencrypted port 9100 (raw) socket printing with a vendor PDL to IPP or IPPS using the same vendor PDL or a different one?
From the standpoint of expectations, I would expect a SMALL overhead due to the initial application/ipp messages (Create-Job, Send-Document + document data vs. just sending the document data over the socket). If TLS is used there is often a measurable slowdown as well, especially on older hardware.
> Is there a way to do this using IPP or IPPs for this particular use case?
If the IPP printer reports support for the PDL (e.g. "application/vnd.hp-pcl"), then you can do the same optimization over IPP. But it *is* important to determine whether the destination printer supports a given PDL over IPP since older hardware has historically had an issue accepting legacy PDLs over IPP (things are better today than 10 years ago, but still...)
> Obviously the user did not create an “IPP-JOB” that contains multiple documents, but rather multiple Jobs that contain only one document each.
> The client on the printer only shows a job list to the user so there is really no way the client could create the “IPP-Job” after the fact?
>> Is there a known way for the server that sends those individual jobs to the printer to do something similar to putting a @PJL JOB wrapper around the documents to avoid the unnecessary traffic, certificate exchanges, etc. for an IPPs job?
The server is free to do whatever it deems best with the submitted documents, including merging them for sending to an output device. If the server implements an IPP Printer (which sounds likely from your initial description) then it needs to maintain separate state for the submitted jobs, but how they are then sent to the output device is an implementation detail.
> Would it make sense to have the server create an IPP JOB that contains all the previously separate jobs?
That is certainly one valid implementation when sending the print jobs to the output device.
> Please let me know what you think. If there already is a known way to do this, great, if not, maybe this is a good idea?
>> Just to clarify, this is not a Ricoh specific issue. Our particular offering for this use case does not suffer from this problem.
>> Vendor B is ready to make a change to how this is handled when IPPs is used, they just don’t see IPP supporting this use case. What is the “right way” to solve this?
IPP is about providing consistent semantics with a standard interface. It does not dictate HOW those semantics and interfaces are implemented, just that (from the outside/Client) the interface looks and works the same. IPP even talks (a little) about how jobs submitted via other protocols (port 9100, LPD, etc.) can be reflected as IPP jobs (to show state), and CUPS provides an LPD listener (disabled by default) for accepting jobs over LPD (which then become IPP jobs). I've even seen sites configure socket listeners (via xinetd previously, now systemd) to emulate port 9100 printing to particular CUPS (IPP) print queues, again creating IPP jobs.
So yes, IPP can absolutely support this use case, both as you've described with the server pushing the content to printers and (more recently) using the IPP Shared Infrastructure Extensions (PWG 5100.18) to pull the content.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer