The "printer-alert" attribute mirrors the corresponding Printer MIB properties and provides a detailed reporting of current state and configuration changes for the printer. There is a discussion of how to handle configuration changes specifically in section 188.8.131.52 of Printer MIB v2 (RFC 3805) - see:
Ultimately, "printer-alert" reports the current state and a (short) history of unary events such as configuration changes.
We require this attribute because having a way to monitor the health/condition of a printer is important and SNMP over UDP is unreliable or unavailable on many networks. This is discussed at some length in PWG 5100.9.
Since most printers already implement the Printer MIB and but do not implement IPP Notifications, requiring "printer-alert" is a relatively small thing to ask implementors to do.
"printer-alert" is also required for IPP Everywhere, which is our current "baseline" for minimum IPP implementation requirements for all services. The ultimate goal is to be able to use and manage any printer via IPP, with a guaranteed minimum level of functionality (and thus interoperability).
On May 13, 2014, at 7:18 PM, Soma Meiyappan <Soma.Meiyappan at conexant.com> wrote:
>> 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.
>> 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)?
>> 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.
>> Thanks and Regards,
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
Michael Sweet, Senior Printing System Engineer, PWG Chair