Jay, Harry, and Tom,
I just had to respond so you guys didn't think no one else is paying
attention... ;-)
I have been reluctant to comment due to my lack of overall
understanding of the job MIB. Although I have been following the
e-mail and attending recent meetings, I do not have a deep
understanding of many of the issues.
I decided that at the risk of showing off my ignorance, it may be
useful to ask some rather basic questions which might occur to someone
unfamiliar with the project as they first dive in to do an
implementation.
Also, I'm am concerned about the complexity of the Job MIB (I think
Jay also commented about this once or twice ;-) ). It must be
frustrating to Tom to have us say that it is too complex without
giving concrete suggestions for simplifying it. Let me put it another
way. It seems too complex because when I read it I'm as confused as
heck, but I can't give any real constructive criticism if I don't
understand it very well! But, I will can at least comment on a few
things that I find confusing.
1) Tom says there are only 8 mandatory attributes. But the rest are
conditionally mandatory, as in "shall implement each conditionally
mandatory attribute, if the server or device that the agent is
instrumenting has the feature represented by the conditionally
mandatory attribute." Does this mean that for an agent in a printer,
attributes which can always be known by a printer, such as
printQualityUsed, tonerEconomyUsed, jobCopiesCompleted,
jobDocumentsCompleted, pagesCompleted, sheetsCompleted, etc., must
always be implemented? This seems to disguise how many items are
actually mandatory.
1a) Related to this is the question, if there is no indication to the
agent whether the job contains multiple documents, does the agent
implement just jobCopiesCompleted? or also jobDocumentsCompleted with
the same value since it assumed to be a 1 document job?
2) Roughly 15% of the job MIB document is spent describing
JobStateReasons. As an agent, do I really have to differentiate
between all these reasons? How do I implement just a small subset of
possible JobStateReasons?
3) There are some attributes in the job MIB that an agent can obtain
from the data stream, such as jobCopiesRequested. Others relate to the
printer MIB or hr MIB. But with many of the attributes it is not clear
how the agent gets passed the information. For items such as jobOwner,
jobName, submittingServerName, etc. where does the agent get this
information? Some of this stuff is now sometimes sent with the job via
PJL or PostScript. Are we hoping that PJL and PostScript (and other
job control languages?) will be used to send this information? Will it
be ubiquitous? Accounting information will not be very useful if only
50% of the jobs contain jobOwner information for example.
4) I think the Attribute Table design using AttributeType textual
conventions has reduced the number of objects in the MIB, but has made
it more confusing. The number of OIDs is less, but it does make for a
daunting Attribute Table! I don't have enough implementation
experience to really know which is better or easier to implement.
Harry is the Attribute Table as much of a beast as it appears to be?
Sorry this is so long winded, I'll just make one more comment. Jay
said he is starting to like the sound of a Job State MIB and a Job
Attribute MIB. Maybe this isn't as far fetched as it sounds. Like
Harry, I view the monitoring and accounting aspects of the MIB as
addressing distinctly different needs. Perhaps we should separate the
MIB to meet these different needs. We sure could make a simple Job
State MIB which would likely be implemented across the board!
Thanks for listening.
Stuart Rowley
Kyocera Electronics