[IPP] New draft of IPP Presets posted; discussion needed on storing presets in Printer

[IPP] New draft of IPP Presets posted; discussion needed on storing presets in Printer

Michael Sweet msweet at apple.com
Fri Aug 25 18:28:14 UTC 2017


Thanks Smith!

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:
> 
> Greetings,
> 
> 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.
> 
> Cheers,
> 
> 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.
> */
> 
> 
> 
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

_________________________________________________________
Michael Sweet, Senior Printing System Engineer



More information about the ipp mailing list