Subject: JMP> Comments from a novice

From: Harry Lewis <[email-masked]>
Date: Mon, 12 May 1997 13:03:01 -0400

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

---

From: [email-masked]
Date: 13 May 97 20:16:48 EDT

Harry,
     
Thanks for your thorough response.
     
I'm still not sure about this "conditionally mandatory" business.  You 
said: 
     
>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.
     
Ok, pagesCompleted may be ambiguous to the agent because it might be printing 4 
up without knowing it, but what about sheetsCompleted?  It is not mandatory, but
a printer will always know this, therefore wouldn't it be considered mandatory 
for all printers which implement the job MIB?  Later, you said:
     
>printer from implementing a subset of JobStateReasons - or *no* 
>JobStateReasons."
     
With reasons such as "successfulCompletion" I don't understand how 
JobStateReasons could be conditionally mandatory.  It may be useful to list 
which attributes would normally be considered mandatory in a printer agent and 
which would normally be considered mandatory in a server agent.
     
>never heard of DPA, have you? 
     
Hey, I resent that! I've been a member of the Drug Prevention Association for 
years!

>submission attributes.
     
>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.
     
I remember discussing the PJL extension for JobSubmissionID.  PJL and PS 
extensions are definitely a step in the right direction, but I think we need to 
focus more energy in this area.  With no clear standard job submission protocol 
the job MIB will be pretty impotent.  Until the JMP group articulates its plans 
in this area more clearly, I believe it will be a BIG impediment to wide spread 
implementation of the job MIB.  If IPP is going to become THE standard job 
submission protocol, the JMP group needs to carefully evaluate how this will 
impact the JMP effort.  Unfortunately, aside from Tom, I don't think many of the
IPP group is much aware of what's going on in JMP.  
     
Regarding the attribute table vs. the JobStateTable...
Of course, we are going to discuss this in San Diego.  I don't profess to 
understand all the issues, but I like the concept of a separate 
JobStateTable that provides quick easy access to the most commonly needed 
information.  I also see that the JobStateAssociatedValue attribute is 
complex and may be tricky to implement and there is also the issue of 
duplication with the AttributeTable.  Let's see how the others feel.

Stuart Rowley
Kyocera Electronics