Hi Mike,
Thank you very much for the explanation.
printer-alert is certainly semantically more descriptive than printer-state-reasons and has all the benefits that PWG 5100.9 explains. It is certainly very useful if all the RECOMMENDED/OPTIONAL alert objects in Table 5-3 of PWG 5100.9. Otherwise, prtAlertCode (which is the only REQUIRED alert object in printer-alert) is almost same as printer-state-reasons. As a part of this initiative to set the guaranteed minimum level of functionality, I would assume that most of the alert objects in Table 5-3 of PWG 5100.9 will actually be REQUIRED (where applicable depending upon the alert code) although PWG 5100.9 calls for only prtAlertCode to be REQUIRED.
I was also concerned about potential inconsistencies in treatment of the unary events - both by clients and by servers. In the absence of IPP event subscription support in a product and if prtAlertTime remains OPTIONAL, there are certainly other IPP attributes (printer-config-change-xxx & printer-change-xxx) that seem like a useful alternative for communicating change events which can trigger further inquiry.
These were the reasons why I was trying to find out why printer-alert is REQUIRED and not RECOMMENDED. Probably, I was just getting caught up over a minor technicality.
In principle, I am able to appreciate that printer-alert is very useful simply from the perspective of it being richer than printer-state-reasons in describing the printer's state. I guess that when it comes to implementation, I can see your point that most printer OEMs will provide as much state/event information as possible if printer-alert is made REQUIRED although only prtAlertCode is the only REQUIRED alert object.
Thanks again.
Regards,
Somasundaram.
-----Original Message-----
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Thursday, May 15, 2014 11:07 PM
To: Soma Meiyappan
Cc: <ipp at pwg.org>
Subject: Re: [IPP] printer-alert in PWG 5100.9 & its relevance in IPP FaxOut and IPP Scan
Soma,
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 2.2.13.4 of Printer MIB v2 (RFC 3805) - see:
http://tools.ietf.org/html/rfc3805#section-2.2.13.4
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:
> Hello,
>> 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,
> Somasundaram.
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair