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

Hi,

Note that IPP/2.0 reducing Validate-Job from REQUIRED is a known technical
error.

IPP/2.0 (or any other later IPP spec) CANNOT reduce any REQUIRED operation
conformance from IETF Standard IPP/1.1 (STD92/RFC 8010/RFC 8011).

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*








*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email protected]
<[email protected]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*


On Wed, Oct 21, 2020 at 4:49 PM Michael Sweet <[email protected]> wrote:

> 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
>
>
>
> _______________________________________________
> Printing-architecture mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>

_______________________________________________
Printing-architecture mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture