Rick,
What Smith said.
Additionally, Apple (in CUPS) is in the process of implementing support for the job-presets-supported attribute, which will include support for arbitrary IPP attributes.
> On Dec 4, 2017, at 8:19 PM, Kennedy, Smith (Wireless & Standards Architec) <smith.kennedy at hp.com> wrote:
>> Hi Rick,
>> I'm sorry the Canon posting to the IPP WG reflector didn't go through. Looking in my own client, I don't see it. I checked the moderator request page in the list server's administrator page for the IPP WG, but I don't see any pending messages that were blocked. Posting requires subscription to the list, which is unencumbered by any moderator approval and doesn't require membership in the PWG.
>> However, to briefly respond to Canon's request that the IPP Presets registration document should be updated to say that the Client MUST return "preset-name" because there is the suspicion that the Client might not send unsupported attributes listed in the preset, I do not understand why Canon believes this actually resolves Canon's concerns:
>> • Even if a Client supports "job-presets-supported" insofar as it presents the preset choices in its print dialog UI, it seems nearly as likely that a Client might choose to not return "preset-name" as any other attribute.
> • As we discussed in the IPP WG, the Client is supposed to still allow the User to make individual choices after selecting a Preset. If the Client returns "preset-name", it becomes ambiguous at what point the "preset-name" still applies if the user continues to make individual choices. This could cause problems on the Printer because it may make choices based on "preset-name" that are no longer germane based on the rest of the User's choices as conveyed via the Job Template attributes.
> • A vendor may create its own vendor-specific Job Template attribute equivalent to "preset-name" (such as "canon-preset-name") and use that, which is as likely to be conveyed as a standard "preset-name".
> • Some client vendors have already expressed support for sending all the attributes in a preset, including the vendor-specific ones. We have no Client vendors that have expressed an objection to doing this. Are you aware of any clients that are opposed to this?
>> This is basically why we came to the state of IPP Presets as it exists today, mandating that the Client send all the attributes in the Preset, whether or not the Client supports them via UI controls. Is there something that I or others in the IPP WG have missed?
>> Cheers,
>> Smith
>> /**
> Smith Kennedy
> Wireless & Standards Architect - IPG-PPS
> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
> Chair, IEEE ISTO Printer Working Group
> HP Inc.
> */
>>>>> On Dec 4, 2017, at 5:49 PM, Yardumian, Rick <RYardumian at ciis.canon.com> wrote:
>>>> Hi,
>>>> Canon Japan emailed feedback on the IPP-Presets spec last Friday (12/1) but the IPP mail archive doesn't show it yet so I'm resending Canon's feedback.
>>>> Canon wants to add the specification of passing "preset-name" strings to the printer, so that user can use unique function of printer, that is difficult to define as standard.
>>>> Alternatively, Smith added following description.
>>>> "A Client MUST copy all Preset member attributes (except "preset-name") from the selected Preset to the Job Creation Request, either with the values from the Preset or alternate values subsequently chosen by the User.
>> This includes member attributes that the Client does not natively support."
>>>> "A Client SHOULD list available Presets by name wherever it presents printing choices to the User. The Presets might have originated in the Printer or they might be local to the Client. When a User selects a Preset, the Client copies all Preset member attributes to the Job Creation Request.
>> Client implementers might want to consider appropriate behavior in response to the User changing a setting and then the User chooses a Preset that overrides that earlier selection.
>> The Client could notify the User that the setting will be changed.
>> Alternately, the Client could apply the Preset but not change the setting changed by the User, or let the selected Preset overwrite the previous User selection."
>>>> For this description, we pointed out "the data size of the Presets could be quite large."
>>>> So,
>> "Our concern is that client may end up NOT supporting Presets feature because of the issues above."
>>>> Above problem, we think WG have not done enough discussion.
>> As we interviewed some client members, they are thinking of some limitation for implementation of IPP preset.
>> This means they are going not to be compliant with "A Client MUST copy all Preset member attributes".
>>>> We are afraid it depends on client implementation.
>>>> These are reasons we cannot agree current IPP Preset Registration.
>>>> Our requests are,
>>>> 1. Please include "preset-name" again.
>> We heard the major reason for rejected is that adding the "preset-name" make printer implementation complex.
>> But, for non-support printers, only skipping "preset-name".
>>>> 2. Please answer, or more discuss about depending on client implementation problem.
>> Again, we are afraid client may NOT support ALL COPY, or IPP PRESET itself.
>>>> Best regards,
>> Rick Yardumian, Canon
>>>> -----Original Message-----
>> From: ipp [mailto:ipp-bounces at pwg.org] On Behalf Of Michael Sweet
>> Sent: Thursday, November 16, 2017 7:25 PM
>> To: PWG IPP WG Reflector
>> Subject: [IPP] IPP Last Call of IPP Presets Registration (Ends 10pm December 1, 2017)
>>>> All,
>>>> This message begins the IPP Last Call of the IPP Presets registration which is available at the following URLs:
>>>>http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipppreset-20171116.pdf>>http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipppreset-20171116.odt>>>> Please review this registration and respond to the IPP mailing list (reply-all to this message is fine) with any feedback you have for the proposed registration.
>>>> This IPP Last Call ends at 10pm PT on December 1, 2017.
>>>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer
>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer