We also agreed on the telecon that we need to agree on the requirements for
the functionality of various operations first. And we need to agree on how
the operation is intended to be usage (use case).
Here is a start on the Set2 and Set3 requirements and usage:
1. Have separate operations for affecting the IPP Printer versus affecting
the output-device, so its clear what the intent of each is and implementers
can implement one or the other or both.
2. Need a Printer operation to prevent a Printer object from accepting new
IPP jobs, but currently accepted jobs continue unaffected to be scheduled
and processed. Need a companion one to restore the Printer object to accept
new IPP jobs.
Usage: Operator is preparing to take the IPP Printer out of service.
Suggested name and operations: Disable-Printer and Enable-Printer
3. Need a Device operation to prevent an output device from accepting any
new jobs from any job submission protocol and a companion one to restore the
output device to accepting any jobs.
Usage: Operator is preparing to take the output device out of service.
Suggested name and operations: Disable-Device and Enable Device
4. Need a Printer operation to stop the processing after the current IPP job
completes and not start processing any additional IPP jobs, but continue to
accept new IPP jobs. Need a companion operation to start processing IPP
jobs again.
Usage: Operator is ???
Suggested name and operations: Pause-Printer-After-Current-Job,
Resume-Printer
5. Need a Device operation to stop the processing the current job
"immediately", no matter what protocol. Its like the Pause button on the
output device. This operation is for emergencies. The stop point depends
on implementation, but can be mid page, end of page, end of sheet, or after
a few sheets for output devices that can't stop that quickly. The paper
path isn't run out. Need a companion operation to start processing the
current any-protocol job without losing any thing.
Usage: Operator sees something bad about to happen, such as the paper is
about to jam, or the toner is running out, or the device is overheating or
wants to add more paper.
Suggested name and operations: Pause-Device-Now, Resume-Device
6. Need a Printer operation to stop the processing of IPP jobs after all of
the currently accepted jobs that have been processed, but any newly accepted
jobs go into the 'processing-held' state.
Usage: This allows an operator to reconfigure the output device in order to
let jobs that are held waiting for resources, such as special media, to get
a chance. Then the operator uses Resume-Printer after reconfiguring. He
repeats the two operations to restore the output device to its normal media.
Suggested name and operations: Pause-Device-After-All-Current-Jobs,
Resume-Device
7. Need a Device operation to stop the processing the current any-protocol
job at a convenient point, such as after the current copy (or end of job if
last or only copy). Need a companion operation to start processing the
current any-protocol job or next job without losing any thing.
Usage: The operator wants to empty the output bin that is near full. The
paper path is run out.
Suggested name and operations: Pause-Device-After-Current-Copy,
Resume-Device
7a. ISSUE: Maybe need a Device operation that always pauses on a job
boundary, no matter how many copies, in order to not break up a job? Need a
companion operation to start processing the current any-protocol job or next
job without losing any thing.
Usage: The operator wants to empty the output bin that is near full, but he
doesn't want to break up a job in case it has multiple copies. The paper
path is run out.
Suggested name and operations: Pause-Device-After-Current-Job,
Resume-Device
8. Need a Printer operation that combines Disable-Printer,
Pause-Printer-After-Current-Job, and rejects all other Job, Printer, and
Device operations, except Job and Printer queries, System Administrator
Set-Printer-Attributes, and the companion operation to resume activity. In
other words, this operation makes the Printer a read-only object in a
graceful manner for end-users and the operator.
Usage: The administrator wants to reconfigure the Printer object using the
Set-Printer-Attributes operation without disturbing the current in process
work, but wants to make sure that the operator isn't also trying to change
the Printer object as part of running the Printer.
Suggested name and operation: Deactivate-Printer, Activate-Printer
9. Need a Device operation that combines Disable-Device,
Pause-Device-After-Current-Copy (Current-Job?), and rejects all other Device
operations, except Job and Printer queries and the companion operation to
resume activity. In other words, this operation makes the output-device a
read-only object in a graceful manner.
Usage: The field service person wants to open up the device without
disturbing the current in process work, perhaps to replace staples, or
replace the toner cartridge.
Suggested name and operation: Deactivate-Device, Activate-Device
10. Need a Printer operation to recover from the IPP Printer software that
has gotten confused (run out of heap memory or gotten into a state that it
doesn't seem to be able to get out of). This is a condition that shouldn't
happen, but does in real life. Any volatile information is saved if
possible before the software is re-initialized. No companion operation is
needed to undo this. We don't want to go back to the "confused" state :-).
Usage: The IPP Printer software has gotten confused or isn't responding
properly.
Suggested name and operation: Restart-Printer
11. Need a Device operation to recover from the output device hardware and
software that has gotten confused (gotten into a state that it doesn't seem
to be able to get out of, run out of heap memory, etc.). This is a
condition that shouldn't happen, but does in real life. Any volatile
information is saved if possible before the software and hardware is
re-initialized. This is the same and has the same options as the Printer
MIB reset. No companion operation is needed to undo this. We don't want to
go back to the "confused" state :-).
Usage: The output device has gotten confused or need resetting to some
initial conditions.
Suggested name and operation: Reset-Device
12. Need a Printer operation to put the IPP Printer object out of business
with no way in the protocol to bring that instantiation back to life. (but
see Startup-Printer which brings a new instantiation to life with the same
URL).
Usage: The Printer is being moved or the building's power is being shut
off.
Suggested name and operation: Shutdown-Printer
13. Need a Printer operation to bring an IPP Printer to life when there is
an already running host. Note: This operation is unlikely to be supported
for the embedded Printer configuration.
Usage: After the host is started (by means outside the IPP protocol), the
operator is able to ask the host to bring up any number of Printer objects
(that the host has been configured in some way) each with distinct URLs.
Suggested name and operation: Startup-Printer
14. Need a Device operation to power off the output device after writing out
any software state. It is assumed that other operations have more
gracefully prepared the output device for this drastic and immediate. There
is no companion Device operation to bring the power back on.
Usage: The output device is going to be moved, the power in the building is
going to be shutoff, the repair man has arrived and needs to take the output
device apart.
Suggested name and operation: Power-Off-Device
I'll add these requirements and usage to the beginning of the Set2 spec, so
that the parallelism between the Printer and the Device operations can be
seen, even though the Device operations will be in the separate Set3 spec,
ok?
Comments?
Thanks,
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Thursday, December 09, 1999 09:02
To: ipp
Cc: Hastings, Tom
Subject: IPP> OPS - Agreements on Set2 from 12/8/99 telecon - comments?
At the IPP telecon we reached the following agreements which I'll put into
an updated Set2 spec today for the L.A. meeting, 12/15/99:
1. We'll decide on final names for the Set2 and Set3 operations next week in
L.A. after we understand and agree to the semantics for each operation.
2. Instead of Quiesce-Printer, Restart-Printer, Quiesce-Device, and
Restart-Device, we will use the working names: Deactivate-Printer,
Activate-Printer, Deactivate-Device, and Activate-Device. These should be
more easily translatable to non-English and more easily understood by
non-English speakers. These operations allow the Printer to be queried and
the Printer and Device to be Activated. They don't initialize the software,
so they aren't used to recover when the software gets confused. They are
used to just make the Printer or Device by read-only and not do anything.
They MUST be implemented in pairs.
3. Reset-Device does reinitialize the software as well as resetting the
hardware. It has the same semantics as the Printer MIB reset.
4. Restart-Printer also re-initializes the software, so that if the software
processes/threads have become corrupted, the Restart-Printer straightens it
out.
5. Some people want a Shutdown-Printer which cannot be brought back to life.
Instead, the operation uses a Restart-Printer to start up a new
instantiation of the Printer object (with the same URL).
6. Power-Off Device cannot be brought back with any IPP operation. If the
IPP Printer is embedded in the output device, then Power-Off also affects
the IPP Printer. However, if the IPP Printer is hosted, then it is
unaffected by the Power-Off Device operation. This is one case where the
semantics of the operations would appear to depend on the configuration.
However, Power-Off does first write the state of the software to persistent
storage, so that when the device is started (by means outside the protocol),
the jobs are not lost.
7. Instead of Pause-Printer "when" = 'after-current-job',
'after-all-current-jobs'
and Pause-Device "when" = 'now', 'after-current-copy' have four distinct
operations that can be implemented or not and queries for support:
Pause-Printer-After-Current-Job = what Pause-Printer in IPP/1.1 is
Pause-Printer-After-All-Current-Jobs
Pause-Device-Now
Pause-Device-After-Current-Copy
ISSUE: However, Pause-Printer is already published in IPP/1.1 with the
following general implementation-dependent options:
This OPTIONAL operation allows a client to stop the Printer object
from scheduling jobs on all its devices. Depending on implementation, the
Pause-Printer operation MAY also stop the Printer from processing the
current job or jobs. Any job that is currently being printed is either
stopped as soon as the implementation permits or is completed, depending on
implementation. The Printer object MUST still accept create operations to
create new jobs, but MUST prevent any jobs from entering the 'processing'
state.
The IPP Printer stops the current job(s) on its device(s) that were
in the 'processing' or 'processing-stopped' states as soon as the
implementation permits. If the implementation will take appreciable time to
stop, the IPP Printer adds the 'moving-to-paused' value to the Printer
object's "printer-state-reasons" attribute (see section 4.4.12). When the
device(s) have all stopped, the IPP Printer transitions the Printer object
to the 'stopped' state, removes the 'moving-to-paused' value, if present,
and adds the 'paused' value to the Printer object's "printer-state-reasons"
attribute.
So are we changing the IPP/1.1 Pause-Printer definition by nailing down what
had been implementation-dependent options? Or are we adding two additional
Pause-Printer operations?
So we have the following operations with the following working names. The
actual names will be selected in L.A. after the semantics are agreed:
Printer operation Corresponding Device operation
----------------- ------------------------------
Pause-Printer-After-Current-Job Pause-Device-Now
Pause-Printer-After-All-Current-Jobs Pause-Device-After-Current-Copy
Resume-Printer Resume-Device
Purge-Jobs Purge-Device
Get-Printer-Attribute no
Set-Printer-Attributes no
Disable-Printer Disable-Device
Enable-Printer Enable-Device
Deactivate-Printer Deactivate-Device
Activate-Printer Activate-Device
Restart-Printer Reset-Device -- these 2 lines aren't
pairs
Shutdown-Printer Power-Off-Device
6. Printer operations MUST NOT be forwarded
Job operations MUST be forwarded to affect the intended job wherever it
is
Device operations MUST NOT be forwarded when there is fan-out of any kind
(output-device fan-out or Printer object fan-out)
Device operations MUST be forwarded if there is only one subordinate
Printer (the chained case), so that there is no difference to an operator
client whether the first Printer is using IPP or some other protocol to
control the downstream device (singular).
7. There will not be any roll-up of fan-out device state or Printer object
state, and state-reasons, except the "printer-state" 'stopped' and the
'stopped-partly' printer-state-reasons.
Therefore, we don't need the 'device-xxx-failed' set of values. If a Device
operation fails, then the 'moving-to-xxx' state reason is removed and that
indicates the failure.
We probably need the two values for the following Device operations,
(including the new or renamed ones suggested above):
device-moving-to-disabled, devices-disabled
device-moving-to-enabled, *
device-moving-to-purged, devices-purged
device-moving-to-quiescent, devices-quiescent
device-moving-to-restarted, *
device-moving-to-reset, *
device-moving-to-powered-off, devices-powered-off
Send comments to the DL.
Thanks,
Tom