PMP Mail Archive: RE: PMP> Indexing option for prtAlertGroupIndex to identify funct ion

RE: PMP> Indexing option for prtAlertGroupIndex to identify funct ion

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Nov 06 2006 - 16:13:34 EST

  • Next message: Bergman, Ron: "RE: PMP> Indexing option for prtAlertGroupIndex to identify function"

    Hi,

    Sorry I've had no bandwidth to look at this stuff, Stuart
    and Ron.

    But, it is NOT 'hrDeviceID' (an OID), but 'hrDeviceIndex'
    (an integer) that is the high-order index in Printer MIB
    tables.

    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: Monday, November 06, 2006 12:44 PM
    To: Bergman, Ron
    Cc: pmp@pwg.org
    Subject: RE: PMP> Indexing option for prtAlertGroupIndex to identify
    function

    Hi Ron,
     
    Your description of the indexing is appropriate; however, there is still no
    mention of prtAlertGroupIndex which is the same as the index of prtInput,
    prtChannel, etc. but in the Alert, prtAlertGroupIndex is what allows the
    management app to identify which function the alert is relating to. I think
    completely leaving prtAlertGroupIndex out of this text is a mistake.
     
    I am also concerned about this sentence: The index position to be used is
    the least significant index, not the position occupied by hrDeviceID.
    I think hrDeviceID should not be introduced here without further
    clarification. We discussed the use of hrDeviceID as an alternative method
    for distinguishing the function, but it does not relate to the use of the
    index position at all, so I think this is just confusing. If we mention
    hrDeviceID, it should be a separate paragraph saying why using the
    hrDeviceID for the scan function is not an acceptable alternative for
    determining the function that an alert is related to. It is not clear to me
    what "The index position to be used is the least significant index," is
    trying to convey. Are you saying that for a prtChannel relating to the fax,
    the index should start with 24576 rather than say 25000? Is this necessary
    to state?
     
    prtCovers should be prtCover.
     
    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: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]
    Sent: Thursday, November 02, 2006 4:05 PM
    To: Stuart Rowley
    Subject: RE: PMP> Indexing option for prtAlertGroupIndex to identify
    function
     
    Hi Stuart,
     
    I made some modifications to your text. I thing there is still a
    misunderstanding regarding the index this grouping applies to. Review this
    part carefully.
     
    11 Appendix A Suggested Indexing Method (Informative)
    For the MFD subunits that are represented in the common alert groups of
    prtMediaPath, prtInput, prtChannel, prtConsole, prtCovers,
    systemGeneralTransformer, systemGeneralOutputChannel, and
    systemGeneralSupply, there may be no information to indicate the MFD
    function associated with the alert.
    To allow an application implementation to easily determine the functional
    device that is associated with an alert, it is recommended that table index
    groups be assigned to each device. The index position to be used is the
    least significant index, not the position occupied by hrDeviceID. For
    example, in the prtMediaPath group, this applies to prtMediaPathIndex.
    Although the exact grouping may be implementation dependent, the following
    grouping is strongly suggested to provide interoperability between MFDs and
    management applications.
    It is recommended all MFDs assign table index values from 1 to 16383 (0x0001
    to 0x3FFF) to the printer, the values from 20480 to 24575 (0x5000 to 0x5FFF)
    are to be assigned to the scan device and the values from 24576 to 28671
    (0x6000 to 0x6FFF) are to be assigned to the fax device.
     
    Let me know if you agree.
     
        Ron
     
     

    From: Stuart Rowley [mailto:Stuart.Rowley@ktd-kyocera.com]
    Sent: Wednesday, November 01, 2006 12:02 PM
    To: Bergman, Ron
    Subject: RE: PMP> Indexing option for prtAlertGroupIndex to identify
    function
    Ron,
     
    I remember Ira saying recommended was too strong, but I kind of don't get
    that. This is in a never never land of not being normative, but on the other
    hand if everyone uses different ranges, then management apps make wrong
    assumptions. The only reason not to use recommended in my opinion is due to
    a special meaning of recommended in "standards-ese".
     
    Thanks,
     
    Stuart
     
     

    From: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]
    Sent: Wednesday, November 01, 2006 11:56 AM
    To: Stuart Rowley
    Subject: RE: PMP> Indexing option for prtAlertGroupIndex to identify
    function
     
    Thanks Stuart, looks good. I hope to be able to get back to this later in
    the week.
     
    You probably missed some of the discussion, Ira indicated that "recommended"
    was too strong (?) and indicated a requirement. We agreed to use
    "suggested" instead. Whatever...
     
    Too bad you missed the meeting with Ira actually present. He is an
    interesting character.
     
        Regards,
        Ron
     

    From: Stuart Rowley [mailto:Stuart.Rowley@ktd-kyocera.com]
    Sent: Tuesday, October 31, 2006 12:00 PM
    To: pmp@pwg.org
    Cc: Bergman, Ron
    Subject: PMP> Indexing option for prtAlertGroupIndex to identify function
    Ron,
     
    I took a stab at new text for section 7 Recommended Indexing Method.
     
    Ira suggested that it should not be normative and should therefore be in an
    appendix. I wasn't sure how to handle whether the ranges are recommended or
    just an example. If there is no explicit agreement on the ranges, then a
    management app has no idea of the special meaning of the index. Therefore,
    "recommended" seems appropriate to me. I expanded the ranges because Ira
    said that some device implementations may bump into the previous range
    limits.
     
    Appendix (x) - prtAlertGroupIndex Indexing Option
    The various MFD functions share some common alert groups, such as
    prtMediaPath, prtInput, prtOutput, prtChannel, prtConsole, prtCover, etc.,
    For alerts in these common alert groups, there may be no information which
    indicates the MFD function affected by the alert. The recommended method to
    allow a management application to associate an alert with a specific device
    function is to assign index ranges to each device function. The following
    prtAlertGroupIndex index ranges are recommended; index values from 1 to 255
    (0x0001 to 0x00FF) may be assigned to the print function, index values from
    256 to 511 (0x0100 to 0x01FF) may be assigned to the scan function, and
    index values from 512 to 767 (0x0200 to 0x02FF) may be assigned to the fax
    function. Note that this method does not indicate when a common group alert
    affects multiple device functions. For example, an open cover may affect the
    print, fax, and scan functions, but only one prtAlertGroupIndex is used.
     
    For the alert groups that are specific to one MFD function, such as
    faxDeviceGeneral or scanDeviceScanner, prtAlertGroupIndex indices may be
    assigned normally, i.e starting at index 1.
     
    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
     
     

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


    This archive was generated by hypermail 2.1.4 : Mon Nov 06 2006 - 16:14:11 EST