I've posted the Set3 spec (30 pages) as agreed in principle from the Raleigh
IPP WG meeting to create Device operations and separate them from the
Printer and Job operations that are in Set2:
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set3-991208.docftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set3-991208.pdf
I'll bring copies to the L.A. meeting.
Here is the Abstract:
This document specifies 12 additional OPTIONAL operations for use with the
Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1
[ipp-mod, ipp-pro]. These Set3 operations are Device operations that
operators/administrators may perform that directly affect the output device:
Disable-Device Enable-Device
Pause-Device-Now Pause-Device-After-Current-Copy
Pause-Device-After-Current-Job Resume-Device
Deactivate-Device Activate-Device
Purge-Device Reset-Device
Power-Off-Device
This document does not define any new objects and does not define any Job
operations. A companion specified, entitled "Internet Printing
Protocol/1.1: Set2 Operations [ipp-set2] defined Printer operations that
affect the Printer object, rather than the output device. Both the Set2
Printer operations and the Set3 Device operations have the Printer object as
the target, i.e., the client must supply the "printer-uri" operation
attribute and must direct the operation to the network entity that is
implied by that URI.
The scope of IPP, is characterized in RFC2526 "Design Goals for an Internet
Printing Protocol". It is not the intent of this document to revise or
clarify this scope or conjecture as to the degree of industry adoption or
trends related to IPP within printing systems. It is the intent of this
document to extend the original set of operations - in a similar fashion to
the Set1 extensions which referred to IPP/1.0 and were later incorporated
into IPP/1.1.
This document is intended for registration following the registration
procedures of IPP/1.0 [RFC2566] and IPP/1.1 [ipp-mod] and to be published as
an RFC that extends IPP/1.0 and IPP/1.1. The material will also be added to
a new minor revision of IPP if and when such a minor version is published.
There are 11 issues:
ISSUE 01 - Ok that every Device operation REQUIRES the IPP Printer to
perform the corresponding Printer operation, if implemented?
ISSUE 02 - Which corresponding Printer operations MUST an implementation
support, if it supports a particular Device operation?
ISSUE 03 - Ok to REQUIRE roll-up of the "output-devices-supported" Printer
Description attribute.
ISSUE 04 - What additional 'device-moving-to-xxx' are needed as
"printer-state-reasons" values? What target 'device-xxx' delayed states are
needed as "printer-state-reasons" values?
ISSUE 05 - What new status codes are needed, if any?
ISSUE 06 - What new out-of-band values are needed, if any?
ISSUE 07 - Should Pause-Printer-After-Current-Job be a new operation with a
new operation-id code or be a clarification of the existing IPP/1.1
Pause-Printer operation and use its operation-id? Or should the
Pause-Device-Now operation be a new operation-id code or be the
clarification of the existing IPP/1.1 Pause-Printer operation and use its
operation-id? Or should both Pause-Printer-After-Current-Job and
Pause-Device-Now be new operation-id codes and leave the IPP/1.1
Pause-Printer with its current ambiguous (implementer free-for-all)
semantics?
ISSUE 08 - Or should the Printer's "printer-state" attribute be
independent of the Pause Printer operations so that the Pause Device (and
Pause Printer) operations don't set the "printer-state" to 'stopped', i.e.,
the "printer-state" tries to reflect 'idle', 'processing', or 'stopped' of
the output device(s) as best it can independent of whether the IPP Printer
object is paused or not?
ISSUE 09 - Or should we define Purge-Device to cancel any current job rather
than having the behavior undefined on output device?
ISSUE 10 - Or should we define Reset-Device to cancel any current job rather
than having the behavior undefined on current jobs in the output device?
ISSUE 11 - What happens to 'pending' jobs on a Reset-Device for various
values of "reset-function"? If the output device implements persistent
jobs, aren't they saved?
Please send comments to the DL.
Thanks,
Tom