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

Hi Zdenek,

A major update of IPP/2.0 is one of the primary projects for 2021 for the
IPP WG,
to align with the major revisions of Driverless, Enterprise, and Production.

We hope to move away from long internal lists of attributes and operations
and
instead move to a higher-level of named specs.

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 Thu, Oct 22, 2020 at 2:08 AM Zdenek Dohnal <[email protected]> wrote:

> Hi Ira,
>
> thanks for the heads-up! I only checked IPP 2.0 standard and didn't follow
> documents created later, which is a mistake...
>
> Zdenek
> On 10/22/20 2:48 AM, Ira McDonald wrote:
>
> 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 WG Secretary - IEEE-ISTO Printer
> Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF
> Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc
> http://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
>>
> --
> Zdenek Dohnal
> Software Engineer
> Red Hat Czech - Brno TPB-C
>
>

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