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/20110918/355912e9/attachment-0001.html>