Jay,
>> 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?
>>It could very well be. Underscore has studied this problem over the
>last year or so, and it appears to be a very difficult nut to crack.
>So much so, that we now agree with Harry (and some others) in stating
>that the Job MIB should be constrained to a simple client-server
>model...with no intervening print server concept. Just a "client"
>(server, mgmt app) talking to a "server" (printer, print server).
I agree that this problem is a tough one to solve. But, I think that
constraining the MIB to a simple client to one-server model will
result in a MIB that is useless to a huge portion of the existing
market. How will the simple model allow Netware-based customers to
monitor their jobs as they progress from client to netware print queue
to one of perhaps several printers that may service the queue? What
good is this MIB if it does not provide a solution for the majority of
the non-unix customer base?
>> 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.
>>Then why on earth didn't you just propose the solution as developed by
>Xerox, for heaven's sake?? Why did you constantly view the Job MIB
>effort as a "fundamental research activity", apparently ignoring any
>and all existing practice?
In Tom's defense, the original proposal to the PWG by Tom was in fact
the Xerox proprietary solution with a very few proprietary objects removed.
Thanks,
Angelo