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

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

Uli Wehner ulrich.wehner at ricoh-usa.com
Thu May 23 21:16:27 UTC 2019


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)
ulrich.wehner at ricoh-usa.com

[cid:image001.png at 01D51189.D810D070] <http://socialmedia.ricoh-usa.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190523/42edc6e6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2212 bytes
Desc: image001.png
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190523/42edc6e6/attachment.png>


More information about the ipp mailing list