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

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

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

Peter Zehler peter_zehler at ocp.mc.xerox.com
Tue May 27 15:45:27 EDT 1997


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



More information about the Ipp mailing list