attachment
<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Mike,<br><br></div>For Create-Printer it's really nice to have a template-printer Resource<br></div>for each supported service type.<br><br></div>I agree about the template-job (too heavyweight to configure). But<br></div>we already plan that the HTTP PUT of a font to a well-known URL<br></div>will quietly create a corresponding Resource object for that font.<br></div>Why not do that simple HTTP PUT for job templates? <br><br></div>Pete's retired from PWG work or he'd be speaking up for Job Templates<br></div>(they're part (in XML at present) of PWG Job Ticket spec). I think the<br></div>MIME type of a Job Template Resource should allow application/ipp<br></div>or text/xml.<br><br></div>Is even the simple HTTP PUT support too much for IPP native job<br></div>templates (i.e., wire-encoded IPP attributes, not PAPI or XML)?<br><br></div>Cheers,<br></div>- Ira<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Jan-April: 579 Park Place Saline, MI 48176 734-944-0094<br>May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Aug 25, 2017 at 5:20 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ira,<br>
<span class=""><br>
> On Aug 25, 2017, at 4:27 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br>
><br>
> Hi Mike,<br>
><br>
> Fine - as long as End Users don't get to use Set-Printer-Attributes.<br>
><br>
> We really need to keep "template-job" Resources. Xerox has implemented<br>
> them for 20 years in DPA-based production systems. Others have done so.<br>
<br>
</span>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.<br>
<br>
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:<br>
<br>
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),<br>
<br>
2. Present the user with a list of templates, which when selected either:<br>
a. Disable all of the user controls for the attributes; or<br>
b. Cause the Client software to download and decode the resource so that the individual controls can be set to match the template.<br>
<br>
3. When the User submits the Job, either:<br>
a. Include the resource ID in the Job Creation request; or<br>
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.<br>
<br>
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...<br>
<br>
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?!?<br>
<br>
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.<br>
<span class=""><br>
> The idea is that there's a NEW End User operation on a Printer called<br>
> Get-User-Resources that mirrors Get-Resources from System Service.<br>
><br>
> Having End Users push presets to Printers for use by other End Users<br>
> assumes the whole fine-grained access control policies of original IDS<br>
> work. Too much new ground for too little benefit.<br>
<br>
</span>Agreed.<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>___________________________<br>
Michael Sweet, Senior Printing System Engineer<br>
<br>
</div></div></blockquote></div><br></div>