>You know, you're the first person to respond to my "What next?" message
>on the SENSE mailing list. I really wonder how many people are interested
>in it...at least right now, anyway. Just so no one misunderstands,
>I really believe it is NOT in our best interest to push a spec effort
>when no one is really going to follow thru with it. It's just a waste of
>my time, as writing such spec language is quite time consuming.
It's been so hard, lately to keep up with all that's going on with PWG!
Plus a REAL job!! We're all in this boat (including YOU!) and I suspect
this has more to do with the (quiet) response than lack of interest.
Nonetheless, I agree... it's work you can't (and shouldn't) afford to
do if there's not a good chance that PWG members will make use of it.
>As far as SENSE and the printer goes, yes, the easiest (and best, IMHO)
>thing for a printer to do with SENSE is to embed a simple STEP.1 Publisher
>that speaks to (at least) one SENSE server. It really should be no big
>deal.
Let me get this straight. A STEP.1 publisher would not need to implement
the SENSE message format. Just the Text Event Protocol itself and this
is designed to work with standard networking protocols. Right?
Can I ask, how would a STEP.1 publisher communicate with a SENSE server?
Could it be via a telnet session? Is there a preferred method?
>SENSE should be able to address the asynchronous event requirements for
>the Job Monitoring MIB. At this point, I would suggest that the JMP group
>define all desirable events...but in an abstract sense (no pun intended),
>and not around SNMP Traps, etc. I wonder who in the JMP would be willing
>to start such an effort? SENSE or no SENSE, that effort must be done
>in the JMP sooner or later, anyway.
I would be willing to do this in a couple weeks after a major deadline
of mine passes. I'm a bit reluctant, because it seems every time we
try to define a practical set of (anything) what should be a few tweaks
turns into a free-for-all and, before you know it, we've made an
unscalable mountain of a (very useful) mole hill.
Sorry, it's late... and I'm feeling rough around the edges. This is not
aimed at anyone in particular, in fact the readers are probably thinking
I should take a look in the mirror (WHEREs that hrPrtDetectedErrorState
2nd Octet proposal... Harry?).
If I were to start with JMP events... it would look like this
JobEvent (Job Index; Time stamp)
Started
Completed (bin x)
PageCompleted (page n)
CopyCompleted (copy i)
Alarm (type)
Jam
Canceled (which means canceled, aborted, terminated etc)
Paused
I would stipulate that periodicity on PageCompleted is adjustable via
SNMP set or vendor specific (every page, every 3 pages, every 5
seconds no matter what page it catches etc.).
I'm sure we could find a few more good ones, but, like your current
STEP.1 proposal, a brief list like this could go a long way to
facilitating job management.
Harry Lewis - IBM Printing Systems