1. A system has multiple interpreting units and multiple marking units.
Jobs have to be interpreted before they are marked.
If the printer system is interpreting on all of the interpreting units, then
it is probably in the processing state, even if all the output units are
idle. A new job would have to wait in the pending state until an
interpreting unit became free. This means that the overall state of the
printing system depends on the availability of an interpreting unit,
regardless of what the marker units are doing.
2. The same system as above, except the interpreted data is cached for a
while so that some jobs ( typically extra copies of a recent job) don't have
to be interpreted.
In this system a new job could go directly into processing even though all
the interpreting units are interpreting and the printer system is in the
processing state, because the new job does not need interpreting and there
is a marking unit free. The next new job does need interpreting and has to
go into pending until an interpreting unit becomes free.
3. An IPP server running on an old PC in the corridor, controls two
identical inkjet printers. The server appears as a single printer to
clients, and sends to jobs to whichever of the two printers becomes free
first. One of the two printers has a paper jam. The other is OK and the
server will accept jobs and print them on the serviceable printer. The
status of this IPP server is probably 'idle', since it will accept jobs and
print them. Even so, the IPP server ought to report 'printer-state-reasons'
'media-jam-error', to warn the operator to go and fix it.
This appears to contradict the MOD which states that none of the reasons may
prevent a job from completing. 4.4.11 states that if the printer reports an
error, the printer MUST be in the stopped state
4. An IPP server is embedded in an office laser printer that has several
output trays, The printer is in state 'processing' and is printing a long
job. A high priority job comes in. The printer can interrupt the long job
and print the high priority job, sending it to an empty output tray, and
then resume the long job. This contradicts the MOD that states that the new
job must only transit to processing when jobs ahead of it have completed.
The exception for separate interpreters does not apply in this case.
Cases 3 and 4 show that these anomalies are not restricted to mega-buck
systems.
I think that printer-states are most useful for stand alone printers where
the operator is likely to use IPP to administrate them. For more complex
systems the states become less useful for IPP clients. If the system has a
full time operator, it may be better if the IPP server never reported errors
to clients.
Perhaps it is better if the printer states were less specific, e.g.
'3' 'idle': Indicates that the system is running but that none of the jobs
are in the 'processing' state. If a suitable job arrives while a printer is
in the 'idle' state, the printer is likely to begin processing it
immediately.
'4' 'processing': Indicates that the system is running and that one or more
jobs are in the 'processing' state.
'5' 'stopped': Indicates that the system is not currently processing jobs,
even though one or more jobs may be in the processing state.
4.4.11 should allow the printer to return errors even when the printer is in
the 'processing' or 'idle' states.
Unfortunately, these changes might cause 1.1 servers to violate 1.0, since I
am not sure that the server will be able to report different states to
different clients. The server in example 3 above ought to report 'stopped'
to IPP 1.0 clients and refuse to start their jobs because one of the print
units is in error, and at the same time report 'idle' to IPP 1.1 clients and
print their jobs because the other print unit is OK.
-----Original Message-----
From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of Hastings,
Tom N
Sent: 11 May 1999 08:12
To: anthony.porter@computer.org
Cc: ipp
Subject: RE: IPP> MOD - IPP/1.1 Issue #31
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.
-