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're an architectural error<br>and belong in an appropriate IETF Ops & Mgmt Area<br>MIB.<br>
<br>I'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'll write the<br>sentence for each, but it won't (and inherently can'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 "printer-state-reasons", then<br>it doesn'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 "pollution" 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 & 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"><<a href="mailto:msweet@apple.com">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;">
<div style="word-wrap:break-word">Ira,<div><br></div><div>Given the inconsistencies I'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't get used (or won'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't want "idiot lights" that need to be reset, and we don't want clients that poll the printer on the off chance they'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 "printer-state-reasons" attribute (by<br>direct transform from the IANA Printer MIB registry).<br><br>This supports wider interoperability with IPP implementations that don't<br>
implement the "printer-alert" attribute (keyword/value pairs).<br><br>That is, it's an implementation choice to show specific alert conditions<br>in "printer-state-reasons" - which already has a *complete* set defined<br>
for the Printer MIB and Finisher MIB subunits).<br><br>Security Alerts:<br><br>I'm happy to explain these - due to copyright, we can'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 & 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"><<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">
<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'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'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.