Anton,
> On Jul 7, 2022, at 11: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?
The November 2021 Face-to-Face meetings had some discussion of this, which has a short mention in the minutes:
https://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20211102.pdf
This is reflected in the current working draft for IPP Everywhere 2.0:
https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve20-20220510.pdf#page=29
but the current draft of IPP/2.x Fourth Edition still lists Print-Job as required for IPP/2.0 and higher:
https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippbase23-20220428.pdf#page=13
Ultimately, the current consensus is that Print-Job is "not recommended" for Client usage and the best practice is to use Create-Job and Send-Document, as stated in the current IPP Implementor's Guide:
https://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf
> 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.
There are several known issues with Print-Job, specifically:
1. Timeouts with low-end consumer inkjet printers.
2. No reliable way to monitor job status - don't know job-id until submitted.
3. No reliable way to cancel an in-progress job - terminating a Print-Job request can have side-effects ranging from an extra error page printed by the Printer to the Printer firmware resetting (crashing) or hanging until the TCP connection timeout (300 seconds by default).
Many of these are arguably an issue of implementation quality, but since Create-Job and Send-Document have been required for IPP Everywhere since day one and AirPrint since 2012, it is hard to find an IPP printer today that doesn't support them. And Create-Job and Send-Document don't have the above issues (even timeouts, strangely...)
> 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.
>> It isn't the point that clients should be separating each page into a new document and get status back then, is it?
No, certainly not. Multiple page/copy jobs are a given, the issue is simply that Print-Job doesn't offer the level of control and/or access to reliably print something, monitor the job's progress, and (if necessary) cancel the job.
> 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...
Please use RFC 8011 (STD 92), which updates/clarifies a LOT of things in 2911. In particular, "multiple-document-handling" has always conflated copy collation and how multiple documents are handled, and a separate (now obsolete) attribute *also* specified whether copies should be collated. As a result, we just decided to use "multiple-document-handling" to specify the kind of collation to do for copies.
________________________
Michael Sweet
-------------- 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/889c22a9/attachment.sig>