PMP Mail Archive: RE: PMP> New MFP Alert Groups Specification Available

RE: PMP> New MFP Alert Groups Specification Available

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Nov 21 2006 - 12:54:43 EST

  • Next message: McDonald, Ira: "RE: Printer Status - Web Server versus MIB (was: RE: PMP> New MFP Alert Groups Specification Available)"

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

    -----Original Message-----
    From: Stuart Rowley [mailto:Stuart.Rowley@ktd-kyocera.com]
    Sent: Monday, November 20, 2006 11:55 AM
    To: McDonald, Ira
    Cc: Bergman, Ron; pmp@pwg.org
    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
    stuart.rowley@ktd-kyocera.com
    V: 925.849.3306
    F: 925.849.3399

       

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Saturday, November 18, 2006 9:52 AM
    To: Stuart Rowley; Bergman, Ron; pmp@pwg.org
    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: imcdonald@sharplabs.com
    -----Original Message-----
    From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Stuart
    Rowley
    Sent: Friday, November 17, 2006 3:27 PM
    To: Bergman, Ron; pmp@pwg.org
    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
    stuart.rowley@ktd-kyocera.com
    V: 925.849.3306
    F: 925.849.3399
     
     
     

    From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf Of Bergman,
    Ron
    Sent: Friday, November 17, 2006 11:10 AM
    To: pmp@pwg.org
    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



    This archive was generated by hypermail 2.1.4 : Tue Nov 21 2006 - 12:57:12 EST