The current proposal allows a client to display a single "chooser" control to select a named preset provided by the printer, so it seems like the functionality requested here is already covered.
The difference in implementation is that right now the client is responsible for copying the Job Template attributes from the job-presets-supported collection value to the job creation request, instead of having the printer do so.
A client UI might not display controls for every job template attribute, but it can certainly copy attributes from the preset to the job creation attributes and/or to the controls it does provide.
I think having the printer copy preset attributes into the job is more complicated and somewhat problematic. It would require us to define the order of precedence, how to handle attribute fidelity, when to copy preset attributes, and amend the job creation operations to support all of it. It would probably also warrant making this registration a full specification since we'd be extending the job creation operations.
So maybe the action to take here is to clarify how the attributes are used and how a client can support arbitrary attributes in the preset without necessarily supporting those attributes in the client UI?
> On Oct 20, 2017, at 1:49 PM, Yardumian, Rick <RYardumian at ciis.canon.com> wrote:
>> Please read and send feedback on the attached Canon proposal for extending the current IPP Preset draft specification. It allows printers to apply preset job attributes that a client does not directly support. I personally find this proposal interesting and useful since one of the biggest issues with driverless printing (aka universal driver) is that typical IPP clients only support a small subset of the possible IPP printer capabilities.
>> Thank you,
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
Michael Sweet, Senior Printing System Engineer