Ira,
Its getting hard to keep up with your changes;-)
The smaller content for both jmDeviceEventV2Event
and jmJobEventV2Event seem to be reasonable. This
is most likely all anyone would want for these
traps. However, the jmJobProgressV2Event should
contain sufficient information to allow the client
application to maintain a set of "gas gauge" style
displays. This makes this trap fairly heavy, but
without this information the trap is not very useful.
I eliminated jmJobState and jmJobEventJobStateReasons
since a state change seldom happens during printing,
at least as compared to progress, and a separate
jmJobEventV2Event trap can be sent to report state
changes.
I don't believe that this trap content will exceed
the 485 byte limit, but I did not do a byte count.
Here is my revised proposal:
jmJobProgressV2Event NOTIFICATION-TYPE
OBJECTS {
jmJobEventNotifyEvent, -- new object
jmJobKOctetsPerCopyRequested, -- from Job MIB
jmJobKOctetsProcessed, -- from Job MIB
jmJobImpressionsPerCopyRequested, -- from Job MIB
jmJobImpressionsCompleted, -- from Job MIB
jmJobEventCopiesRequested, -- new object
jmJobEventJobCollationType, -- new object
jmJobEventMediaSheetsCompleted, -- new object
jmJobEventSheetCompletedCopyNumber, -- new object
jmJobEventSheetCompletedDocNumber -- new object
}
Ron Bergman
Hitachi Koki Imaging Solutions
"McDonald, Ira" wrote:
> Hi folks, Tuesday (18 April 2000)
>
> Very small Job Monitoring MIB traps (for IPP Notifications over SNMP).
>
> jmDeviceEventV2Event NOTIFICATION-TYPE
> OBJECTS {
> jmDeviceEventNotifyEvent,
> jmDeviceState,
> jmDeviceStateReasons
> }
>
> jmJobEventV2Event NOTIFICATION-TYPE
> OBJECTS {
> jmJobEventNotifyEvent,
> jmJobState,
> jmJobEventJobStateReasons
> }
>
> jmJobProgressV2Event NOTIFICATION-TYPE
> OBJECTS {
> jmJobEventNotifyEvent,
> jmJobState,
> jmJobEventJobStateReasons,
> jmJobEventKOctetsProcessed,
> jmJobEventImpressionsCompleted
> }
>
> I propose to write this all up in a revised Internet-Draft in the near
> future.
>
> Comments?
>
> Cheers,
> - Ira McDonald, consulting architect at Xerox and Sharp
> High North Inc
>
> ------------------------------------------------------------------------
>
> Changes from previous proposal of 22 May 2000:
>
> 1) Revised INDEX clauses of tables to always use single-level indices.
>
> 2) Added 'jmDeviceEventDeviceIndex', 'jmJobEventJobSetIndex', and
> 'jmJobEventJobIndex' pointer objects to event tables but not traps.
>
> 3) Deleted '...DeviceIsAcceptingJobs' from event table and trap
> because it's redundant with a value of '...DeviceStateReasons'.
>
> 4) Deleted '...NotifyCharset', '...NotifyLanguage', and '...NotifyText'
> from event tables and traps because they're incompatible with SNMP
> libraries (which assemble trap bindings and then send the IDENTICAL
> trap to all registered destinations) - in IPP, each destination MAY
> request a DIFFERENT value of '...NotifyLanguage', etc.
>
> 5) Deleted '...UpTime' from traps because 'sysUpTime' is included
> in SNMPv1 and SNMPv2/SNMPv3 traps by all conforming SNMP agents.
>
> 6) Deleted '...DateTime' from traps and event tables because it's
> redundant with '...UpTime' objects.
>
> 7) Deleted 'jmJobExtraTable' (for 'notify-attributes' from IPP) as it's
> redundant with attributes in 'jmJobTable' and 'jmAttributeTable'.
>
> 8) Renamed '...TriggerEvent' to '...NotifyEvent' for clarity (and I
> think this is the agreement for all IPP notification methods).
>
> ------------------------------------------------------------------------
>
> -- Device Table - devices which support job services
> --
> -- Systems which also implement IETF Host Resources MIB (RFC 2790)
> -- SHALL set 'jmDeviceIndex' to 'hrDeviceIndex' for the same device
>
> -- INDEX { jmDeviceIndex }
> jmDeviceEntry ::= SEQUENCE {
> jmDeviceIndex Integer32 (1..2147483647),
> jmDeviceName SnmpAdminString,
> jmDeviceURI SnmpAdminString,
> jmDeviceServiceTypes JmJobServiceTypesTC,
> jmDeviceState JmDeviceStateTC,
> jmDeviceStateReasons SnmpAdminString
> }
>
> -- Device Event Table
> --
> -- Rows are persistent until system reboot or table overflow
>
> -- INDEX { jmDeviceEventIndex }
> jmDeviceEventEntry ::= SEQUENCE {
> jmDeviceEventIndex Integer32 (1..2147483647),
> jmDeviceEventNotifyEvent SnmpAdminString,
> jmDeviceEventNotifyTime TimeTicks,
> jmDeviceEventDeviceIndex Integer32 (1..2147483647),
> jmDeviceEventDeviceState JmDeviceStateTC,
> jmDeviceEventDeviceStateReasons SnmpAdminString
> }
>
> -- Device Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform
> --
> -- For all device events
>
> jmDeviceEventV2Event NOTIFICATION-TYPE
> OBJECTS {
> jmDeviceEventNotifyEvent,
> jmDeviceState,
> jmDeviceStateReasons
> }
>
> -- Job Event Table - persistent only for lifetime of job
> --
> -- Rows are persistent ONLY for lifetime of job
>
> -- INDEX { jmJobEventIndex }
> jmJobEventEntry ::= SEQUENCE {
> jmJobEventIndex Integer32 (1..2147483647),
> jmJobEventNotifyEvent SnmpAdminString,
> jmJobEventNotifyTime TimeTicks,
> jmJobEventJobSetIndex Integer32 (1..32767),
> jmJobEventJobIndex Integer32 (1..2147483647),
> jmJobEventJobState JmJobStateTC,
> jmJobEventJobStateReasons OCTET STRING (SIZE (4..16)),
> jmJobEventKOctetsProcessed Integer32 (-2..2147483647),
> jmJobEventImpressionsCompleted Integer32 (-2..2147483647)
> }
>
> -- Job Event Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform
> --
> -- For basic job events
>
> jmJobEventV2Event NOTIFICATION-TYPE
> OBJECTS {
> jmJobEventNotifyEvent,
> jmJobState,
> jmJobEventJobStateReasons
> }
>
> -- Job Progress Notify - for SNMPv1 Trap or SNMPv2 Trap/Inform
> --
> -- For both job-progress and job-completed events
>
> jmJobProgressV2Event NOTIFICATION-TYPE
> OBJECTS {
> jmJobEventNotifyEvent,
> jmJobState,
> jmJobEventJobStateReasons,
> jmJobEventKOctetsProcessed,
> jmJobEventImpressionsCompleted
> }
>
> ------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Thu Jun 01 2000 - 14:13:03 EDT