At 07:12 05/07/97 PDT, Jay Martin wrote:
>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.)
Here is lines 1007-1016 from the Internet-Draft 00 (V0.81:
The mandatory attributes are:
jobState(3)
numberOfInterveningJobs(9)
deviceAlertCode(10)
jobKOctetsRequested(48)
jobKOctetsCompleted(50)
impressionsRequested(54)
impressionsCompleted(55)
outputBinName(35) [but as Harry pointed out, has to
be an integer to fit with the
AssociatedValue object]
However, I have added Issue 76: So should jobName, jobOwner, and one of
deviceNameRequested or queueNameRequested be made Mandatory?
because they were mandatory when we had a Job Table, but when we deleted
the job table and moved them into the Attribute table, we didn't make
them Mandatory.
>>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?
I'm not sure what you mean by "functional model".
Lines 286-319, "1.2 Types of Job Monitoring Applications" has the three
models for applications: monitor one active job, monitor all active jobs
on a printer or server, and gather accounting or usage information on
completed jobs on a printer or server.
Lines 406-556, "3. Configurations for the Job Monitoring MIB", has the
three system configurations that the MIB is designed to support.
The current draft has two ways to access the 8 mandatory items:
a. The Job State Table represents 3 as mandatory objects and the other 5
with the "multi-plexed" AssociatedValue object which has a representation
that depends on the state of the job, i.e., which is a "fan out" to 5
different attributes depending on which of the 7 job states the job is
in.
b. The same 8 mandatory items ALSO exist as mandatory attributes in the
Attribute Table. So an application can access the same information
either by using the Job State table or the Attribute table.
>>>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?
Almost. We agreed that a conforming agent did not need to implement the
Printer MIB. Therefore, we shouldn't have any Mandatory attributes that
require the Printer MIB. On the other hand, for Conditionally Mandatory
attributes there is no problem with them being tightly coupled with the
Printer MIB, say, by being indexes into the Printer MIB.
Then an implementation that does include the Printer MIB can get tight
coupling. In other words, we are trying for a win-win here. Implementations
that also have the Printer MIB will be able to take advantage of that.
Implementations that don't have the Printer MIB will not be unduly short
changed in what they can express.
>>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.
I hope my answer helps.
>>>> 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.
First, not every attribute comes in two flavors: integer and octets.
Only 8 out of 78 do. Most attributes are by their nature, either an
integer or an octet string. File names and DateAndTime data types are
reprsented as octet strings. Counts, counters, and enums are represented
as integers.
>>>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.
Gee, I think it is one of the simplest MIBs!. It has only 4 groups, all
mandatory, with a total of 13 object. No read-write, no trapping.
True, in addition there are 8 mandatory attributes, and 70 conditionally
mandatory attributes, but implementations can do just the 8 mandatory
attribute or can do as many more as they want.
We could even simplify further, if we get rid of the Job State table and the
AssociatedValue multi-plexed attribute)! It would be only three groups, all
mandatory, for a total of 10 objects.
>>Doesn't this concern anyone else? (Hopefully some of the other vendors
>doing a prototype can respond here.)
Are you concerned about the implementation of agents or applications,
I'm not sure which. If you could give some specific concern about
complexity, that would help us understand your concerns.
>> ...jay
>>