Thank you very much for your explanation & pointers, Ira.
Regards,
Somasundaram.
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Wednesday, May 14, 2014 10:42 PM
To: Soma Meiyappan; Ira McDonald
Cc: <ipp at pwg.org>
Subject: Re: [IPP] printer-alert in PWG 5100.9 & its relevance in IPP FaxOut and IPP Scan
Hi,
On further reflection.
Unary events (including 'configurationChange') in Printer MIB "prtAlertTable" are
indeed allowed to be (but not required to be) "aged" out (delete oldest unary
event first, is the typical implementation). The algorithm used is implementation
defined. The same would be true for the IPP mapping of "prtAlertTable" rows.
See the discussion of configuration change and other unary events in section
2.2.13.4 Alert Table Management on pages 22-23 of RFC 3805.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com>
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Wed, May 14, 2014 at 10:28 AM, Ira McDonald <blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com>> wrote:
Hi,
'configurationChange' has always been a one-time event - it was originally derived
from the prtGeneralConfigChanges counter in Printer MIB v1 and v2 (RFC 1759 and
RFC 3805). It was defined as OPTIONAL event (not state) in IPP Events Notifications
and Subscriptions (RFC 3995), named 'printer-config-changed'.
Some confusion may arise because PWG 5100.9 defines new values for the IPP
attribute "job-state-reasons" - these are NOT states - they are durable reasons that
"job-state" may have changed in the past. They must not be simply "aged" out of the
"job-state-reasons" attribute. But, if they reflect a binary event (e.g., coverOpen),
then they must be removed from "job-state-reasons" when the condition clears.
I'll let Mike and Pete answer why it's listed as REQUIRED in IPP FaxOut and IPP Scan.
That doesn't sound right to me, based on RFC 3995.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com>
Winter 579 Park Place Saline, MI 48176 734-944-0094<tel:734-944-0094>
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<tel:906-494-2434>
On Tue, May 13, 2014 at 10:18 PM, Soma Meiyappan <Soma.Meiyappan at conexant.com<mailto: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<mailto:ipp at pwg.org>
https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140517/467fda84/attachment.html>