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.
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
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
> > ◦ Added section 4.3 (placeholder) to discuss storing presets as
> > • 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...