IPP Mail Archive: IPP> Comments on the SNMP Notifications Do

IPP Mail Archive: IPP> Comments on the SNMP Notifications Do

IPP> Comments on the SNMP Notifications Document

From: Ron Bergman (rbergma@hitachi-hkis.com)
Date: Wed Mar 01 2000 - 21:36:19 EST

  • Next message: McDonald, Ira: "RE: IPP> [URGENT] RE: Help - Naming problems in SLP 'service:prin ter'"

    Ira,

    At last here are my comments. I hope this starts a good discussion.

    1. Job MIB Event Group, jmEventPrinterState: This object syntax is
    defined as OCTET STRING, but is should match the syntax of the IPP
    attribute "printer-state", which is an enumeration. The enums
    values also should be aligned with "printer-state" (i.e. idle(3),
    processing(4), stopped(5) ).

    2. Job MIB Event Group: The value of the objects in this group can have
    many values, unique to each notification and subscdription. In
    order for these objects to be properly identified, this group should
    be a table with multiple indexes. Some of the indexes necessary
    would be (more may be necessary):

    - jmGeneralJobSetIndex
    - jmJobIndex
    - jmEventIndex (new, must be defined)
    - jmEventSubscriptionID

    However, I don't see any need for direct access to any these
    objects. The only need for this group is to define the OIDs for use
    by the SNMP notification. Within the context of the notification,
    these is no need to provide a unique OID to each instance of an
    object.
    A better solution would be to change the MAX-ACCESS clause from
    "read-only" to "not-accessible". Since this would be a somewhat
    unusual application of an SNMP object group, a short explanation
    needs to be added.

    3. Section 3.1: "jmEventEventPrinterState" should be
    "jmEventPrinterState".

    4. The notification contains 5 objects to define printer status
    (hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState,
    jmEventPrinterState, and jmEventPrinterStateReasons). This seems
    like a large number of objects just to indicate what is wrong with
    the printer. The 2 objects hrDeviceStatus and hrPrinterStatus add
    very little value and I strongly recommend their removal.
    hrPrinterDetectedErrorState could be considered of marginal value,
    due to the presence of jmEventPrinterStateReasons, but would provide
    easier machine processing capability. Certainly jmEventPrinterState
    and jmEventPrinterStateReasons are sufficient for human use.

    5. The mapping of printer-uri to prtChannelInformation does not seem
    appropriate. I also question the need for both the printer name and
    the printer URI in the notification. We sometimes go overboard and
    I am surprised that the printer location, manufacturer, model,
    serial number, and date of manufacture are not also included;-).

    6. The representation of an attribute in a notification presents
    another unique problem. The OID of an attribute cannot be
    determined without first processing the entire attribute table in
    the Job Monitoring MIB within the device. Even after this
    processing, it cannot be guaranteed that the OIDs will be stable.
    To resolve this issue it would be best to include additional entries
    in the Job MIB Event group for each attribute that is needed in the
    notification. Thus, 10 new objects would need to be added.

    jmEventJobName for "jmAttributeValue...jobName.1"
    jmEventJobStateReasons2 for ...
    jmEventJobStateReasons3 for ...
    jmEventJobStateReasons4 for ...
    jmEventSheetsCompleted for ...
    jmEventJobCollationType for ...
    jmEventSheetCompletedCopyNumber for ...
    jmEventSheetCompletedDocumentNumber for ...
    jmEventImpressionsInterpreted for ...
    jmEventImpressionsCompletedCurrentCopy for ...

       jmEventJobName OBJECT-TYPE
           SYNTAX OCTET STRING (SIZE (0..255))
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "The human readable string name of the job assigned by the
               submitting user to allow the user to distinguish this job
               among others submitted by the same user. The name may be
               truncated, if necessary, to fit into the SNMP datagram.
               This value is equivalent to the Job MIB Attribute jobName
               that is associated with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 8 }

       jmEventJobStateReasons2 OBJECT-TYPE
           SYNTAX JmJobStateReasons2TC
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Provides addition information concerning the state of the
               job, in addition to or instead of the information presented
               in jmJobStateReasons1, jmEventJobStateReasons3 or
               jmEventJobStateReasons4. The value of this object
               corresponds to the value of the Job MIB Attribute
               jobStateReasons2 that is associated with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 9 }

       jmEventJobStateReasons3 OBJECT-TYPE
           SYNTAX JmJobStateReasons3TC
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Provides addition information concerning the state of the
               job, in addition to or instead of the information presented
               in jmJobStateReasons1, jmEventJobStateReasons2 or
               jmEventJobStateReasons4. The value of this object
               corresponds to the value of the Job MIB Attribute
               jobStateReasons3 that is associated with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 10 }

       jmEventJobStateReasons4 OBJECT-TYPE
           SYNTAX JmJobStateReasons4TC
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Provides addition information concerning the state of the
               job, in addition to or instead of the information presented
               in jmJobStateReasons1, jmEventJobStateReasons2 or
               jmEventJobStateReasons3. The value of this object
               corresponds to the value of the Job MIB Attribute
               jobStateReasons4 that is associated with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 11 }

       jmEventSheetsCompleted OBJECT-TYPE
           SYNTAX Integer32
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Defines the total number of media sheets that have
               completed marking and stacking for this job. This value is
               equivalent to the Job MIB Attribute sheetsCompleted that
               is associated with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 12 }

       jmEventJobCollationType OBJECT-TYPE
           SYNTAX JmJobCollationTypeTC
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Specifies the type of collation used for this job. This
               value is equivalent to the Job MIB Attribute
               jobCollationType that is associated with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 13 }

       jmEventSheetCompletedCopyNumber OBJECT-TYPE
           SYNTAX Integer32
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "The number of the copy being stacked for the current copy
               document in this job. This value is equivalent to the Job
               MIB Attribute sheetCompletedCopyNumber that is associated
               with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 14 }

       jmEventSheetCompletedDocumentNumber OBJECT-TYPE
           SYNTAX Integer32
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Defines the ordinal number of the document in the job that
               is currently being stacked. This value is equivalent to the
               Job MIB Attribute sheetCompletedDocumentNumber that is
               associated with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 15 }

       jmEventImpressionsInterpreted OBJECT-TYPE
           SYNTAX Integer32
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Defines the current number of impressions completed for the
               job . This value is equivalent to the Job MIB Attribute
               impressionsInterpreted that is associated with the job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 16 }

       jmEventImpressionsCompletedCurrentCopy OBJECT-TYPE
           SYNTAX Integer32
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Defines the current number of impressions completed for the
               current copy of the current document . This value is
               equivalent to the Job MIB Attribute
               impressionsCompletedCurrentCopy that is associated with the
               job.

               See: Section 7 'Notification Content' in [IPP-NOT]."
           ::= { jmEvent 17 }

    7. Scheme Name: I was going to propose "snmpnotify", but if "snmp" can
    be used, it is better yet!

    8. You had proposed including three optional parameters in the scheme
    URL. (version, pdu-type, and community-name) We also need an IPP
    attribute so that the printer can be queried to determine which
    scheme parameters are supported. (if we are not careful here we
    will have another "3 musketeers" situation) For discussion
    purposes, I propose the following:

       attribute name: snmp-notifications-supported

       attribute values: snmpV1Trap, snmpV2cTrap, snmpV2cInform,
    snmpV2uTrap, snmpV2uInform, snmpV3cTrap, snmpV3cInform, snmpV3uTrap,
    and snmpV3uInform.

       There is a potential problem with SNMPv3, in that the PDU can be
    encoded by any one of multiple methods, and I totally ignored
    SNMPv2u security in a v3 packet. But having each variant
    combination a separate value prevents illegal combinations.

    I hate to ask, but any comments?

        Ron Bergman
        Hitachi Koki Imaging Solutions, Inc.



    This archive was generated by hypermail 2b29 : Wed Mar 01 2000 - 21:31:54 EST