Subject: JMP> Comments from a novice

From: [email-masked]
Date: 09 May 97 14:02:21 EDT

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