attachment-0001

Hi Mike,<br><br>Several thoughts.<br><br>I was not a proponent a year ago of security alerts<br>in Printer MIB - I think they&#39;re an architectural error<br>and belong in an appropriate IETF Ops &amp; Mgmt Area<br>MIB.<br>
<br>I&#39;d rather *delete* the security alerts from this spec<br>(and let Common Log spec talk about them instead).<br><br>About events and transient states.  RFC 2566 and<br>RFC 2911 enshrined *lots* of very short-lived transient <br>
states in printer-state-reasons (from the service level) <br>and defined lots or Printer MIB alert values for<br>printer-state-reasons.<br><br>The specific new alerts for Scanner and Fax Modem<br>are just as self-descriptive (and clear in my opinion)<br>
as existing Marker and Input events.  I&#39;ll write the<br>sentence for each, but it won&#39;t (and inherently can&#39;t)<br>further qualify when to report them - the answer is:<br>when they occur and the implementation supports<br>
reporting them in prtAlertTable.<br><br>If an implementation does NOT support showing<br>prtAlertTable content in &quot;printer-state-reasons&quot;, then<br>it doesn&#39;t.<br><br>Given the terrible report/error/warning prefixes (which<br>
are not and *could* not be IANA registered, by very their<br>format) from IPP/1.0 onward, the &quot;pollution&quot; of<br>printer-state-reasons with stuff of minimal value for<br>automated behavior is long-standing.<br><br>
Comments?<br><br>Cheers,<br>- Ira<br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Chair - TCG Embedded Systems Hardcopy SWG<br>
IETF Designated Expert - IPP &amp; Printer MIB<br>Blue Roof Music/High North Inc<br><a 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>Christmas through April:<br>  579 Park Place  Saline, MI  48176<br>  734-944-0094<br>May to Christmas:<br>  PO Box 221  Grand Marais, MI 49839<br>
  906-494-2434<div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><br>
<br><br><div class="gmail_quote">On Sun, Sep 18, 2011 at 6:35 PM, Michael Sweet <span dir="ltr">&lt;<a href="mailto:msweet@apple.com">msweet@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">Ira,<div><br></div><div>Given the inconsistencies I&#39;ve seen in recent years with even the keywords defined in RFC 2911, I really think we need to provide specific descriptions for each new keyword, otherwise they won&#39;t get used (or won&#39;t get used properly).</div>
<div><br></div><div>In addition, I think we want to document which new keywords are not appropriate for use with printer-state-reasons (even if they have to be registered for that attribute), simply because some are not persistent/present state but instead are really identifiers for sporadic events.  We don&#39;t want &quot;idiot lights&quot; that need to be reset, and we don&#39;t want clients that poll the printer on the off chance they&#39;ll see a particular keyword show up in printer-state-reasons because the printer chose not to support printer-alerts.</div>
<div><br></div><div>(and FWIW I think we want IPP Everywhere to require printer-alert and printer-alert-description...)</div><div><div></div><div class="h5"><div><br><div><div>On Sep 16, 2011, at 9:47 AM, Ira McDonald wrote:</div>
<blockquote type="cite">Hi Mike,<br><br>Sure I can add a brief description for each new alert code.<br><br>But I note that this has never been done before in either IPP PSX <br>or Printer MIB itself (arguably a Printer MIB deficiency).<br>
<br>Note that, by IPP PSX precedent, ALL IANA Printer MIB alert codes<br>
are available in the REQUIRED &quot;printer-state-reasons&quot; attribute (by<br>direct transform from the IANA Printer MIB registry).<br><br>This supports wider interoperability with IPP implementations that don&#39;t<br>

implement the &quot;printer-alert&quot; attribute (keyword/value pairs).<br><br>That is, it&#39;s an implementation choice to show specific alert conditions<br>in &quot;printer-state-reasons&quot; - which already has a *complete* set defined<br>

for the Printer MIB and Finisher MIB subunits).<br><br>Security Alerts:<br><br>I&#39;m happy to explain these - due to copyright, we can&#39;t actually use<br>the IEEE 2600 definitions - though we can mention IEEE 2600 as an<br>

informative reference - normative references to non-public specs are<br>not allowed by PWG process and precedent.<br><br>Cheers,<br>- Ira<br><br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>

Co-Chair - IEEE-ISTO PWG IPP WG<br>Chair - TCG Embedded Systems Hardcopy SWG<br>IETF Designated Expert - IPP &amp; Printer MIB<br>Blue Roof Music/High North Inc<br><a 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>

Christmas through April:<br>  579 Park Place  Saline, MI  48176<br>  <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>May to Christmas:<br>  PO Box 221  Grand Marais, MI 49839<br>  <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><div style="display:inline">
</div><div style="display:inline">
</div><div style="display:inline"></div><div></div><br>
<br><br><div class="gmail_quote">On Thu, Sep 15, 2011 at 11:51 PM, Michael Sweet <span dir="ltr">&lt;<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div><div>On Sep 15, 2011, at 11:05 AM, Ira McDonald wrote:</div><blockquote type="cite">Hi Mike,<br><br>I&#39;d like to add to the IPP slide deck discussion of the MFD Alerts <br>
for Printer MIB spec which has just had its second review at <br>Prototype status:<br></blockquote><div><br></div></div>Will do.</div><div><br></div><div><blockquote type="cite">...<div><br>Will CUPS pickup the IANA IPP Registry keywords for scanner, fax <br>


modem, and security alerts in IPP printer-state-reasons attribute?<br></div></blockquote><div><br></div></div>CUPS already supports arbitrary keywords from drivers, so a fax driver definitely could set them today.<div><br>

</div><div>Scanning is not currently supported via CUPS, so that will have to wait for a future implementation.<div><br></div><div>As for the security keywords, I will need to review them closely; it isn&#39;t clear that mapping them all to printer-state-reasons makes sense since they represent events (alerts) and not persistent conditions.</div>

<div><br></div><div>Moreover, I think all of the keywords need at least a sentence to describe what they mean (it is not obvious to me, particularly for the security keywords)</div><div><br></div><div><div>
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>

__________________________________________________</div><div>Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></span>
</div>
<br></div></div></div>
</blockquote></div><br><div></div>
</blockquote></div><br><div>
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>
__________________________________________________</div><div>Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></span>
</div>
<br></div></div></div></div></blockquote></div><br><div style="visibility: hidden; left: -5000px;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup{position: absolute;z-index: 9999;padding: 0px 0px;margin-left: 0px;margin-top: 0px;overflow: hidden;word-wrap: break-word;color: black;font-size: 10px;text-align: left;line-height: 130%;}</style>
<br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.