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@hitachi-hkis.com]
Sent: Thursday, June 01, 2000 11:16 AM
To: McDonald, Ira
Cc: 'ipp@pwg.org'; 'jmp@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
> }
>
> ------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Fri Jun 02 2000 - 09:20:48 EDT