Re: [IPP] NODRIVER: Seeking consensus on a solution for use cases 3.2.20 and 3.2.21

Hi Smith,

I prefer Option 3 "print-quality-col".  Lots of precedent in tricky
bits of IPP and still extensible.  I agree that any single simple
new attribute (such as "print-quality-percent") won't be a good
solution.

To respond to Paul's comment about 3D Printing, I think that
the "print-quality-col" solution would be the only acceptable
one.

Question.  Would we encourage implementors to support
*both* "print-quality" and "print-quality-col" (simultaneously
present)?  Because there's a huge legacy of "print-quality"
implementation.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
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/highnorthinc
mailto: blueroofmusic@gmail.com
(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434
(to 30 April 2020) 203 W Oak St  Ellettsville, IN 47429  812-876-9970

On Fri, Mar 27, 2020 at 8:57 AM Kennedy, Smith (Wireless & IPP Standards)
via ipp <ipp@pwg.org> wrote:

> Greetings,
>
> In the last review of IPP Driverless Printing Extensions v2.0, concerns
> were once again raised about extending the set of enum values for
> "print-quality" to solve the "Manufacturer-Deployed Print Quality Mode" and
> "Administrator-Deployed Print Quality Mode" use cases (3.2.20 and 3.2.21 in
> the 20200204 published draft
> <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v20-20200204.pdf>).
> I want to see if we can hash this out via email in between meetings.
>
> Before we dive into the implementation choices, I want to focus on the use
> cases and the user experience(s) we want to support. The use cases I have
> articulated are important to HP, and I have to believe that they are also
> important to other printer vendors.
>
> The "print-quality" attribute as defined originally in IPP/1.0 (RFC 2566)
> has remained unchanged for over 20 years:
>
> 4.2.13 <https://tools.ietf.org/html/rfc2566#section-4.2.13> print-quality (type2 enum)
>
>    This attribute specifies the print quality that the Printer uses for
>    the Job.
>
>    The standard enum values are:
>
>      Value  Symbolic Name and Description
>
>      '3'    'draft': lowest quality available on the printer
>      '4'    'normal': normal or intermediate quality on the printer
>      '5'    'high': highest quality available on the printer
>
>
> Since semantically there is a linear progression from "draft" to "normal"
> to "high", a "Print Quality" UI selection control could be presented as a
> slider, or more generically as a radio button group or a pop-up or table
> list, where only one option can be chosen. The ordering of the three
> choices is clear and common sense dictates that they should be presented in
> order rather than out-of-order.
>
> Unfortunately, though, this long-standing definition doesn't provide for
> the possibility that the Printer supports more than 3 quality levels. Nor
> does it provide space for vendor-defined or site-defined levels, which have
> existed for quite some time, but always been described in terms of
> vendor-unique attributes or via legacy (non-IPP) mechanisms. I strongly
> believe that we need to find a way to allow printers to express their
> additional print quality options in a way that allows simpler UIs to
> maintain their simplicity but still allows access to these printer-provided
> non-standard print quality levels.
>
> So, my questions are these:
>
> 1. Are there any specific objections to these use cases? I believe these
> are important to all printer manufacturers, not just HP, as a way of
> expressing an important vector of product differentiation without having to
> adopt vendor-unique or site-unique attributes, which many universal clients
> ignore. This undermines efforts to move away from model-specific drivers.
>
>
> 2. Assuming agreement with the use cases, if we had a green field / blank
> sheet of paper, how to support the use cases in IPP?
>
> Option 1: Extend "print-quality" as per the current proposal
>
>
> Option 2: "print-quality-percent" as per Mike's proposal, which I don't
> think adequately addresses the use cases
>
>
> Option 3: Define a new "print-quality-col", which could contain a
> "print-quality-percent" but could also have printer-provided localized
> labels and tooltips.
>
>
> Option 4: ???
>
>
> Please share your thoughts and feedback!
>
>
> Smith
>
> /**
>     Smith Kennedy
>     HP Inc.
> */
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>