attachment

<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Mike,<br><br></div>Thanks for both replies.  I got stalled on editing for a few days, but<br></div>I did get a lot of this latest thinking in on Monday and Tuesday and<br></div>will return to editing this weekend.<br><br></div>I agree with all of your comments.<br><br><br></div><div>Pedantic DPA background stuff:<br><br></div>ISO-10175 Part 3 defines the Create operation on pages 10 to 15,<br>which normally results (for a Printer object) in a Printer with initial <br>state of 'unknown' (not an out-of-band value).<br></div></div><br></div>ISO-10175 Part 1 defines "printer-state" on pages 185 to 186 with<br></div>a long list of values (most of which were moved CORRECTLY to<br></div>"printer-state-reasons" in IPP) including the indeterminate state<br>of 'unknown'.  <br><br>ISO-10175 Part 1 defines "current-job-state" on pages 125 to 126, <br>also including 'unknown'.<br><br>In DPA implementations at a printer vendor where I once consulted, <br>'unknown' was used as the initial state result of a Create operation <br>for either a Printer or a Job, because they wanted Create to return<br>quickly.<br></div></div><br></div>Cheers,<br></div><div>- Ira<br></div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></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, Sep 9, 2016 at 12:00 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 Sep 6, 2016, at 8:25 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br>
><br>
> Hi Mike,<br>
><br>
</span><span class="">> Further thoughts about "resource-printer-id" and "resource-job-id".<br>
><br>
> Delete them.  Several Printers and/or Jobs could need a Resource<br>
> (and would have a pointer to indicate that), but the Resource should<br>
> NOT have pointers.  That is, all Resources are (as we agreed) of<br>
> System scope and can only be managed (or state affected) by the<br>
> System Service.<br>
<br>
</span>That makes sense for Jobs.  I'm not sure for Printers, where ICC profiles, icons, etc. might very well be Printer-specific.<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>___________________________<br>
Michael Sweet, Senior Printing System Engineer<br>
<br>
</div></div></blockquote></div><br></div>