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).
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.
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
mailto:blueroofmusic at gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
May to Christmas:
PO Box 221 Grand Marais, MI 49839
On Thu, Sep 15, 2011 at 11:51 PM, Michael Sweet <msweet at apple.com> wrote:
> On Sep 15, 2011, at 11:05 AM, Ira McDonald wrote:
>> 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:
>>> Will do.
>> Will CUPS pickup the IANA IPP Registry keywords for scanner, fax
> modem, and security alerts in IPP printer-state-reasons attribute?
>>> 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
> Michael Sweet, Senior Printing System Engineer, PWG Chair
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...