This trap is sent whenever the state of a job changes. The 'state of a job' is comprised by the aggregate values of the xcmJobCurrentState, xcmJobPriority, xcmJobStateReasons, xcmJobXStateReasons, xcmJobX2StateReasons, xcmDevicesAssigned and xcmDeviceStateOfDevicesAssigned fields of the job's table entries: This notification is sent whenever any of these values changes with the following exceptions:

1. Changes in xcmDeviceStateOfDevicesAssigned shall only generate traps when the job is in the processing state (NOTE - xcmJMDevicesAssignedGroup is deprecated)

2. Changes in xcmJobStateReasons, xcmJobXStateReasons, and xcmJobX2StateReasons shall only generate traps when the job is in the processing state (rare). The normal polling cycle will pick up any changes while the job is not in the processing state. Since most changes in reasons also accompany a job state change, the chances that a change in a reason will have to wait for the normal polling cycle is very small. For example, a requester further modifies a held job adding more reasons for it to be held will have to wait for the polling cycle, since the job does not change state (remaining in the held state).

NOTE - the hrDeviceIndex is included for convenience, even though the Printer MIB (RFC 1759) doesn't include hrDeviceIndex in its traps. Then the management station doesn't have to parse the received varBind OIDs on a trap in order to discover which device trapped.

NOTE - the addition of an entire row to the job tables corresponds to the acceptance of another job by the server. The state of the job changes from unknown to a specific value (usually pending). Therefore, the agent shall generate a trap when a job is accepted (so that the management station can display the newly arrived job in a timely fashion).

Similarly when the server removes a job because the job has been in the completed state for a sufficient time or the job has been deleted by a Delete operation, the SNMP agent shall reflect that removal by removing the row from the job tables, and shall generate a trap (since the state of the job has changed to non-existent).

The IETF Printer MIB maintains a table which serves as a sort of 'audit-trail' of recent alerts. There is no need for such a table here, since the job's tables will serve virtually the same purpose.

As with all SNMP notifications, critical applications cannot completely rely upon delivery: some amount of polling is recommended.

The variable-bindings of this trap have been chosen to give the minimum of information: the xcmJobIdentifierOnSystem value and hrDeviceIndex are provided. With these an application is able to obtain the full job table entry. An application has to look at the job tables anyway. The time of the alert is returned as part of any SNMP trap.

The hrDeviceIndex maps one-to-one with the PWG Job Mon jmGeneralJobSetIndex. (The PWG Job Mon does not require the Host Resources MIB, so the name of the primary index for all PWG Job Mon tables is not hrDeviceIndex, but serves the same purpose of allowing multiple instances in a single device or server.

The Job Alert's special semantics is covered by U.S. patent 5778183. This notification has the following special semantics:

o If the job's xcmJobClientId field is not empty, its value will also be appended to trap object ID.

NOTE: If the format of the xcmJobClientId is dotted decimal representation, then it will be encoded as a BER binary OID appended to the trap object ID.

NOTE: The BER binary OID shall not include the ASN.1/BER tag of 6 indicating an OID and shall not include the ASN.1/BER length field in octets of the OID.

This trap OID qualifier allows job-submission and monitoring applications to limit the alerts they receive to ones generated by jobs which they have submitted.

NOTE: The sum of the trap var bind values must be less than can fit into a PDU on any transport, roughly 540 octets on some transports. Thus implementers are warned to minimize the length of the xcmJobClientId and xcmJobIdentifierOnSystem objects.