[cups] [Printing-architecture] IPP Validate-Job operation and its implementation in CUPS

[Zdenek Dohnal]

Hi Mike,

thank you for the comments!

I'll implement both approaches for option 2 (validate two times and end
with error if fails x validate once and move to printing no matter of
the result), see what will work for the customer and then create PR in
Openprinting/cups for review.

Thank you again and have a nice day!

Zdenek

On 10/21/20 10:49 PM, Michael Sweet wrote:
> Zdenek,
>
>> On Oct 21, 2020, at 9:18 AM, Zdenek Dohnal <zdohnal at redhat.com> 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
>
>
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C