Subject: RE: PMP> New MFP Alert Groups Specification Available

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 21 Nov 2006 09:54:43 -0800

Hi Stuart,

Ron and I aren't that far apart.  Since an MFD contains
two or more apparent devices (e.g., Print and Fax Devices),
it's fine to talk about devices ("virtual devices"?).

But I'm concerned about this numbering convention
because (since Printer MIB is considered a primary
modelling source), it will carry over in an odd way
into Semantic Model/2.0 modelling of MFDs (as a 
SHOULD, I guess?).

And because many/most network MFD product lines can't 
make significant changes to their SNMP agents and (more
importantly) to their SNMP clients, I don't see that
this numbering convention will ever become widespread.
So real customers will get reduced benefits.

Actually I don't think a large MFD MIB is necessary or
useful.  But I do think that _some_ kind of MIB should
explicitly show the dependencies of various devices on
their shared subunits.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: Stuart Rowley [mailto:[email-masked]]
Sent: Monday, November 20, 2006 11:55 AM
To: McDonald, Ira
Cc: Bergman, Ron; [email-masked]
Subject: RE: PMP> New MFP Alert Groups Specification Available

Hi Ira,

Yes, creating an MFP MIB would address this issue, but we have been
looking for a simple solution which adds "some" value with very little
additional effort - just using the existing structures.

I think what it comes down to is what you and Ron frequently disagree
on: are we modeling services or devices? Of course we cannot be modeling
devices because it is a single device, but on the other hand, with the
alert table we are really primarily interested in the hardware
components of the device.

You suggested that this is not extensible. On a purely service level of
course you are right. However, from a practical standpoint, it is very
difficult to come up with scenarios where hardware failures affect only
individual services, e.g. document transform service is ok but instant
message service is down. Such software failures would be beneficial to
be able to identify, but are really beyond the scope of this effort.

I think the bottom line is that it would be beneficial for us to be able
to distinguish between a jammed scan input and a jammed print input or a
cover open that prevents scanning but printing is not affected. This
proposed indexing method allows us to do that. I am willing to accept
that this method will never be able to tell me that the instant message
service is down but document transform is ok. I accept that I will have
to implement a more advanced MIB or schema to achieve this additional
level of sophistication.

Best regards,

Stuart

Stuart Rowley
Network Product Mgr.
Kyocera Technology Development
1855 Gateway Blvd. #400
Concord, CA 94520
[email-masked]
V: 925.849.3306
F: 925.849.3399

-----Original Message-----
From: McDonald, Ira [mailto:[email-masked]] 
Sent: Saturday, November 18, 2006 9:52 AM
To: Stuart Rowley; Bergman, Ron; [email-masked]
Subject: RE: PMP> New MFP Alert Groups Specification Available

Hi Stuart,

With your example range (4) below (affects scan and fax,
but not print) you have neatly shown why I think that the
ranges are no help.  When you add a document transform
function, an email function, an instant messaging function,
etc., these combination ranges become impractical.

We are overloading right-most subunit index to specify
function (loosely 'imaging device').

But the ambiguity goes away when there's an XML Schema
or a MIB or whatever that _does_ expose associations of
device and service with subordinate subunits - because the
one-to-many from subunit "up" is explicit.  That's what 
the current WIMS/SM Service and Device objects and my
several drafts of an Imaging System MIB do.

I suggest we replace this appendix with a "Rationale for
Design Alternatives" appendix (as in IPP PSX spec) and 
explain why ranges of subunit indices is impractical
and not extensible.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked] 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Stuart
Rowley
Sent: Friday, November 17, 2006 3:27 PM
To: Bergman, Ron; [email-masked]
Subject: RE: PMP> New MFP Alert Groups Specification Available

Ron,
 
Thanks for posting the changes so quickly.
 
I am still a little concerned that the case of a subunit used by
multiple
functions is not clear. We discussed the subunits that use the print
function and the fax function as being in the print function index
range,
but what about the example of a cover open which means the scan function
is
out and the (outbound) fax function is out, but the print function is
unaffected? What range would an implementation use in this case?
 
Maybe we need 4 ranges:
1: affects print function alone or in combination with other functions
(does
not break current implementations)
2: affects scan function exclusively
3: affects fax function exclusively
4: affects scan and fax function
 
Thanks,
 
Stuart
 
Stuart Rowley
Network Product Mgr.
Kyocera Technology Development
1855 Gateway Blvd. #400
Concord, CA 94520
[email-masked]
V: 925.849.3306
F: 925.849.3399

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bergman,
Ron
Sent: Friday, November 17, 2006 11:10 AM
To: [email-masked]
Subject: PMP> New MFP Alert Groups Specification Available
 
The latest MFP Alerts Specification is now available at:
 
    ftp://ftp.pwg.org/pub/pwg/pmp/wd/wd-mfp-alert-groups10-20061117.doc
    ftp://ftp.pwg.org/pub/pwg/pmp/wd/wd-mfp-alert-groups10-20061117.pdf
 
ftp://ftp.pwg.org/pub/pwg/pmp/wd/wd-mfp-alert-groups10-20061117-rev.pdf
 
This document contains the changes discussed in last Wednesday's
teleconference.

    Ron Bergman
    Chairman, PWG PMP Work Group

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.7/537 - Release Date:
11/17/2006

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.8/539 - Release Date: 11/19/2006