So we needed you on the agreed to joint IPP/JMP call last Wendesday.
>
>Ron, you didn't mention that the IPP job states do not include held
>(pending, processing, cancelled, aborted, and completed). I believe there
>is also an important distinction between held and pending and that there
>should be both held and pending states.
Again, JMP can have additional states, not in IPP, if we want to.
So JMP could have the held state and the needs-attention state, if we
want to with a clear mapping for an agent to use that is instrumenting
an IPP system. However, I had the sense from JMP that we wanted to
align more directly with IPP and only have additional reasons, not
additional states, so that is what I have written up for JMP.
>
>I think the jmJobStates of Held, Pending, Processing, Needs Attention,
>Cancelled, and Completed are the best at providing the necessary
>information WITH A SINGLE OBJECT. As Harry has said, most printer agents
>can tell the whole story (as they know it) with just these job states.
But what about the pending job that is waiting for a printer that
has stopped printing the current job? The problem with needs-attention
as a state, in stead of a reason, is that it only can be for the
current job, not the pending jobs (Unless all the pending jobs jump
into the needs-attention state too, which I hadn't thought anyone wanted,
since that would lose the information as to which job or jobs were
actually currently printing).
> The
>JobStateReasons are things the printer agent typically doesn't know about.
Isn't the job of the agent to map what ever state information it can get
from the device to the MIB? So if the agent has to map the information
to a reason or to a state, its the same amount of work.
>
>Perhaps IPP is hung up on the semantics such as that a hold is really a
>reason it is pending. I can perhaps see the theoretical justification for
>having held as a reason for the state pending. But, I believe users, as
>opposed to us grizzled standards developers, would immediately see the
>utility of having held as a separate state from pending, with pending
>applying only to jobs that are waiting and have not been put on
>administrative hold. The user may then choose to see the reason why it is
>held or pending. This same arguement applies to the Needs Attention state
>as opposed to making Needs Attention a reason under the one of the other
>states. It is just more useful to have Held and Needs Attention as job
>states rather than reasons!
The MIB isn't the UI for the user (though many applications just map the
MIB to a UI.) So an application could show any reason as a state, if it
wanted to.
>
>Stuart Rowley
>Kyocera Electronics, Inc.
>
>
>______________________________ Reply Separator
_________________________________
>
>
>
>I agree with all the changes proposed for alignment of the IPP and
>JMP job states except for the removal of "Needs Attention". This
>should be the most important state to indicate to a user since
>unless he takes action the job may never complete. I would think
>that this would also be very important for IPP as well.
>
>I also agree with Harry that "requiredResourcesNotReady" and
>"serviceOffLine" apply better to "Needs Attention" than "Held".
>(I also agree with Harry that "Printing" is a better description
>for a user than "Processing". Since this is an enum, a user or
>management ap can display whatever text that is deemed
>appropriate. So I will vote to keep "Processing" unless there
>is very strong support for "Printing".)
>
>(Didn't we discuss "serviceOffLine" in a previous meeting and
>determined that no one except Dataproducts has ever implemented
>such a capability? I also indicated that I had recently deleted
>the feature because I felt it was "stupid".)
>
>Also, I agree with Jay that "Needs Attention" should apply to all
>conditions, other than "Held", that prevents the job from printing.
>"Held" only implies an administratively set condition.
>
>Tom, since I could not participate in the Wednesday conference call,
>could you explain why "Needs Attention" was not accepted by IPP?
>It is very critical that JMP and IPP agree in this area and I would
>hope this can be resolved quickly.
>
>
> Ron Bergman
> Dataproducts Corp
>
>
>
>
>