On further reflection.
Unary events (including 'configurationChange') in Printer MIB
indeed allowed to be (but not required to be) "aged" out (delete oldest
event first, is the typical implementation). The algorithm used is
defined. The same would be true for the IPP mapping of "prtAlertTable"
See the discussion of configuration change and other unary events in
184.108.40.206 Alert Table Management on pages 22-23 of RFC 3805.
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
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>wrote:
>> 'configurationChange' has always been a one-time event - it was originally
> 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
> 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.,
> then they must be removed from "job-state-reasons" when the condition
>> 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.
> - 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/blueroofmusic>http://sites.google.com/site/highnorthinc> 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 Tue, May 13, 2014 at 10: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>>>>-------------- next part --------------
An HTML attachment was scrubbed...