Hi Mike,
It seems to me that Canon's proposal is simply to require that the Client pass back to the Printer the "preset-name" if one is chosen. But if I understand your feedback, if the Client provides the "preset-name" in the Job Creation operation, then we have to be clear about which attribute value takes precedence when one value is also included in the Job Creation operation and is also present in the Preset. This might arise if a user selects a preset and then makes further selections that effectively overwrite the value(s) listed in the preset.
I like your alternative, because it keeps things simpler. But from a purely PWG / certification / compliance point of view, I'm not sure how we would go about certifying that the Client will behave properly.
As you said, let's please discuss at this week's call.
Smith
/**
Smith Kennedy
Wireless Architect - Client Software - IPG-PPS
Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
Chair, IEEE ISTO Printer Working Group
HP Inc.
*/
> On Oct 20, 2017, at 1:59 PM, Michael Sweet <msweet at apple.com> wrote:
>> Rick,
>> 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:
>>>> Hi,
>>>> 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,
>> Rick
>> <IPP_Preset_improvement_proposal_20171020_E.pptx>_______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20171023/3d6f3945/attachment.p7s>