attachment

<div dir="ltr"><div>Michael,</div><div><br></div><div>Thanks for your prompt reply.</div><div><br></div><div>From a client point of view deprecating and no longer requiring is quite similar in impact - we'd need to change.</div><div><br></div><div>Is this discussion captured somewhere so that i could read up on it?<br></div><div dir="ltr"><div>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.</div><div>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.</div><br></div><div dir="ltr">It isn't the point that clients should be separating each page into a new document and get status back then, is it?<br><div>That would have impacts on collated copies and probably more things.<br></div><div>I realized only now that 2911 says multiple-document-handling "is relevant only if a job consists of two or more documents",</div><div>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).</div><div>Furthermore, i don't see a total-collation option for jobs with multiple documents at all...<br></div><div><br></div></div><div>I always saw this two-stage approach as something for advanced use-cases, like adding cover pages and whatnot in corporate settings.</div><div>(now obsoleted by pull printing, but none the less)<br></div><div>In today's world i'd argue that any use-case beyond beaming over a page or three is basically exotic.</div><div>(So while it should of course be supported, it would be nice if it wasn't at the detriment of basic usage)</div><div><br></div><div>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.<br></div><div><br></div><div>Br,</div><div>Anton<br></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den ons 6 juli 2022 kl 21:13 skrev Michael Sweet <<a href="mailto:msweet@msweet.org">msweet@msweet.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Anton,<br>
<br>
> On Jul 5, 2022, at 3:26 PM, Anton Thomasson <<a href="mailto:antonthomasson@gmail.com" target="_blank">antonthomasson@gmail.com</a>> wrote:<br>
> <br>
> Hi<br>
> <br>
> Sorry if it is not my place...<br>
> But will the capability of handling Print-Job remain part of certification at least in one or two transactions?<br>
<br>
Yes, as long as we require Print-Job.<br>
<br>
> You mention Print-Job being deprecated in #90; i can't find anything about that on iana.<br>
> Did it happen recently, as in after the deprecation of Print-URI?<br>
<br>
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).<br>
<br>
> Is it a misunderstanding, or what is the reason?<br>
<br>
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.<br>
<br>
________________________<br>
Michael Sweet<br>
<br>
</blockquote></div></div>