attachment
<div dir="ltr"><div><div><div>Hi Smith,<br><br></div>Nope - existing attributes are fine. No changes needed.<br><br></div>Cheers,<br></div>- Ira<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 Wed, Sep 6, 2017 at 5:51 PM, Kennedy, Smith (Wireless Architect) <span dir="ltr"><<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>Would these attributes be any different then the attributes that are already defined in the current draft? Or does the Set-Printer-Attributes case necessitate the need to define additional attributes?<br>
<br>
<div id="m_-5456674835995112997AppleMailSignature">
<div><span style="background-color:rgba(255,255,255,0)">Cheers,<br>
</span></div>
<div><span style="background-color:rgba(255,255,255,0)">Smith<br>
</span></div>
<div><span style="background-color:rgba(255,255,255,0)">---<br>
</span></div><span class="">
<div><span style="background-color:rgba(255,255,255,0)"><br>
</span></div>
<div><span style="background-color:rgba(255,255,255,0)"> Smith Kennedy<br>
</span></div>
<div><span style="background-color:rgba(255,255,255,0)"> Wireless Architect - Client Software - IPG-PPS<br>
</span></div>
</span><div><span style="background-color:rgba(255,255,255,0)"> Standards - PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum<br>
</span></div><span class="">
<div><span style="background-color:rgba(255,255,255,0)"> Chair, IEEE ISTO Printer Working Group<br>
</span></div>
<div><span style="background-color:rgba(255,255,255,0)"> HP Inc.</span></div>
<div style="font-family:UICTFontTextStyleBody;font-size:19px"><span style="background-color:rgba(255,255,255,0)"><br>
</span></div>
</span></div>
</div><div><div class="h5">
<div><br>
On Sep 6, 2017, at 11:45 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi Smith,<br>
<br>
</div>
I agree with Mike that the Presets white paper should define the Printer attributes<br>
</div>
for persistent Presets that are configured by the Administrator (never by a User)</div>
<div>using Set-Printer-Attributes and Presets should NOT be a subclass of template
<br>
</div>
<div>Resources.<br>
</div>
<br>
</div>
Cheers,<br>
</div>
- Ira<br>
<br>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="m_-5456674835995112997gmail_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/<wbr>blueroofmusic</a><br>
<a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/<wbr>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 <a href="tel:(734)%20944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>
May-Dec: PO Box 221 Grand Marais, MI 49839 <a href="tel:(906)%20494-2434" value="+19064942434" target="_blank">906-494-2434</a><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 Wed, Sep 6, 2017 at 1:01 PM, Kennedy, Smith (Wireless Architect)
<span dir="ltr"><<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks Ira and Mike for your discussion!<br>
<br>
In an attempt to bring this to a conclusion and get a stable draft created for review, is your consensus that, for the Presets white paper, that Set-Printer-Attributes is the method of choice? If so, then is the section 4.2 in the latest draft (<a href="https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822.pdf" rel="noreferrer" target="_blank">https://ftp.pwg.org/pub/pwg/i<wbr>pp/whitepaper/tb-ipp-preset-20<wbr>170822.pdf</a>)
adequate or suitable? And that would also indicate that we ought to remove section 4.3 that is a placeholder for defining Preset resources.<br>
<br>
Or should the Presets white paper not define a way to push a Preset definition back to the Printer? If so, then both 4.2 and 4.3 should get chopped and the use case / out of scope sections need to be updated.<br>
<span class="m_-5456674835995112997HOEnZb"><font color="#888888"><br>
Smith<br>
</font></span>
<div class="m_-5456674835995112997HOEnZb">
<div class="m_-5456674835995112997h5"><br>
<br>
<br>
> On Aug 27, 2017, at 10:34 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> wrote:<br>
><br>
> Hi Mike,<br>
><br>
> Thanks - i agree with all your points.<br>
><br>
> Shoehorning presets into Resources would always be a bit strange.<br>
><br>
> Smith had (verbally) hoped to perhaps use Resources for finer-grained<br>
> access control (i.e., "this is a preset Resource for my user group"), but<br>
> even so, there's no getting around that End Users shouldn't be doing<br>
> the Printer configuration (by whatever operations), so pushing Client<br>
> side presets to Printers from End Users just doesn't work.<br>
><br>
> I agree with your explicit precedence of attributes for Create-Printer.<br>
><br>
> Pete's original thought about Job Template resources was that they<br>
> formed a neat alternative to a lot of pre-configured Printers (color,<br>
> double-sided, etc.). I'll give this a bit more thought.<br>
><br>
> Cheers,<br>
> - Ira<br>
><br>
><br>
> 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 href="http://sites.google.com/site/blueroofmusic" rel="noreferrer" target="_blank">
http://sites.google.com/site/b<wbr>lueroofmusic</a><br>
> <a href="http://sites.google.com/site/highnorthinc" rel="noreferrer" target="_blank">
http://sites.google.com/site/h<wbr>ighnorthinc</a><br>
> mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
> Jan-April: 579 Park Place Saline, MI 48176 <a href="tel:734-944-0094" value="+17349440094" target="_blank">
734-944-0094</a><br>
> May-Dec: PO Box 221 Grand Marais, MI 49839 <a href="tel:906-494-2434" value="+19064942434" target="_blank">
906-494-2434</a><br>
><br>
><br>
> On Sat, Aug 26, 2017 at 2:45 PM, Michael Sweet <<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>> wrote:<br>
> Ira,<br>
><br>
> > On Aug 25, 2017, at 6:32 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> wrote:<br>
> ><br>
> > Hi Mike,<br>
> ><br>
> > For Create-Printer it's really nice to have a template-printer Resource<br>
> > for each supported service type.<br>
><br>
> Agreed, and for a sometimes-used admin operation with likely vendor extension attributes, I think it is appropriate.<br>
><br>
> I also think that we should define the semantics of template resources in general, i.e., the order of precedence used in creation operations:<br>
><br>
> 1. Attributes in request (highest)<br>
> 2. Attributes in resource<br>
> 3. Default attributes (lowest)<br>
><br>
> That makes it clear how a template resource is applied during a create request.<br>
><br>
> > I agree about the template-job (too heavyweight to configure). But<br>
> > we already plan that the HTTP PUT of a font to a well-known URL<br>
> > will quietly create a corresponding Resource object for that font.<br>
> > Why not do that simple HTTP PUT for job templates?<br>
><br>
> Well, while we do have HTTP PUT for creating and allocating Printer resources (as defined in IPP INFRA), that interface is also quite limited compared to using the Create-Resource operation since you cannot specify a "resource-name" different from the filename
in the PUT. So either the Printer has to pull the "resource-name" value from the file's metadata, e.g., the typeface name, and/or you use the "base name" from the URL, e.g., "<a href="http://printer.example.com/ipp/print/resources/Foo%20Bold.otf" rel="noreferrer" target="_blank">http://printer.example.com/ip<wbr>p/print/resources/Foo%20Bold.<wbr>otf</a>"
has a "resource-name" value of 'Foo Bold'.<br>
><br>
> For IPP messages we'd be limited to using the base name approach, which means UTF-8 with percent escapes in the URL (ugh).<br>
><br>
> > Pete's retired from PWG work or he'd be speaking up for Job Templates<br>
> > (they're part (in XML at present) of PWG Job Ticket spec). I think the<br>
> > MIME type of a Job Template Resource should allow application/ipp<br>
> > or text/xml.<br>
><br>
> *If* an implementation chose to support a PWG PJT (with whichever schema) we need to use a specific MIME media type for it, not just "text/xml". Also, I believe IETF currently wants us to use application-scoped media types for this kind of thing, so that
would probably mean registering "application/pwg-pjt+xml".<br>
><br>
> There is also the issue of schema versions - do we make that part of the media type (a parameter) that can be included in "resource-formats-supported" values?<br>
><br>
> > Is even the simple HTTP PUT support too much for IPP native job<br>
> > templates (i.e., wire-encoded IPP attributes, not PAPI or XML)?<br>
><br>
> The issue is how hard will it be for the Client to support them? Doing N requests (Get-User/Printer-Resources + a bunch of HTTP GET requests) to get presets (which is all Job Template resources are) is inefficient and complicated compared to looking at a
single collection attribute that is returned by the (common) Get-Printer-Attributes request that Clients already do.<br>
><br>
> I can also say we (Apple) are more likely to support the "job-presets" and "job-triggers" attributes than we are to support Job Template resources - philosophically they are better aligned with how presets and our internal trigger implementations work on
macOS, and adding support for them will be easier (since we already have the interface for querying Printer attributes) than if we have to add additional code to query and pull resources. And because there are fewer requests, the time to show the Print UI
will remain low.<br>
><br>
> Many Printers also already support Set-Printer-Attributes, so I think adding support for a couple attributes will be easier than adding all of the resource infrastructure.<br>
><br>
> ______________________________<wbr>___________________________<br>
> Michael Sweet, Senior Printing System Engineer<br>
><br>
><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div></div></div>
</blockquote></div><br></div>