IPP Mail Archive: RE: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are the

RE: IPP> Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are the

Peter Zehler (peter_zehler@ocp.mc.xerox.com)
Tue, 27 May 1997 12:45:27 PDT

Tom,
You wrote:
If a simple output device implements IPP and doesn't queue or spool, wouldn't
the jobs in that output device never be in pending? Such a device would
refuse acceptance of another job, while it was processing its current job.
That is why pending is conditionally mandatory in IPP and therfore also in
JMP.

Would it help to indicate that if an implementation queues or spools,
that it shall implement the 'pending' state jobs that are queued or spooled
but are not yet processing?

Tom

[PZ] I am implementing IPP in a small printer that does not spool simple
print jobs. There can be a time when an entire print job is accepted by
the IPP printer and the back end of the physical printer is not yet ready to
process the job. At this point the job is blocked pending service by the
backend print system.
The IPP channel may accept only one job at a time. The print device may
service multiple print channels. From the time the job is accepted by the IPP
printer until the job is passed onto the native print system the IPP state would
be pending. I would not claim a job sitting in memory blocked on the submission
to the native print system is queued or spooled.
Pete