Hi Ron,
I agree - Interoperability is our goal.
I agree we should have the separate Job Progress trap with
all ten bindings - but NOT record Job Progress traps in the
alert table 'jmJobEventTable'. The Job Progress bindings
(except the few from 'jmJobTable') should have leaf objects
defined to hold their bindings.
All other job events should be recorded in the alert table
'jmJobEventTable', except that Job Completed won't redundantly
record the progress counters there (just bind them from the
base objects in 'jmJobTable' into the trap).
All device events should be recorded in the device table
'jmDeviceEventTable'.
Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
High North Inc
-----Original Message-----
From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
Sent: Friday, June 02, 2000 2:11 PM
To: McDonald, Ira
Cc: 'ipp at pwg.org'; 'jmp at pwg.org'
Subject: JMP> Re: IPP> Very small Job Mon traps (IPP notifications) - 31
May 2000
Ira,
A while back I would have agreed with you regarding the
"static" information. However, experience has shown that
this information is not always available at the begining of
the job. It is much more efficient to provide this information
in the trap than have the client continually poll until it is
available.
Hitachi printers don't currently include all the information
proposed, since our collation type is fixed. Also, I do not
see much use in tracking octets processed. (But I lost that
argument years ago during the Job MIB development.)
The total objects in the progress trap is only 10, which
seems to be faitly modest compared to some of the
earlier trap proposals. The advantage of one progress
trap definition is interoperability. This will allow a job
monitor application to be developed that will support
any printer that supports the trap,
I have always tried to favor light-weight protocols,
but in this case including all the important information
in a single trap is the most efficient.
Ron Bergman
Hitachi Koki Imaging Solutions
"McDonald, Ira" wrote:
> Hi Ron,
>> Thanks very much for your quick feedback.
>> I see your point about a detailed trap for job-progress.
>> But in recent IPP discussions, the agreement was that
> REQUIRED content for IPP events would be very small
> (this latest sketch of mine is aligned with IPP here)
> and servers (IPP Printers) or clients could OPTIONALLY
> add additional bindings.
>> Any SNMP trap may have additional bindings, by SNMP rules.
>> What you're requesting is that ALL job-progress traps
> have 'gas gauge' bindings - but this places a higher
> conformance requirement on Job Mon MIB implementations
> to support these optional job attributes for this 'gas
> gauge'.
>> SMI standard usage is never to bind static info (names,
> submitted job size, etc.) into traps, but to let the
> client separately read and cache such static info.
> This is part of the problem with these 'gas gauge'
> bindings.
>> In your private traps at Hitachi/Koki, did you have this
> many bindings for the 'job-progress'?
>> One other comment - after I sent this out the other day,
> I realized that 'job-basic' (state, config, etc.) and
> 'job-completed' can and should have rows in the
> job event table, but 'job-progress' should NOT have a
> row in the job event table (because of information
> explosion with page-by-page 'job-progress' rows).
>> Cheers,
> - Ira McDonald, consulting architect at Sharp and Xerox
> High North Inc
>> -----Original Message-----
> From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
> Sent: Thursday, June 01, 2000 11:16 AM
> To: McDonald, Ira
> Cc: 'ipp at pwg.org'; 'jmp at pwg.org'
> Subject: Re: IPP> Very small Job Mon traps (IPP notifications) - 31 May
> 2000
>> 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
> > }
> >
> > ------------------------------------------------------------------------