Re: IPP Validate-Job operation and its implementation in CUPS

Zdenek,

> On Oct 21, 2020, at 9:18 AM, Zdenek Dohnal <[email protected]> wrote:
> ...
> In this email I would like to ask if there can be a way how to work around such printer issues within CUPS, which can be aligned with RFC and PWG standards, and can be merged into OpenPrinting/cups project.

Aside from maybe retrying the Validate-Job request if it fails the first time, I'm not sure 

> I have several ideas:
> 
> 1) Validate-Job operation is 'only' recommended since IPP 2.0, so the backend would have printed only warning if Validate-Job failed and the IPP protocol used for communication is 2.0 or newer

Actually, while Validate-Job was listed as RECOMMENDED in IPP 2.0, IPP Everywhere restores it to REQUIRED, just as STD 92 has required it going all the way back to the IPP/1.0 experimental version.

> 2) configurable retries for Validate-Job operation - this idea came up from printer behavior (Validate-Job works after N retries) and from knowledge there are already configurable variables in backends via device uri

I'd rather it be automatic - either retry the Validate-Job operation or just move on to printing without validation.

> 3) define a specific IPP_STATUS_* enum variable for failing Validate-Job, let the backend fail if ipp_status is that variable and let error-policy handle the possible retry

I'm not keen on "supporting" broken behavior.  Usually I've tried to "gracefully degrade" in these situations, which would basically mean option 2 without the retry (just attempt to validate and continue if we don't get a valid response.

________________________
Michael Sweet