Here is my attempt to clarity the "printer-state" to allow an IPP Printer to
be able to rip one or more jobs while marking one. Look ok?
'3' 'idle': If a Printer receives a job (whose required resources are
ready) while in this state, such a job MUST transit into the 'processing'
state immediately. If the "printer-state-reasons" attribute contains any
reasons, they MUST be reasons that would not prevent a job from transiting
into the 'processing' state immediately, e.g., 'toner-low'.
If a Printer can interpret one or more jobs while marking a job, then it is
idle if it is available to interpret jobs even while marking a job.
If a Printer controls more than one output device, the above definition
implies that a Printer is 'idle' if at least one output device is idle,
i.e., the IPP Printer is available to immediately start processing a job if
a client submitted it.
'4' 'processing': If a Printer receives a job (whose required resources
are ready) while in this state, such a job MUST transit into the 'pending'
state immediately. Such a job MUST transit into the 'processing' state only
after jobs ahead of it complete. If the "printer-state-reasons" attribute
contains any reasons, they MUST be reasons that do not prevent the current
job from printing, e.g. 'toner-low'.
If a Printer can interpret one or more jobs while marking a job and receives
a job (whose required resources are ready) while in this state, such a
received job MAY transit into the 'processing' state along with the job that
is being marked, if any.
If a Printer controls more than one output device, the above definition
implies that a Printer is 'processing' if at least one output device is
processing, and none is idle.
'5' 'stopped': If a Printer receives a job (whose required resources
are ready) while in this state, such a job MUST transit into the 'pending'
state immediately. Such a job MUST transit into the 'processing' state only
after some human fixes the problem that stopped the printer and after jobs
ahead of it complete processing. Issue 30 The "printer-state-reasons"
attribute MUST contain at least one reason, e.g. 'media-jam', which prevents
it from either processing the current job or transitioning a 'pending' job
to the 'processing' state.
If a Printer can interpret one or more jobs while marking a job and receives
a job (whose required resources are ready) while in this state, such a
submitted job MAY transit into the 'processing' state in order to be
interpreted even while the Printer is in the 'stopped' state. However,
before such a job can be completed, a human needs to fix the problem.
If a Printer controls more than one output device, the above definition
implies that a Printer is 'stopped' only if all output devices are stopped.
Note: it is tempting to define 'stopped' as when a sufficient number of
output devices are stopped and leave it to an implementation to define the
sufficient number. But such a rule complicates the definition of 'stopped'
and 'processing'. For example, with this alternate definition of 'stopped',
a job can move from 'pending' to 'processing' without human intervention,
even though the Printer is stopped.
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Wednesday, May 05, 1999 01:20
To: anthony.porter at computer.org
Cc: ipp
Subject: RE: IPP> MOD - IPP/1.1 Issue #31
In order to close on IPP/1.1 issues Anthony Porter agrees to work with us on
adding the extra attributes for high end systems that rip separately from
marking as extensions to IPP/1.1, rather than adding them to the IPP/1.1
document at this time.
He suggests a more flexible definition for the new 'queued-for-marked'
job-state-reason which we have agreed to include in IPP/1.1 as part of the
resolution of ISSUE 31:
Suggested text for section 4.3.8 job-state-reasons:
'job-queued-for-marker': Job is in any of the 'pending-held', 'pending', or
'processing' states, but more specifically, but more specifically, the
Printer has completed enough processing of the document, to start marking
and the job is waiting for the marker. Systems that require human
intervention to release jobs using the Release-Job operation, put the job
into the 'pending-held' job state. Systems that automatically select a job
to use the marker put the job into the 'pending' or keep the job in the
'processing' job state while waiting for the marker, depending on
implementation. All implementations put the job into (or back into) the
'processing' state when marking does begin.
Also as part of resolving ISSUE 31, we will also clarify that an IPP Printer
can have more than one job in the 'processing' state (for the high end
printers that rip one or more jobs while marking one).
Finally, as part of resolving ISSUE 31, clarify that a job can remain in the
'processing' state even when the Printer is 'stopped', if that job is being
ripped; only the job that is being marked MUST be moved to the
'processing-stopped' state.
Ok everybody?
Thanks,
Tom
-----Original Message-----
From: Anthony Porter [mailto:anthony.porter at computer.org]
Sent: Monday, May 03, 1999 01:00
To: 'Hastings, Tom N'
Cc: 'Herriot, Bob'; 'Manros, Carl-Uno'
Subject: RE: IPP> MOD - IPP/1.1 Issue #31
Tom,
Yes, I realize that it is too late to incorporate many high-end extensions
into 1.1
For 4.3.8, it is possible for the job to enter 'job-queued-for-marker' even
though it has not been completely ripped, so the job could be in both
job-interpreting and job-queued-for-marker. How about:
'job-queued-for-marker': Job is in any of the 'pending-held', 'pending', or
'processing' states, but more specifically, the Printer has completed enough
processing of the document, to start marking and the
job is waiting for the marker.
There were a couple of anomalies in 4.4.10 in the Feb 17 text. One statement
said that a job could not be in the processing state if the printed had
stopped marking, and another said that only one job could in processing at a
time. Neither of these are true if there is a separate RIP unit.
Anthony