From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Aug 29 2006 - 21:22:13 EDT
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@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
This archive was generated by hypermail 2.1.4 : Tue Aug 29 2006 - 21:22:22 EDT