attachment
<div dir="ltr"><div><div><div><div>Hi,<br><br></div>On further reflection.<br><br></div>Unary events (including 'configurationChange') in Printer MIB "prtAlertTable" are<br></div>indeed allowed to be (but not required to be) "aged" out (delete oldest unary<br>
</div><div>event first, is the typical implementation). The algorithm used is implementation<br>defined. The same would be true for the IPP mapping of "prtAlertTable" rows.<br></div><div><br>See the discussion of configuration change and other unary events in section <br>
2.2.13.4 Alert Table Management on pages 22-23 of RFC 3805.<br><br></div><div>Cheers,<br></div><div>- Ira<br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><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>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer 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>
<br><br><div class="gmail_quote">On Wed, May 14, 2014 at 10:28 AM, Ira McDonald <span dir="ltr"><<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.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="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>'configurationChange' has always been a one-time event - it was originally derived<br></div>from the prtGeneralConfigChanges counter in Printer MIB v1 and v2 (RFC 1759 and<br>
</div>RFC 3805). It was defined as OPTIONAL event (not state) in IPP Events Notifications <br>and Subscriptions (RFC 3995), named 'printer-config-changed'.<br></div><br></div><div>Some confusion may arise because PWG 5100.9 defines new values for the IPP<br>
attribute "job-state-reasons" - these are NOT states - they are durable reasons that<br></div><div>"job-state" may have changed in the past. They must not be simply "aged" out of the<br></div>
<div>"job-state-reasons" attribute. But, if they reflect a binary event (e.g., coverOpen),<br></div><div>then they must be removed from "job-state-reasons" when the condition clears.<br><br></div>I'll let Mike and Pete answer why it's listed as REQUIRED in IPP FaxOut and IPP Scan.<br>
</div>That doesn't sound right to me, based on RFC 3995.<br><br></div>Cheers,<br></div>- Ira<br><br><div class="gmail_extra"><br clear="all"><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>Winter 579 Park Place Saline, MI 48176 <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>
Summer PO Box 221 Grand Marais, MI 49839 <a href="tel:906-494-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 class="h5">
<br><br><div class="gmail_quote">On Tue, May 13, 2014 at 10:18 PM, Soma Meiyappan <span dir="ltr"><<a href="mailto:Soma.Meiyappan@conexant.com" target="_blank">Soma.Meiyappan@conexant.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
PWG 5100.9 allows an alert code(PrtAlertCodeTC) 'configurationChange' for printer-alert. This value sounds like it is defined to be an event rather than a state.<br>
<br>
If you think that it is a 'state' rather than an 'event', can you please explain how? If it should be treated as a 'state', then should devices initiate a self-determined-timeout value to come out of that 'state' (this sounds like a method to morph an event into a state)?<br>
<br>
If it is indeed an 'event', then please explain why this attribute (printer-alert) is part of the REQUIRED table in IPP FaxOut and IPP Scan specifications when the IPP operations for event subscription themselves are optional.<br>
<br>
Thanks and Regards,<br>
Somasundaram.<br>
<br>
_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>