IPP> PSX - Limited Design Alternative for Device Alerts

IPP> PSX - Limited Design Alternative for Device Alerts

McDonald, Ira imcdonald at sharplabs.com
Tue Aug 29 21:22:13 EDT 2006


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
 



More information about the Ipp mailing list