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
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/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
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
On Sun, Sep 18, 2011 at 6:35 PM, Michael Sweet <msweet at apple.com> 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.
>> (and FWIW I think we want IPP Everywhere to require printer-alert and
> printer-alert-description...)
>> On Sep 16, 2011, at 9:47 AM, Ira McDonald wrote:
>> 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
>>> 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:blueroofmusic at gmail.com> 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
>>>> 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
>> keywords)
>>>> __________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>>>> __________________________________________________
> 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...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20110919/da95a6f0/attachment-0001.html>