[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

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

Ira McDonald blueroofmusic at gmail.com
Fri Aug 25 20:27:44 UTC 2017


Hi Mike,

Fine - as long as End Users don't get to use Set-Printer-Attributes.

We really need to keep "template-job" Resources.  Xerox has implemented
them for 20 years in DPA-based production systems.  Others have done so.

The idea is that there's a NEW End User operation on a Printer called
Get-User-Resources that mirrors Get-Resources from System Service.

Having End Users push presets to Printers for use by other End Users
assumes the whole fine-grained access control policies of original IDS
work.  Too much new ground for too little benefit.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434


On Fri, Aug 25, 2017 at 2:28 PM, Michael Sweet <msweet at apple.com> wrote:

> 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
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20170825/a8475d44/attachment.html>


More information about the ipp mailing list