Hi Anton,
There is discussion of the advantages of Create-Job / Send-Document over Print-Job in the IPP Implementor's Guide v2 (http://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf <http://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf>).
If your client has a very long timeout before failing the connection, it doesn't support monitoring the Job status while the Job is in the 'processing' state, and/or it has no need to cancel a job in progress, then Print-Job is probably adequate. But for clients that are trying to provide a more "live" and active experience, Print-Job is inferior to Create-Job / Send-Document for printers that don't send a response until the Job has completed processing.
More below,
Smith
/**
Smith Kennedy
Vice Chair, IEEE ISTO Printer Working Group
HP Inc.
*/
> On Jul 7, 2022, at 9:09 AM, Anton Thomasson <antonthomasson at gmail.com> wrote:
>> Michael,
>> Thanks for your prompt reply.
>> From a client point of view deprecating and no longer requiring is quite similar in impact - we'd need to change.
>> Is this discussion captured somewhere so that i could read up on it?
> I'd be sad to see it go, since it has been working quite well for me (even with raster formats) and kept the client simple.
> I'd like to offer something more substantial than this knee-jerk reaction if it still sounds like a bad idea after reading the background.
There is discussion of the advantages of Create-Job / Send-Document over Print-Job in the IPP Implementor's Guide v2 (http://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf <http://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf>).
If your client has a very long timeout before failing the connection, it doesn't support monitoring the Job status while the Job is in the 'processing' state, and/or it has no need to cancel a job in progress, then Print-Job is probably adequate. But for clients that are trying to provide a more "live" and active experience, Print-Job is inferior to Create-Job / Send-Document for printers that don't send a response until the Job has completed processing.
>> It isn't the point that clients should be separating each page into a new document and get status back then, is it?
No, and I'm glad that nobody has done that. 😊 It is unnecessary.
When a Client does a Create-Job, if successful, it gets the "job-id" in the response. It can then immediately start polling or register for events on that Job using the "job-id", and even cancel the Job before the document was submitted. You can't do that with a Print-Job because the document is submitted before the "job-id" is returned in the response.
> That would have impacts on collated copies and probably more things.
> I realized only now that 2911 says multiple-document-handling "is relevant only if a job consists of two or more documents",
> but this is the only way i could see achieving collated copies on the 20+ printers i have dumps from (and it has been working well).
> Furthermore, i don't see a total-collation option for jobs with multiple documents at all...
>> I always saw this two-stage approach as something for advanced use-cases, like adding cover pages and whatnot in corporate settings.
> (now obsoleted by pull printing, but none the less)
> In today's world i'd argue that any use-case beyond beaming over a page or three is basically exotic.
> (So while it should of course be supported, it would be nice if it wasn't at the detriment of basic usage)
>> I can't help but hope future presence of this operation is based on its own merits, not in mirroring other job types that would have a harder time supporting it.
Again, read IPP Implementor's Guide v2 for a good discussion of the advantages of using Create-Job / Send-Document, which is used by all of the most widely used clients, for the reasons discussed in there. If you have further questions, please bring them to us!
>> Br,
> Anton
>>> Den ons 6 juli 2022 kl 21:13 skrev Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>>:
> Anton,
>> > On Jul 5, 2022, at 3:26 PM, Anton Thomasson <antonthomasson at gmail.com <mailto:antonthomasson at gmail.com>> wrote:
> >
> > Hi
> >
> > Sorry if it is not my place...
> > But will the capability of handling Print-Job remain part of certification at least in one or two transactions?
>> Yes, as long as we require Print-Job.
>> > You mention Print-Job being deprecated in #90; i can't find anything about that on iana.
> > Did it happen recently, as in after the deprecation of Print-URI?
>> We are not deprecating the Print-Job operation yet, but the current draft of IPP Everywhere 2.0 no longer requires it. Similarly, the FaxOut service (PWG 5100.15) does not include a Print-Job operation, and there is no corresponding one-step scan operation in the Scan service (PWG 5100.17).
>> > Is it a misunderstanding, or what is the reason?
>> Print-Job doesn't work well with streaming printers (i.e. PWG Raster, PCLm, Apple Raster), since there is no reliable way to monitor or manage the jobs while they are being sent to the printer.
>> ________________________
> Michael Sweet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20220707/57cb780a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20220707/57cb780a/attachment.sig>