Harry,
> >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 would like to say that the only reason we even broached this topic is
> due to the "Job MIB in the SERVER" model. Why would a printer ever go so
> far as to implement an SNMP agent to do a Job MIB but not implement the
> printer MIB as well? So I really don't support the notion of totally
> uncoupling the MIBs when, for printer implementations, it makes
> greater sense to allow this association. Am I wrong about why we wanted
> to uncouple?
You ask:
"Why would a printer ever go so far as to implement an SNMP agent
to do a Job MIB but not implement the printer MIB as well?"
This sounds totally cogent to me. However, we would like to pursue
Job MIB support in non-printers (such as spooling servers) to allow
LPD and System V printing systems to be "visible" via SNMP and the
Job MIB. And, as you might imagine, we certainly don't want to be
in the position of also implementing the Printer MIB in those cases.
Let me ask a more pointed question, one that I would like to see Tom
answer:
"Does the Job Monitoring MIB require an agent to simultaneously
support the Printer MIB, and if so, what exactly is the binding?"
A quick table or list (in text, please) would suffice. If there is
no binding, then great. If there is, then the PMP group had better
be totally cognizant of that fact, and critical clarifications should
exist in the MIB draft to explain those bindings.
Hopefully the only bindings are those dealing with Textual Conventions.
...jay