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

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

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

McDonald, Ira imcdonald at sharplabs.com
Thu Mar 1 12:22:00 EST 2007

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
email: imcdonald at sharplabs.com

-----Original Message-----
From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf Of
Ron.Bergman at ricoh-usa.com
Sent: Wednesday, February 28, 2007 4:35 PM
To: pmp at pwg.org
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

More information about the Wims mailing list