Subject: [IPP] asking for advice on how to best print multiple jobs/documents when using IPP compared to say 9100 with PJL

From: Uli Wehner via ipp <[email-masked]>
Date: Thu, 23 May 2019 21:16:27 +0000

Hi all,

I have been asked to find out if there is a way in IPP to speed up the way multiple small jobs print when they are all released at the same time.

Use case is encrypted pull printing/ follow-me printing.

Printers are made by vendor A
Server software is made by Vendor B
Printer embedded client is made by Vendor C

User prints all day long and sends their jobs to a server that holds all the user's jobs. Jobs may be sent via LPR, Socket 9100, IPP, or any other method from multiple operating systems.
User walks up to a printer with a 3rd party embedded software that lets them see their jobs on that server. User selects several or all of their jobs, and releases them for print.
The server then uses IPP or IPPs to push the jobs to the printer.

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.

Is there a way to do this using IPP or IPPs for this particular use case?
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?

Would it make sense to have the server create an IPP JOB that contains all the previously separate jobs?

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?

regards

Uli Wehner
Sr Technology Specialist, Technology Solutions Support (TSS)
Software Enterprise Support Center
Office Services Business Group

Ricoh USA, Inc. (RUSA)
4667 North Royal Atlanta Drive
Tucker, Georgia, 30084
Phone: 770-621-1329 (office)
Cell:     404-337-9948 (cell)
[email-masked]

 <http://socialmedia.ricoh-usa.com/>

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet via ipp <[email-masked]>
Date: Fri, 24 May 2019 08:39:47 -0400

Ulrich,

> On May 23, 2019, at 5:16 PM, Uli Wehner via ipp <[email-masked]> wrote:
> ... 

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?
>  

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.
 
> 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