Sorry I cannot make today's PSX meeting. I have a conflicting internal
DMTF CIM meeting. I have run the options past IBMers and we prefer options
2 or 3 (not option 1).
----------------------------------------------
Harry Lewis
IBM STSM
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems
http://www.ibm.com/printers
303-924-5337
----------------------------------------------
"McDonald, Ira" <imcdonald at sharplabs.com>
Sent by: owner-ipp at pwg.org
08/29/2006 07:22 PM
To
"'ipp at pwg.org'" <ipp at pwg.org>
cc
Subject
IPP> PSX - Limited Design Alternative for Device Alerts
Hi folks, Tuesday (29 August 2006)
For consideration at this week's IPP WG telecon, below is a very limited
design alternative for the IPP Printer State Reasons (PSX) project.
NOTE - This design alternative does NOT satisfy most requirements in
the latest IPP PSX Problem Statement (email note of 14 August 2006):
http://article.gmane.org/gmane.ietf.ipp/1282
Comments?
Cheers,
- Ira (co-editor of IPP PSX spec)
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
------------------------------------------------------------------------
REQUEST FOR COMMENTS
The IEEE-ISTO PWG requests comments from BMLinkS consortium members on
the design alternative summarized below. The PWG IPP Working Group is
at an effective standstill on the IPP Printer State Reasons Extensions
project until a concensus on the design alternatives is reached.
------------------------------------------------------------------------
LIMITED DESIGN ALTERNATIVE
(0) 'PrtAlertCode' only mapped to existing IPP "printer-state-reasons"
and no other alert context from 'prtAlertTable' mapped to IPP
Syntax:
"printer-state-reasons (1setOf type2 keyword)"
Example:
printer-state-reason[1] = stitcher-jam
printer-state-reason[2] = wrapper-empty
printer-state-reason[3] = input-media-size-change
Note:
Finisher MIB uses 'stitcher' (from ISO DPA) instead of 'stapler'.
Description:
For existing Printer MIB v1/v2 subunits, we would add all missing
values of 'PrtAlertCodeTC' enumeration to "printer-state-reasons".
For Finisher MIB devices, we would add all missing specific values
to 'PrtAlertCodeTC' and "printer-state-reasons" for the equivalent
alerts (e.g., 'wrapper-empty' but NOT 'wrapper-power-saver').
Pros:
P0a Simple solution using only registration - no new IPP attributes.
P0b Avoids large set of parallel ordered attributes that would be
fragile for generic IPP parsers.
P0c Does not require any new formal specification in ABNF.
Cons:
C0a Forces cross-registration between IANA Printer MIB Registry
'PrtAlertCodeTC' and IANA IPP Registry "printer-state-reasons".
C0b Forces transforms of the IANA Printer MIB enumeration tags into
IANA IPP Registry keywords (due to limited keyword syntax).
C0c Does NOT support remote provisioning or field service use cases,
due to lack of alert context (location, group index, etc.).
C0d Does NOT support using IPP as a substitute for SNMP Printer MIB
access for management gateways (for DMTF CIM or other models).
C0e Vendor extensions MUST be IANA-registered (inherent limitation
of the IPP 'type2' keyword syntax).
C0f Results in a very large number of new alert codes (probably
several hundred), mostly unnecessary with all other PSX design
alternatives (where 'PrtAlertGroupTC' is extended).
C0g Probable long delay for concensus on the appropriate set of new
alert codes in (C0f) above would hinder timely solution.
------------------------------------------------------------------------
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.6/430 - Release Date: 8/28/2006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/20060831/31081073/attachment.html