Harry has an action item from the Denver meeting to propose the semantics
for the Restart-Printer/Shutdown-Printer.
The set2 is located in:
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-set2
-991022.doc
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-set2
-991022.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-set2
-991022-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-set2
-991022-rev.pdf
There wasn't a lot of change, except that a bunch of issue got deleted
(without change to the document) and a few minor issues have been added.
Here is the change history for the 10/22/99 version compared with the
9/19/99 version:
1.1 Changes to the September 19, 1999 version to make the October 22,
1999 version
Adding or removing ISSUES that don't change the document are not listed
here. The following changes to the September 19, 1999 version to make the
October 22, 1999 version as a result of the IPP WG meeting in Denver, 9/99:
1. Added the Interpreter object.
2. Added the "device-name" operation attribute to handle passing
operations through the IPP Printer object to the device.
3. Added the out-of-band 'not-settable' to allow the Set-Job-Attributes
and Set-Printer-Attributes response to indicate the difference between an
unsupported attribute and a supported, but not settable, attribute in the
Unsupported Attributes Group.
4. Removed "when-values-supported" and "job-settable-attributes" and
"printer-settable-attributes" and "interpreter-settable-attributes" from the
list of attributes that MUST be read-only. So an administrator could
sub-set the policy on what when values are supported or which attributes can
be set.
Here are the 17 issues from the 10/22/99 version of the Set 2 operations:
ISSUE 1: Can a client determine the values of "when" that are supported for
operations (Pause-Printer, Reset-Printer, Shutdown-Printer, and
Pause-Current-Job)?
TH> Just add a "when-values-supported" that applies to all of the
four operations supported, with the exception of Pause-Current-Job.
For Pause-Current-Job, only the 'now' and 'after-current-copy' have
any meaning, so the other two values ('after-current-job' and
'after-all') don't apply.
HRL> Or, "just say NO". The client can't determine the values of
"when" supported. The client may specify a value of when and the
implementation will do it's best to deliver as close to the desired
behavior as possible within the constraints of the device or
environment. The client may determine the actual result based on
final status and/or notification feedback.
ISSUE 2 - Shouldn't the Printer object also be affected? In other words, if
the "device-name" is supplied with the Pause-Printer operation to pause the
actual device, shouldn't the Printer object also enter the 'stopped' state
with the 'paused' "printer-state-reasons" value set?
ISSUE 3 - From the Denver meeting, it was strongly urged that an IPP Printer
implementation that supports more than one device, i.e., fan-out, SHOULD
support device name. Can we make "device-name" REQUIRED if an IPP Printer
supports more than one device? If not, can we make "device-name" RECOMMEND
if an IPP Printer supports more than one device?
ISSUE 4 - An implementation is free to support the "device-name" operation
attribute on any operation, but NEED NOT support it on all operations, if it
supports it on some, correct?
ISSUE 5 - Could we specify a minimum set of operations which, if supported,
MUST also support the "device-name" operation attribute, if the
implementation supports the "device-name" operation attribute on any
operation?
ISSUE 6 (repeat of 2 ) - Shouldn't the Printer object also
be affected? In other words, if the "device-name" is supplied with the
Pause-Printer operation to pause the actual device, shouldn't the Printer
object also enter the 'stopped' state with the 'paused'
"printer-state-reasons" value set?
ISSUE 7 - Keep "printer-settable-attributes",
"interpreter-settable-attributes", and "job-settable-attributes" so that a
client can determine which subset of the Printer, Interpreter, and Job
attributes are settable? The decision in Denver was to delete
"printer-settable-attributes", "interpreter-settable-attributes", and
"job-settable-attributes". However, how can the client display to the user
what is possible? Just random trying seems completely contrary to the query
for capabilities philosophy in IPP. Also the IPP Printer has to validate
whether each Set operation is acceptable or not, so it may as well do such
validation with a queriable attribute, rather than a hidden (and
unconfigurable) mechanism.
ISSUE 8 - Because the Interpreter object is really a sub-class of the
Printer object, maybe we don't need a separate
"interpreter-settable-attributes" Printer attribute. In other words, for
those implementations that do implement the Interpreter object, they would
still indicate which interpreter attributes are settable by putting them in
the "printer-settable-attributes" attribute.
ISSUE 9 - Keep "when-values-supported" Printer Description attribute in the
spec? The decision in Denver was to delete "when-values-supported".
However, how does the client find out what choices to display to the user?
Also it really isn't a burden on the IPP Printer implementation since it has
to valid the value coming in anyway, so it may as well validate against a
Printer attribute, rather than some hard coded internal mechanism.
ISSUE 10 - For consistency with [ipp-mod], shouldn't this be singular even
though it is multi-valued, i.e., device-name-supported (1setOf name(127))?
ISSUE 11: What state does the Printer comes back up on Restart-Printer and
how can the client control?
Possible alternatives:
a. Restart-Printer always brings the Printer up Disabled
("printer-is-accepting-jobs" = 'false') and Paused ("printer-state" =
'stopped', and "printer-state-reasons" = 'paused') which is the state that
Shutdown-Printer leaves the Printer in. Then the operator issues
Enable-Printer and Resume-Printer when want to restore normal operation.
The client can automatically issues these addition 2 operations depending on
GUI options. Advantages: This is the simplest to implement, allows new
states to be added without changing the Restart-Printer operation, and can
have the same GUI interface as b:
b. Add a REQUIRED operation attribute to Restart-Printer,
something like "printer-condition" with values: 'disabled-and-paused',
'enabled-and-paused', and 'enabled-and-idle'.
TH 7/26: Remove the Shutdown-Printer 'standby' mode concept.
Shutdown-Printer always powers off eventually. Also remove
Restart-Printer operation all together. Instead change the
Disable-Printer and Enable-Printer operations to Disable-Operations
and Enable-Operations, so that individual operations are enabled
and disabled independent of the state of the Printer and don't
otherwise affect the state of the Printer.
HRL 9/18: How can the state of the printer not be effected when you
disable or enable it? Don't understand 2nd half of this issue
resolution.
DENVER MEETING> There was significant confusion as to the meaning of
shutdown. If a shutdown operation halts communications to the printer a
restart is not possible. It was agreed to include restart attributes
'restart-to-standby' (requires a two step process), 'restart-fully', and
'restart-sync'.
ACTION ITEM (Harry Lewis): make a complete proposal and submit for
approval.
If the Restart-Printer operation is supported, then the Shutdown-Printer
operation MUST be supported, since the Restart-Printer operation is
meaningful only after a Shutdown-Printer operation has been performed.
However, if the Shutdown-Printer operation is supported, the Restart-Printer
NEED NOT be supported.
Issue 12: Why? This is backward, if you ask me (HRL).
Denver meeting> Consider "shutdown-attributes" similar to
Windows "shutdown". Like:
* Completely power off (walk to printer to bring it back up
* Power off but listen for "restart" - shutdown to standby
Denver meeting> Also consider restart attributes.
* Restart to Standby (disabled and paused) (two step bring up)
* Restart (fully).
* Restart sych
ISSUE 13 - Can we think of a name for Non-Process-Run-Out that follows the
pattern of other IPP operations on Printers, namely Xxxx-Yxxx-Printer? How
about Non-Process-Run-Out-Printer or more simply Run-Out-Printer?
ISSUE 14 - Need to look at life cycle of the Printer versus
standby/power-down and the other operations that can be accepted. There can
be appreciable time between acceptance of this operation and when the final
state of the printer, either standby or powered down is reached. Is it ok
for non-submission operations to continue to be accepted during this time?
May need 'moving-to-shutdown'. What about 'moving-to-standby'?
TH> Add 'moving-to-shutdown' which the Shutdown-Printer sets
immediately (analogous to 'moving-to-paused'). Then the 'shutdown'
values means that the shutdown has completed (and is only meaningful to
a server implementation that hosts the Printer object). Thus the server
can still respond to a Get-Printer-Attributes operation after the
Printer is shutdown as stated in IPP/1.1.
HRL> Is this granularity really achievable enough of a wide enough
variety of environments to be reliable or, in reality, will this be
implementation dependent?
ISSUE 15 - Should we separate setting the device's power saver mode from
shutting the power off? We could have a separate operation, say,
Set-Power-Saver-Level, which takes an integer, starting with 0. A 0 means
full power on. Printer supports some number of levels above that, if any.
Then an operator could turn the device to full power at the beginning of the
day, so the first submission doesn't have to wait for the power save mode to
restore full power.
ISSUE 16: Is the current job automatically restarted when the Printer is
restarted? Or does some client have to issue a Restart-Job operation?
The question is moot, if we remove the Restart-Job operation, as
suggested:
TH 7/26: Remove the Shutdown-Printer 'standby' mode concept. Shutdown-
Printer always powers off eventually. Also remove Restart-Printer
operation all together. Instead change the Disable-Printer and Enable-
Printer operations to Disable-Operations and Enable-Operations, so that
individual operations are enabled and disabled independent of the state
of the Printer and don't otherwise affect the state of the Printer.
HRL> Then, how do we restart the printer?
ISSUE 17 - Since the semantics of Pause-Current-Job is different from
Pause-Printer, in that other jobs are processed, while this job is stopped,
should we have a different name for the verb, such as Suspend-Current-Job,
instead of Pause-Current-Job. Otherwise, users may be mistakenly think that
the printer is paused when the job is paused. If the name is changes, then
the 'job-paused' job state reason would also be changed to 'job-suspended'.