>Harry,
>
>Was interoperability really shown? Given the variance is the results, I
>definately question your statement. Jay, as one of those application
>management vendors, what do you think?
Interoperability - YES. Perfection - NO. I don't think we can continue
this discussion (or perhaps the evaluation of results) until we define
our interoperability targets. Also, we can't put a variance meter on
the interop test and accept the reading at face value. Much of the
variancce that shows is due to variance in printer device implementations
themselves! Anyone managing printers lives within a certain range of
operational variability, no matter if they're dealing with a MIB, HTML
or whatever else we dream up.
I still don't know what you are getting at. Are you recommending the
IETF stifle the progression of RFC1759? Are you suggesting vendors
give up on it?
>I believe that the standardization of the 25 printer conditions will yield
>reasonable and useful results, but these are very, very basic conditions.
>What about all the rest. I have a list of 100 engine errors for
>one printer and a little over half of the errors on this list are not covered
>by the 25 printer conditions. As of yet, I don't have the list of formatter
>errors or channel errors but there are probably around another 50 of those.
>So I still have to make guesses on around 100 printer conditions. Granted,
>I may modify my responses based on the base 25, but the field is still
>wide open. What do I do when the disk is full? When the tray is lifting?
>When I need a different type of paper?
If anything, I think the IETF would say the PWG should have stopped at
the "basic 25" a long time ago. "Reasonable and useful results" regarding
"very basic conditions" (your words) seems to be just what the doctor
ordered if you look at SNMP philosophy.
The PWG had been criticized for going "overboard" with too many objects
but the (large) set does correspond well with our (complex) printer
model. The notion of a "top 25" tries to address consistency in error
reporting - just one element of the Printer MIB. By definition, the
alert table acknowledges device uniqueness (the LOC field) and by
design (post publication of RFC1759) we've migrated to generic alert
codes - realizing it could become a very tenuous task to maintain
fine granularity across vendors and across alert enums at the same time.
Formatter and Channel Errors? Can you give some examples? I've put
things like memory overflow in my product alert tables - a bit
reluctantly - imagining that a management application could determine
something about the configuration (needs more memory for the type of jobs
the printer is handling). Much more detail regarding Interpreter and Channel
errors, however, starts to sound a lot like job specific information -
something we consciously avoided while developing the printer MIB.
>The point is that these 25 errors will not solve our interoperability
>problems, it is really only a start. There a a whole lot more "common"
>errors out there.
Gail, if you have more "common" errors, please make a proposal. I
understand you weren't at Stardust when this happened live (which was
unfortunate 'cause you contributed so much to the test procedure). So,
you should take the opportunity to comment on the list. 25 was an
arbitrary number. We tried for less, actually, but nothing should
keep you from proposing additions if you feel strongly about then.
An example of this is Finishing Supplies low/empty. I felt strongly
about this but got a lot of opposition. So, guess what, I get to define
the proposal for this one. And, I might still get to live with the
rejection if consensus prevails that this is noise level compared to
some critical mass.
I still think it's good to vie for your particular candidates.
Harry Lewis - IBM Printing Systems