At 17:07 05/01/97 PDT, Harry Lewis wrote:
>Classification:
>>Tom, a couple comments related to Output Bin and the Job MIB using draft v.81.
>> 1. Pg. 35 jobStateAssociatedValue is INTEGER. The Associated Attribute for
>state COMPLETED cannot be outputBinName, as you have specified. I had specified
>outputBinIndex, not Name.
I agree I created a problem. We can't fit an OctetString into 32-bits.
But changing the jobStateAssociatedValue to use outputBinIndex
brings up another issue, which I'm calling issue 73:
Issue 73 - If outputBinIndex is made mandatory, because the AssociatedValue
object and attribute require it, but an implementation doesn't have the
Printer MIB, the agent has to put 0 as the value. Should we add one more
attribute: outputBinNumber, which is just a number, not an index into the
Printer MIB? If we do, which should be mandatory? Just one more reason to
get rid of the AssociatedValue object and attribute, which is forcing us to
pick a particular outputBin implementation and make it mandatory. If we got
rid of the AssociatedValue object/attribute, we could forget about making
any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute
mandatory.
If we get rid of the AssociatedValue object/attribute, then we don't
need to add the outputBinNumber attribute either, since an implementation
can just put in the ASCII digits for the bin number into the outputBinName
attribute.
>> 2. Pg 35. jmStateAssociatedValue is SINGULAR. You have defined attributes
>outputBinIndex and outputBinName as Multi-Row. This is probably ok for the
>Attribute table but, for the JobStateTable, we need a single value to represent
>outputBin when the job is completed. I had specified a simple method as
follows:
>> -1 Unknown
> -2 Multi
> prtOutputIndex
>>I believe, as I've stated many times, the jmJobStateTable is very useful for
>JOB STATUS MONITORING (not job accounting). For accounting, I can (sorta) see
>where you might be interested in the multi-bin facet of outputs used. But, if
>you've submitted a job, I believe you want to know it's state, it's progress
>and it's final destination. If you asked for collated copies, that final
>destination might be (-2 Multi). I think that's enough to know, at that point.
>>I'd like us to go back to my proposal for outputbin on jmJobStateValue.
If we keep the jmJobStateAssociatedValue object and jobStateAssociatedValue
attribute, and agree to have something that fits into 32 bits, we should
have the minus values as you suggest. (Though I would think we should
use -1 for multi (other), and -2 for unknown, as we do elsewhere in this
MIB and the Printer MIB.
On the other hand, ISSUE 73 is still with us, even if we put in the
negative values.
>>3. Pg. 41 You have separate attributes defined for output bin name and number.
>Yet, the attribute table is structured such that an attribute type (output bin)
>can have either an Integer or String representation. It is not necessary to
>have two enums.
I agree, that it isn't necessary to have two enums. We could have just
one enum, say, outputBin, which allows either the jmAttributeValueAsOctets
(for output bin name) or jmAttributeValueAsInteger (for output bin index).
We could even allow both to be used for the same row.
On the other hand, I think we considered this and decided that it was
cleaner and simpler to have two separate enums, one for the Integer
value and the other for the Octets value.
However, since you raised the issue, I've added it as Issue 74:
ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus?
Analysis of the 78 attributes shows that there are 8 attribute
pairs that could be collapsed into one attribute with the implementation
using either the Integer or the Octets value (or both) to represent
the attribute. The application would have to query both value objects.
But if it is using GetNext, it has to get both each time anyway.
Only if it is directly accessing an attribute would it have to get
both values. On the other hand, it would be fewer Gets than having
two attributes as we have now.
The 8 paris are:
physicalDeviceIndex physicalDeviceName
outputBinIndex outputBinName
mediumRequestedType mediumRequestedName
colorantRequestedIndex colorantRequestedName
colorantConsumedIndex colorantConsumedName
jobSubmissionToDeviceDateAndTime jobSubmissionToDeviceTimeStamp
jobStartedProcessingDateAndTime jobStartedProcessingTimeStamp
jobCompletedDateAndTime jobCompletedTimeStamp
Should we collapse them into the following:
physicalDevice
outputBin
mediumRequested
colorantRequested
colorantConsumed
jobSubmissiontToDeviceTime
jobStartedProcessingTime
jobCompletedTime
Should we allow an implementation to fill in both with meaningful values?
>>>Harry Lewis - IBM Printing Systems
>>