IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:

IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:

IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE:

Tom Hastings hastings at cp10.es.xerox.com
Mon Jun 2 21:09:21 EDT 1997

At 04:57 05/28/97 PDT, Peter Zehler wrote:
>The amount of time a job would be in the pending state on a non-queueing
> non-spooling printer could be noticable to humans.  It is dependant on the 
>size of the print jobs on the other channels.  

Then such a printer shall implement the conditionally mandatory
pending state.  But an implementation that never waited a human perceptible
time should not have to implement the 'pending' state.  Imagine that you
are building a product that is going to be tested against by a testing
company.  If 'pending' is mandatory and your product doesn't ever show
'pending', that testing company might say you didn't conform to the

>I think it would simplify things just to have the pending state mandatory.  
>Implementations could step through this state so quickly it would never be 
>noticable to humans.

If we spend much more time discussing this issue, it may be wiser to take
your suggestion and make 'pending' mandatory.

>How long would a job be in the pending state in your non-queuing, non-spooling
>IPP system?
>If the time is not noticable to humans, e.g., 100s of miliseconds, I would
>think that there wan't much point in simplementin the IPP state of 'pending'.
>If it was longer, so that end-users would see it for a while, while nothing
>was happending on the printer, then it would be good to implemente the
>IPP 'pending' state for your Printer object.
>So your point was not that 'pending' must be a Mandatory state, but
>that in your implementation of a simple, non-queuing, non-spooling printer
>you wanted to be able to implement 'pending'.  So we just have to find
>language that permits non-queuing, non-spooling printers to implement
>'pending', but doesn't require it.
>On the other hand, it might be simpler to mandate the 'pending' state
>and for implementations that don't queue or spool, the state would
>never be visible or would be visible for a very short period of time.

More information about the Ipp mailing list