Ira,
> On Aug 25, 2017, at 4:27 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> 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.
Well, just because that is the way things have been done in the past by a single vendor doesn't mean we need to encourage future use of templates in the same form.
In IPP a template resource would be an IPP message containing the document, job, or printer attributes that would be used in a creation request. A Client that used such a resource would need to:
1. Lookup Printer resources using a new Printer operation (which should probably be Get-Printer-Resources, not Get-User-Resources - the resources are associated with the Printer object, not with a User),
2. Present the user with a list of templates, which when selected either:
a. Disable all of the user controls for the attributes; or
b. Cause the Client software to download and decode the resource so that the individual controls can be set to match the template.
3. When the User submits the Job, either:
a. Include the resource ID in the Job Creation request; or
b. Include the individual attributes and values from the resource, including overrides by the User without specifying the resource ID in the Job Creation Request.
It's steps 2b and 3b that bother me the most - a lot of extra requests for little benefit. And even if you decide to define the template resource as overlaying the default values for each attribute, with any other attributes in the creation request overriding the template, you make the Client either track differences from the template or send all of the attributes anyways. And if the template resource is canceled before the Client's Job Creation request is accepted, the Job will fail in a way that will require the Client to do a lot of additional processing (is resource-ids in the unsupported attributes group?) or show a (questionable) error to the User, probably requiring them to cancel the print UI and try again...
Then there is the question of storing the template resources on the Printer - since resources are managed by the System you need to first create and install the resource on the System (three operations with authorization for the System) and then allocate the resource to the Printer (a fourth operation, this time authorized for the Printer). How likely do you think it will be that the ACLs for that sequence of operations will be misconfigured?!?
I understand the reasons for wanting job/document/printer template resources. But I question the need for such complexity in 2017, particularly when such templates introduce further exceptions without an obvious benefit over Presets.
> 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.
Agreed.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer