Jay,
You ask some good questions here. We need to discuss what is needed to
make the Job Monitoring spec be the thing that is being prototyped.
Lets put this discussion on the JMP agenda for next week?
Is it some of the remaining issues, such as how a client can find
a particular job that passes through a server to a Printer with the MIB?
Does it take proprietary solutions to solve this problem, so that that
is why implementors are doing something based on the spec, but not
actually implementing the spec. Perhaps the proprietary solutions
can be separate MIBs that merely augments a conforming IETF Job Monitoring
MIB? Or can we come up with an agreed means that doesn't require any
proprietary solutions?
Another reason is that, as HP points out, we need to better understand
how each object is used with each job submission protocol and in each
of the configurations that we are trying to support. How can we make
better progress on this part? I'll be glad to document the understandings
in the spec, so that they can be tested during interoperability testing.
Of course, another reason may be that the committee keeps evolving
the spec with each meeting, so that it is a moving target. Is this
a problem? Except for the remaining issues, I think we are reaching
more stability. We keep removing objects, so that now we are down to
only 21 mandatory objects (but we have 45 attributes, that are conditionally
manatory: you implement them if you got them).
Xerox has its own job monitoring MIB as well with its own solutions to
the above. Xerox would like to implement the IETF spec when it is
stablized.
Tom
At 16:44 03/28/97 PST, JK Martin wrote:
>Tom,
>>You wrote:
>>> Its clear from the responses to Jay's query, that there is
>> real interest in the Job Monitoring MIB.
>>Interest, yes. Work on a real prototype, NO.
>>Note that everyone made comments to the effect of either:
>> "We're working on a job MIB, and watching what's happening."
>>or perhaps:
>> "The job MIB we're developing is ``heavily influenced'' by the Job MIB"
>>No one actually said they were prototyping an implementation that actually
>follows the specification as it stands now. Note that I *explicitly*
>asked this question in my message:
>> "I know there are at least a few companies that have been involved in
> developing their own, proprietary Job-like MIBs, but how many folks
> out there are actually working on developing an implementation of
> the Job MIB as it is currently defined?"
>>If there is so much effort being expended on job MIB-related work,
>why is no one actually trying to prototype the proposed spec?
>>Does anyone have an answer to that question?
>>Oh, and Tom, by the way. How is Xerox's Job MIB prototyping effort
>going? I didn't see a "show of hands" from the Xerox camp. Can you
>tell us how you're doing on your prototype?
>> ...jay
>>