Hi Mike,
For Create-Printer it's really nice to have a template-printer Resource
for each supported service type.
I agree about the template-job (too heavyweight to configure). But
we already plan that the HTTP PUT of a font to a well-known URL
will quietly create a corresponding Resource object for that font.
Why not do that simple HTTP PUT for job templates?
Pete's retired from PWG work or he'd be speaking up for Job Templates
(they're part (in XML at present) of PWG Job Ticket spec). I think the
MIME type of a Job Template Resource should allow application/ipp
or text/xml.
Is even the simple HTTP PUT support too much for IPP native job
templates (i.e., wire-encoded IPP attributes, not PAPI or XML)?
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/blueroofmusichttp://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 5:20 PM, Michael Sweet <msweet at apple.com> wrote:
> 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
>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20170825/e1c2c976/attachment.html>