ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-set2
-991029.doc
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-set2
-991029.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-set2
-991029-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-set2
-991029-rev.pdf
Here are the changes followed by the remaining 14 issues:
1.1 Changes to the October 22, 1999 version to make the October 29, 1999
version
Adding or removing ISSUES that don't change the document are not listed
here. The following changes to the October 22, 1999 version to make the
October 29, 1999 version as a result of the IPP WG meeting in Durham, 10/99:
1. Removed the Reset-Printer, Non-Process-Run-Out, and
Space-Current-Job operations from this Set2 spec and moved them to a new
Set3 spec for use with the new Device object, renaming them appropriately,
to Reset-Device, Non-Process-Run-Out-Device, and Space-Device.
2. Add the concept of parent and subordinate Printer objects to
formally represent fan-out. Mentioned the Device object that is in a new
[ipp-set3] spec.
3. Distributed the definition of the "when" operation attribute to the
Pause-Printer (IPP/1.1), Shutdown-Printer, and Pause-Current-Job operations
and listed the values that are appropriate to that operation only:
Pause-Printer: 'now', 'after-current-copy', 'after-current-job'
(default), and 'after-all'.
Shutdown-Printer: 'now', 'after-current-job' (default), and
'after-all'
Pause-Current-Job: 'now', 'after-current-copy' (default)
4. Deleted the "device-name" operation attribute and the
"device-names-supported" (1setOf name(127)) Printer Description attribute.
The latter will be part of the [ipp-set3] document.
5. Kept the "job-settable-attributes" (1setOf type2 keyword) and
"printer-settable-attributes" (1setOf type2 keyword), but deleted the
"interpreter-settable-attributes (1setOf type2 keyword), since the
Interpreter object and its attributes are really a sub-class of the Printer
object.
6. Deleted the "when-values-supported" (1setOf type2 keyword) Printer
Description attribute.
7. Added the "subordinate-printers-supported" (1setOf uri) Printer
Description attribute.
Here are the remaining 14 issues:
ISSUE 01 - What sub-set of the REQUIRED IPP/1.1 operations MUST a
subordinate Printer object support? Get-Printer-Attributes? Any others?
ISSUE 02 - Are there any IPP Printer or Job operations that a subordinate
Printer MUST NOT support?
ISSUE 03 - Are all the REQUIRED attributes of a Printer object REQUIRED for
a subordinate Printer object?
ISSUE 04 - Ok not to have a way to reset the values of the Printer object to
the factory settings, but only have a way to reset the factory default
settings for the Device object?
ISSUE 05: 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'.
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 06: 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 07 - 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 08 - Ok to remove the 'after-current-copy' value from
Shutdown-Printer?
ISSUE 09 - Ok to have removed the "shutdown-function" operation attribute
with values 'stand-by' vs. 'power-off' Shutdown-Printer on the grounds that
for the Printer object they have no meaning. Power-off is for the
Shutdown-Device operation.
ISSUE 10: Is the current job automatically restarted when the Printer is
restarted? Or does some client have to issue a Restart-Job operation?
ISSUE 11 - 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'.
ISSUE 12 - Ok for Pause-Job to reject a request for a Job that is already
paused (like Cancel-Job), instead of accepting the request?
ISSUE 13 - Ok that the only values for the "when" operation attribute for
the Pause-Current-Job are 'now' and 'after-current-copy' with 'now' being
the default and REQUIRED?
ISSUE 14 - Ok to return an error (like Cancel-Job), rather than having
Resume-Job accept the request even if the Job is already resumed (i.e., not
paused)?