PMP Mail Archive: RE: PMP> [Service to Subunit mapping] MFP Alerts Meeting Minutes, February 19, 2007; Maui

RE: PMP> [Service to Subunit mapping] MFP Alerts Meeting Minutes, February 19, 2007; Maui

From: McDonald, Ira (
Date: Thu Mar 01 2007 - 12:22:00 EST

  • Next message: "PMP> MFD Alerts Presentation for Thursday"

    Hi Ron,

    A thought, because I was just doing the edits in Counter MIB.

    The Counter MIB itself has a table of all the Services (FaxOut,
    Scan, Print, etc) and all the Subunits (including Scanner).

    By adding just ONE columnar object from the older Imaging
    System MIB to the Service table, we could have the pointer
    list (as a bit-mask of indices) to the Subunits from each
    Service. By using the same indices for the Subunits in
    Counter MIB as in the Printer MIB, the problem of multiple
    affected Services for an Alert would be neatly solved.

    Several printer vendors have expressed interest in prototyping
    Counter MIB, because it's the quickest path to multifunction
    counters (without web services), so we might talk about this.

    - Ira

    Ira McDonald (Musician / Software Architect)
    Chair - Linux Foundation Open Printing WG
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434

    -----Original Message-----
    From: []On Behalf Of
    Sent: Wednesday, February 28, 2007 4:35 PM
    Subject: PMP> MFP Alerts Meeting Minutes, February 19, 2007; Maui

    The slides outlining the points for discussion can be found at:

    The primary topic of discussion was in regard to subunits that are used by
    more than one service. (Example, paper input trays may be used by the
    print, copy, and fax-in services.) The question poised was "how can an
    application determine which services are affected?" After a short
    discussion, it was agreed that the proposed alert table index groupings in
    Appendix A could not properly provide this information in all cases. A
    better method would be to define a new service status mechanism as a new
    working group project. It was also agreed to add a short note to Appendix
    A explaining this decision and to indicate this method was not recommended
    for use by the working group.

    I have drafted the following text to be inserted at the beginning of
    Appendix A. If there are no comments received, I will issue the revised
    document next week.

    Working Group analysis and cautions regarding this method.

    The following proposal was discussed extensively within the working group
    and several scenarios were presented that could not be resolved in a
    reasonable manner using the described method. The basic issue relates to
    the fact that the alert table is hardware centric and not service oriented.
    To adequately present the effect of an alert condition on all services
    would, in many cases, require multiple entries in the table for a single
    alert condition. The working group agreed that this is not a desired
    approach and will investigate alternate approaches to provide service
    status information as a follow-on project. The alert table information
    should be used only to obtain hardware status.

    The original text of the proposal follows. NOT RECOMMENDED…

    Ron Bergman
    Chairman, Printer MIBs Working Group

    No virus found in this outgoing message.
    Checked by AVG Free Edition.
    Version: 7.5.446 / Virus Database: 268.18.5/707 - Release Date: 3/1/2007
    2:43 PM

    This archive was generated by hypermail 2.1.4 : Thu Mar 01 2007 - 12:22:12 EST