Overview

The JOB MIB is complete, and has been submitted to the IESG in the form of an Informational RFC. The Job MIB represents the first, official PWG standard in that it is registered under the recently issued PWG enterprise OID subtree. Because IPP and the Job MIB overlap, somewhat, in function, there is interest in continuing to correlate the projects and clarify their interaction. Some people view the Job MIB in conflict with the desire to standardize one, all encompassing, server to device printing protocol. Others see it as a natural extension of existing SNMP agents which are supporting the IETF Printer MIB.

The JMP reconvened, in Austin, on 3/6/98, to consider the use of SNMP traps for Job MIB notifications. Several companies presented Job MIB trap registration, type and content designs for consideration. The Xerox and IBM designs for trap registration, filtering and distribution were shown to be similar and comparable with the latest SNMPv3 Traps and Informs. Our direction will be to emphasize use of these SNMPv3 methods rather than favor anyone's current proprietary design, unless the v3 security model is to cumbersome or the v3 methods are not backward compatible with SNMPv1. A first pass was established at standardizing trap Types and Content, both for Job MIB traps as well as IPP notifications.

Job MIB trap topics Discussed and Recorded

1. Job MIB traps do not address interpreter errors like "font not available". For device errors

effecting a particular job, the monitor should register for Printer MIB traps while the job is

making it's way through the print process.

2. We accepted "printDeadineExceeded" as a valid notification type during e-mail discussion on

the IPP list but realized in Austin that, if polling is the fallback, this trap is not necessary

because the application can set the minimum polling rate relative to the print deadline, if it

wishes.

3. The guideline for what causes a job trap and the content of the job trap varbind is that these

should directly pertain to monitoring job progress. There are many additional JMP and IPP

attributes which should be obtained via polling or standard protocol queries.

The currently defined set of trap types is:

The currently recommended trap content is as follows:
JMP Attribute

(trap content)

 Job Received Job Start Sheet Complete Collated Copy Complete Job Complete, Canceled, Aborted, Held, Released Job Entry Expire
jmJobSubmissionID Yes Yes
jmJobIndex Yes Yes Yes Yes Yes Yes
jmNumberOfInterveningJobs Yes
OctetsRequested Yes Yes Yes Yes Yes
OctetsProcessed Yes Yes Yes Yes
ImpressionsRequestedPerCopy Yes Yes* Yes* Yes* Yes*
ImpressionsInterpreted Yes Yes Yes Yes
ImpressionssCompleted Yes Yes Yes Yes
CopiesRequested Yes Yes Yes Yes
ImpressionsCompletedCurrentCopy Copies >1 Copies >1 Copies > 1 Cop>1
currentCopy Copies >1 Copies >1 Copies >1 Cop>1
CopyType Copies >1 Copies >1 Copies > 1 Cop>1
OutputBin Yes** Yes** Yes** Yes**
JobStateReasons1 Yes Yes Yes Yes Yes Yes
* The Job MIB agent will treat impressionsRequestedPerCopy in the following manner. If explicitly passed in on submission, this will be the value used. If there is no value passed in on submission, then the implicit value, derived from the final number of impressionsInterpreted for the first copy will be used. ** jmOutputBin may be multivalued 4. IPP established the requirement that any attribute may be requested in the response to any notification. This requirement reflects the idea that notification content can be treated just like the response to a query. This is unrealistic. With notifications, or traps, you pre-register for asynchronous events which will occur later in time. It would be a great burden on the agent, whether it be IPP or SNMP, to keep track, not only of who wanted which traps, but also what information they requested with each trap type! Still, some form of extensibility is desirable and may be considered. 5. It was noted, with SNMP, the VarBind passes the OID of each element. Therefore, defining trap content establishes mandatory attributes in the Job MIB. 6. There is an issue whether or not the VarBind must carry the conditional elements (ex. copiesRequested) if they have no meaning for a particular trap (i.e. when copy = 1). Tom and Harry will write up complete trap type descriptions and content definition.