IPP> PSX - Limited Design Alternative for Device Alerts

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Aug 29 2006 - 21:22:13 EDT

  • Next message: Harry Lewis: "Re: 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@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