Stuart, far from appearing as if they are coming from a "novice", your
questions are very useful in guiding our Job MIB discussion. I thank you for
coming forward, letting us know you are interested, and participating in the
discussion. Please let me address several of your questions, if I may...
>1) Tom says there are only 8 mandatory attributes. But the rest are
> conditionally mandatory (snip)...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.
The simple answer is YES. The base interpretation of "conditionally mandatory"
is sorta "if you know it or can do it... you must not consider it optional".
Regarding your particular choices, however, I would say it is not always
"possible" for the SNMP AGENT in the printer to understand each of the
attributes you have listed. For example, we find that impressionsCompleted is a
much more manageable attribute than pagesCompleted.
>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?
Nested Jobs (or Documents within a job) has been one of the major "sore points"
in developing the Job MIB, right from the start. Nested jobs is one of the
reasons we ended up with a huge set of attributes. Originally, we tried to
"hard code" the notion of Jobs and Documents into ID and State tables in the
MIB but later realized, as you have pointed out, that many implementations
would be unaware of nested jobs. Thus began the trend to make things (like
documents) conditionally mandatory and move them to the attribute table. This
was a good move on part of the JMP team. But the crux of the nested job problem
lies mainly in the job submission protocol... not the job MIB. And most of what
we call nested jobs is really little more than a separator sheet being placed
with the job - something which the end-user gains very little from having this
distinguished in the monitoring behavior of the MIB.
>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?
OK, Stuart. Here's where you ARE showing your Novice status. You obviously have
never heard of DPA, have you? (I'm kidding...). The huge number of job state
reasons is probably the most obvious indication of philosophical differences
between Job MIB designers. This list is the herald of Server vs. Printer
implementation differences.
I have to give Tom credit for yielding, however, and, again, specifying the job
State Reasons as attributes - thus not "forcing" them into every
implementation.
Are you beginning to see why the Attribute table has become a "catch-all"
table?
In trying to simplify the Job MIB, every item which appeared unrelated to a
simple printer
implementation has ended up as an attribute.
To answer your question directly, I don't think there is anything preventing a
printer from implementing a subset of JobStateReasons - or *no* 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.
You've hit the "mother lode" of JMP problems with this question. Before IPP was
even a speck on anyone's white paper, the JMP was calling for a "standard
submission protocol". I made a proposal a year ago for a simple "Job Attribute
Wrapper" (not what I called it, but might wish I had) to accompany submission.
Your observation is correct. Accounting will be hamstrung without these
submission
attributes.
As recently as two meetings ago, Bob Pentecost of HP made some overture
regarding
possible extensions to PJL with this regard and has discussed jmJobSubmissionID
here, on the mail list. I think Bob is doing the right thing in considering
standard PJL extensions to support the Job MIB. I haven't heard anything from
Adobe regarding this topic. Also, obviously, IPP could become the standard
submission protocol we're looking for, but I doubt it will become the
one-and-only
protocol and I don't think we're doing a very good job as PWG of coordinating
IPP
and the Job MIB, so there might be some holes to patch.
>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?
The attribute table implementation is not so daunting. In fact, if we did away
with the JobStateTable as Tom would have it, that would make one less group to
implement and JobState has the jmJobAssociatedValue object which is a bit
"tricky" as SNMP goes, because the value depends on the state. But there is a
trade-off. The daunting part of the attribute table is the indexing. The agent
must be implemented, I don't think there is any desire to completely do away
with
the attribute table... but, indexing into the attribute table will have a cost
in
terms of performance (we don't have any really measure of this just yet). We
feel
the JobStateTable is a more straightforward and optimized means of obtaining a
good indication of job progress and current state. The main downside of the
JobStateTable that I see is that it's definition will be rigid. If everything
is an attribute, and you can get enough attributes on one GET, then some
applications could get jmJobState along with their 12 favorite attributes while
others could just go after JobState plus 9. With the JobStateTable and the
jmJobAssociatedValue... there is a fixed relationship... PENDING - QUEUE
POSITION;
PRINTING - CURRENT COPY; COMPLETED - OUTPUT BIN... etc. I want everyone to
realize
this and especially I'd like app writers to comment. The main trade-off is ease
of
indexing vs. flexibility (a pretty traditional engineering scenario)!
Harry Lewis - IBM Printing Systems