IPP> Very small Job Mon traps (IPP notifications) - 31 May 20 00

IPP> Very small Job Mon traps (IPP notifications) - 31 May 20 00

IPP> Very small Job Mon traps (IPP notifications) - 31 May 20 00

McDonald, Ira imcdonald at sharplabs.com
Fri Jun 2 09:11:20 EDT 2000


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
>     }
>
> ------------------------------------------------------------------------



More information about the Ipp mailing list