Some comments on the discussions about how to store presets and triggers:
1. Printer/server-side Presets should necessarily be managed by an operator or administrator and are NOT per-user - that's what Client-side presets are for. So I do not agree with Ira about the operation for this - I think Set-Printer-Attributes is absolutely the right way to do this, just as we do for ICC profiles, metadata (location, organization, etc.), etc.
2. A Job (or Document) Template resource (as envisioned by PWG 5108.03: MFD Resource Service) resembles a Preset, but is not Client-friendly since there is no way for the Client to discover or retrieve the contents of the resource from the Printer (just the System). Changing the "job-presets" attribute to be a "preset-name", "resource-id", and "resource-data-uri" (for the client to access the template) would allow the Client to discover and retrieve the contents but seems like a step in the wrong direction since it is more complicated, resource intensive, slower, etc.
Personally I would like to see us focus on using resources for things that cannot be expressed/encoded directly in IPP: forms, fonts, ICC profiles, logos/images, etc. With that in mind, I'm thinking that we should drop the 'template-xxx' values for "resource-type" (no templates for documents, jobs, or printers) and just add a "resource-ids (1setOf integer(1:MAX))" member attribute to "job-presets" to instruct a Client to include the numbered resources in the Create-Job or Print-Job/URI operations for other types of resources.
> On Aug 22, 2017, at 5:22 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> I have just posted a new draft of IPP Presets:
>>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822.pdf>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822.odt>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822-rev.pdf>https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822-rev.odt>> Changes include:
>> • Extensively updated structure of section 4 “IPP Presets Definitions”
> ◦ Added section 4.2 to discuss storing presets using Set-Printer-Attributes
> ◦ Added section 4.3 (placeholder) to discuss storing presets as resources
> • Added “Client Implementation Recommendations” section
> • Added “Conformance Requirements” section
> • Added “IANA and PWG Considerations” section
>> As you can see, there remains an open issue of how to best support a Client's ability to store presets in a Printer. Ira articulated in our last IPP WG meeting that there were precedent and protocol congruency issues with using Set-Printer-Attributes for doing this. If advocates for these competing methods could describe their particular perspectives, that would help to resolve this aspect of the Presets ecosystem.
> 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.
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
Michael Sweet, Senior Printing System Engineer