Subject: [IPP] printer-alert in PWG 5100.9 & its relevance in IPP FaxOut and IPP Scan

From: Soma Meiyappan <[email-masked]>
Date: Wed, 14 May 2014 02:18:01 +0000

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Wed, 14 May 2014 10:28:49 -0400

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/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
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 <
[email-masked]> 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.
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 14 May 2014 10:42:07 -0400

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

On Wed, May 14, 2014 at 10:28 AM, Ira McDonald <[email-masked]>wrote:

> from the prtGeneralConfigChanges counter in Printer MIB v1 and v2 (RFC
> 1759 and
> I'll let Mike and Pete answer why it's listed as REQUIRED in IPP FaxOut
> and IPP Scan.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 15 May 2014 08:06:33 -0700

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).

> 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 subscrip…

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Soma Meiyappan <[email-masked]>
Date: Sat, 17 May 2014 10:21:09 +0000

Thank you very much for your explanation & pointers, Ira.

Regards,
Somasundaram.

From: Ira McDonald [mailto:[email-masked]]
Sent: Wednesday, May 14, 2014 10:42 PM
To: Soma Meiyappan; Ira McDonald
Cc: <[email-masked]>
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

mailto: [email-masked]<mailto:[email-masked]>

On Wed, May 14, 2014 at 10:28 AM, Ira McDonald <[email-masked]<mailto:[email-masked]>> 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/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Thanks and Regards,
Somasundaram.

_______________________________________________
ipp mailing list
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

---

From: Soma Meiyappan <[email-masked]>
Date: Sat, 17 May 2014 14:22:09 +0000

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:[email-masked]] 
Sent: Thursday, May 15, 2014 11:07 PM
To: Soma Meiyappan
Cc: <[email-masked]>
Subject: Re: [IPP] printer-alert in PWG 5100.9 & its relevance in IPP FaxOut and IPP Scan

Soma,