Thanks for taking the time to help me understand the Job MIB.
I appreciate it. (I really do!)
I realize some of my questions sound like I'm asking you to spoon-feed
me on some of these issues and topics. Please be patient and indulge
me for a moment. Imagine I'm a newbie to the Job MIB, one who is thinking
about using the Job MIB to solve a problem surrounding job state monitoring.
> >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]
Sorry, but I probably didn't state the question correctly. When I asked
for a list of mandatory "elements", I meant MIB objects, not just attributes.
(You discuss such mandatory elements later in your message.)
Here I am asking: What is the minimum skin I have to put in the game to
get going? I look at the Job MIB and it looks, well...real complicated.
I'm just trying to see where to get going in solving my problem.
> 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.
Sounds funny to ask "should jobName and jobOwner be mandatory?" How does
my app identify the jobs currently in the table?
> At 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".
Thanks for the fine pointers to the spec. I'll admit that it's been
a while since I had last read them, so I'll take another look.
However, here's a very explicit example of the complexities in the
Job MIB; this text was in your descriptions of the pointers for me
to examine for "functional model":
> 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.
Say what??? Can I have that in English, please? ;-)
Really, though, this kind of "description" scares the bejeezes out of us.
Pray tell, is the term "multi-plexed" a common SNMP-related term?
Or was it expressly invented for use in the Job MIB? ;-)
> 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.
Hmmm, let me state that last question is bit differently, albeit in a
hypothetical manner:
So an application can access the same information either by using the
Job State MIB or the Job Accounting MIB.
I'm starting to like that statement a lot better, actually.
> >Another key question we've danced around over the years is how closely
> >is the Printer MIB related to the Job MIB?
>
> [...]
>
> 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.
Sounds like a good plan, Tom. Just to make sure I understand your above
explanation:
Those objects in the Job MIB having a corresponding relationship in the
Printer MIB have values that are entirely independent of the Printer MIB.
That is, an application using the Job MIB does not need to know anything
about the Printer MIB in any way in order to take advantage of all the
features provided by the Job MIB.
Is this correct?
> >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.
Sorry, but I don't think you answered my question.
You state that only 8 out of 78 (!) attributes have both integer and string
forms. But you didn't say WHY having multiple forms was necessary in the
first place.
> >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.
Your description certainly paints a decent picture of simplicity. However,
why are the threads between yourself and Harry over the last couple of weeks
so gawd-awfully convoluted? For something so simple, it sure looks so
complex.
Speaking of those "8 mandatory attributes":
> jobState(3)
> numberOfInterveningJobs(9)
> deviceAlertCode(10)
> jobKOctetsRequested(48)
> jobKOctetsCompleted(50)
> impressionsRequested(54)
> impressionsCompleted(55)
> outputBinName(35)
Why is outputBinName mandatory, yet the same is not true for the
input tray name?
> 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.
Hey, when I repeatedly asked for a "small number of objects", I didn't
mean for the Job MIB to turn into the virtual Rubick's Cube of MIB
technology. I mean, all this "multi-plexed AssociatedValue" stuff is
just too much, IMHO.
And speaking of opinions, I sure wish others besides yourself, Harry and
myself spoke up about these issues.
If my opinions represent a minority view, then I'd sure like to know.
> >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.
I'm glad you asked, Tom.
I'm concerned whether any other vendors are planning on implementing
this Job MIB, or will it go the same route as NPAP. (It took three
years to nail down NPAP...and the Job MIB will soon be approaching
that same period.)
Sure, I'm concerned with application implementation, that's our business.
But without implementations in the marketplace, we can't ship diddly.
Look how long it's taken to get a fair number of Printer MIB-capable
printers in the marketplace. Until only recently, Underscore has been
able to go after the market...after some three years of MIB development.
And now, with the rapid development of IPP, it's starting to look like
the Job MIB may never really have an impact in the marketplace at all.
Yep, I'm sure Xerox will eventually ship an implementation for the
standard Job MIB (along with their other implementations), but this is
a critical mass problem we're dealing with. Without a reasonably large
number of players, viable, attractive application solutions are not possible.
Again, thanks for taking the time to explain things, Tom.
...jay