Tom,
> 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.
I'm sorry, but this is getting to be just plain scarry.
When I read "If outputBinIndex is made mandatory...", it makes me realize
that I don't have a good handle for exactly what the minimum conforming
implementation is at this point.
Can you post a simple text-only table of all the mandatory elements of
the Job MIB? (Something like one line per mandatory element would be
great.)
Tom, we are really getting down to the wire on the Job MIB (right????).
When you write words like:
"Just one more reason to get rid of the AssociatedValue object
and attribute..."
it makes me think the basic Job MIB functional model is not completely
thought out. It this stage of the game, we need to have the functional
model complete, wouldn't you agree?
Another key question we've danced around over the years is how closely
is the Printer MIB related to the Job MIB?
Didn't we come to the consensus where an agent supporting the Job MIB
did not necessarily have support for the Printer MIB? That is, there
should no binding between the Job MIB and the Printer MIB. Do I have
that right?
I certainly understand the desire to keep the two MIBs conceptually the
same, at least in terms of modeling characteristics, terminology, etc.
It's the explicit binding between the two that I'm asking about here.
> 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.
>> [...]
>> 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.
>> [...]
>> Should we allow an implementation to fill in both with meaningful values?
Can someone state the fundamental rationale for taking the approach of
having two enums, one for Integer and one for Octets? This is very
confusing to me. A few words of explanation might help here.
Why, oh why is the Job MIB so COMPLEX ???
To solve the #1 problem of "Is my job done yet?", we have devolved into
one of the most complex MIB definitions yet.
Doesn't this concern anyone else? (Hopefully some of the other vendors
doing a prototype can respond here.)
...jay