Subject: [IPP] Topic for IPP slides at F2F (MFD Alerts - IPP extension)

From: Ira McDonald <[email-masked]>
Date: Thu, 15 Sep 2011 14:05:44 -0400

Hi Mike,

I'd like to add to the IPP slide deck discussion of the MFD Alerts
for Printer MIB spec which has just had its second review at
Prototype status:

ftp://ftp.pwg.org/pub/pwg/pmp/wd/wd-pmpmfdalerts10-20110902.pdf / doc
- clean copy with line numbers and live table of contents

ftp://ftp.pwg.org/pub/pwg/pmp/wd/wd-pmpmfdalerts10-20110902-rev.pdf / doc
- redlines copy with line numbers and live table of contents

Since this document defines new values for existing IPP attributes
(printer-state-reasons and printer-alert), Bill Wagner has asked for
both IPP WG review and IPP prototyping.

Will CUPS pickup the IANA IPP Registry keywords for scanner, fax
modem, and security alerts in IPP printer-state-reasons attribute?

The security alerts correlate with System Log spec in IDS of course.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded Systems Hardcopy SWG
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]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

---

From: Michael Sweet <[email-masked]>
Date: Thu, 15 Sep 2011 20:51:17 -0700

> for Printer MIB spec which has just had its second review at 

Will do.

> ...

CUPS already supports arbitrary keywords from drivers, so a fax driver definitely could set them today.

Scanning is not currently supported via CUPS, so that will have to wait for a future implementation.

As for the security keywords, I will need to review them closely; it isn't clear that mapping them all to printer-state-reasons makes sense since they represent events (alerts) and not persistent conditions.

Moreover, I think all of the keywords need at least a sentence to describe what they mean (it is not obvious to me, particularly for the security keywords)

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Fri, 16 Sep 2011 12:47:47 -0400

Hi Mike,

Sure I can add a brief description for each new alert code.

But I note that this has never been done before in either IPP PSX
or Printer MIB itself (arguably a Printer MIB deficiency).

Note that, by IPP PSX precedent, ALL IANA Printer MIB alert codes
are available in the REQUIRED "printer-state-reasons" attribute (by
direct transform from the IANA Printer MIB registry).

This supports wider interoperability with IPP implementations that don't
implement the "printer-alert" attribute (keyword/value pairs).

That is, it's an implementation choice to show specific alert conditions
in "printer-state-reasons" - which already has a *complete* set defined
for the Printer MIB and Finisher MIB subunits).

Security Alerts:

I'm happy to explain these - due to copyright, we can't actually use
the IEEE 2600 definitions - though we can mention IEEE 2600 as an
informative reference - normative references to non-public specs are
not allowed by PWG process and precedent.

Cheers,
- Ira

On Thu, Sep 15, 2011 at 11:51 PM, Michael Sweet <[email-masked]> wrote:

> As for the security keywords, I will need to review them closely; it isn't
> clear that mapping them all to printer-state-reasons makes sense since they
> represent events (alerts) and not persistent conditions.
>
> Moreover, I think all of the keywords need at least a sentence to describe
> what they mean (it is not obvious to me, particularly for the security
> keywords)
>

---

From: Michael Sweet <[email-masked]>
Date: Sun, 18 Sep 2011 15:35:19 -0700

Ira,

Given the inconsistencies I've seen in recent years with even the keywords defined in RFC 2911, I really think we need to provide specific descriptions for each new keyword, otherwise they won't get used (or won't get used properly).

In addition, I think we want to document which new keywords are not appropriate for use with printer-state-reasons (even if they have to be registered for that attribute), simply because some are not persistent/present state but instead are really identifiers for sporadic events.  We don't want "idiot lights" that need to be reset, and we don't want clients that poll the printer on the off chance they'll see a particular keyword show up in printer-state-reasons because the printer chose not to support printer-alerts.

(and FWIW I think we want IPP Everywhere to require printer-alert and printer-alert-description...)

---

From: Ira McDonald <[email-masked]>
Date: Mon, 19 Sep 2011 10:28:13 -0400

Hi Mike,

Several thoughts.

I was not a proponent a year ago of security alerts
in Printer MIB - I think they're an architectural error
and belong in an appropriate IETF Ops & Mgmt Area
MIB.

I'd rather *delete* the security alerts from this spec
(and let Common Log spec talk about them instead).

About events and transient states.  RFC 2566 and
RFC 2911 enshrined *lots* of very short-lived transient
states in printer-state-reasons (from the service level)
and defined lots or Printer MIB alert values for
printer-state-reasons.

The specific new alerts for Scanner and Fax Modem
are just as self-descriptive (and clear in my opinion)
as existing Marker and Input events.  I'll write the
sentence for each, but it won't (and inherently can't)
further qualify when to report them - the answer is:
when they occur and the implementation supports
reporting them in prtAlertTable.

If an implementation does NOT support showing
prtAlertTable content in "printer-state-reasons", then
it doesn't.

Given the terrible report/error/warning prefixes (which
are not and *could* not be IANA registered, by very their
format) from IPP/1.0 onward, the "pollution" of
printer-state-reasons with stuff of minimal value for
automated behavior is long-standing.

Comments?

Cheers,
- Ira

On Sun, Sep 18, 2011 at 6:35 PM, Michael Sweet <[email-masked]> wrote:

> Ira,
>
> Given the inconsistencies I've seen in recent years with even the keywords
> defined in RFC 2911, I really think we need to provide specific descriptions
> for each new keyword, otherwise they won't get used (or won't get used
> properly).
>
> In addition, I think we want to document which new keywords are not
> appropriate for use with printer-state-reasons (even if they have to be
> registered for that attribute), simply because some are not
> persistent/present state but instead are really identifiers for sporadic
> events.  We don't want "idiot lights" that need to be reset, and we don't
> want clients that poll the printer on the off chance they'll see a
> particular keyword show up in printer-state-reasons because the printer
> chose not to support printer-alerts.
>