Tom,
> Gee Jay,
>> You want to add another attribute to IPP: job-sub-state
> and another object to the JMP jmJobTable: jmJobSubState?
>> This doesn't sound like simplicity and elegance to me.
>> Instead, we've shown the "refinement" of these substates, in the
> names of the states and not added any more attributes or objects.
>> That seems like the best of both worlds, namely show the refinement
> but keep the attributes and object simple.
Someday, once the dust finally settles on the JMP and IPP projects,
I'd be really interested in hearing your definitions and metrics
relating to "simplicity" and "elegance".
Unfortunately, the combined JMP/IPP dust is now swirling around at
around 50,000 feet...and is unlikely to settle soon. ;-)
> Or did you mean to add the sub-states as job-state-reasons which
> wouldn't add anymore attributes to IPP and objects to JMP?
Yes, Tom, this is the only natural conclusion here.
Better yet, no need to wait until the dust settles to do this. ;-)
The really sad situation here is that some folks want to model the job
problem/solution to achieve an extremely teenie-weenie minor performance
boost. That is, to only get a single MIB object instead of two (either
of which can be done by a single SNMP Get message).
Sorry, but perhaps the "puritan" nature of my engineering side has
surfaced on this topic, and hence my resistance to this kind of
bastardization of the IPP/JMP job model in general.
A job can be in many, many kinds of "states", depending on the features
(and attendant complexities) of the underlying printing system. However,
no matter what printing system is involved, all jobs will be in exactly
one of the three top-level "meta" states of pending, processing, done.
Below these three states, the mgmt application in question will decide
on the exact semantics of the job based on some *consistent* refinement
of the top-level state. Hence, the simple two-level model I have been
suggesting this past week or so.
...jay