Correct URLs are:
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-991208.docftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-991208.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-991208-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-991208-rev.pdf
**********************************************
* Don Wright don at lexmark.com *
* Director, Strategic & Technical Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
hastings%cp10.es.xerox.com at interlock.lexmark.com on 12/10/99 08:43:19 PM
To: ipp%pwg.org at interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: IPP> OPS - New Set2 spec posted for L.A. meeting
I've updated the Set2 spec from the results of the telecons and email
discussion:
ftp://ftp.pwg.org/pub/pwg/ipp/ipp-ops-set2-991208.docftp://ftp.pwg.org/pub/pwg/ipp/ipp-ops-set2-991208.pdfftp://ftp.pwg.org/pub/pwg/ipp/ipp-ops-set2-991208-rev.docftp://ftp.pwg.org/pub/pwg/ipp/ipp-ops-set2-991208-rev.pdf
Sorry for the short notice. I'll bring paper copies to the meeting. Here
is the change history:
1.1 Changes to the November 16, 1999 version to make the December 8,
1999 version
The following changes to the November 16, 1999 version to make the December
8, 1999 version as a result of the IPP WG telecons and mailing list
discussion:
1. Introduced the separation of Printer operation from Device
operations. Removed the "printer-controls-other-protocols" (boolean)
Printer Description attribute. Printer operations affect only IPP jobs and
objects, while the Device operations affect the output device. Set2 has the
Printer operations and Set3 has the Device operations. But do both sets of
operations with only the Printer object and only the "printer-uri" target.
2. Remove the "when" operation attribute and added distinct Pause
operations instead: Pause-Printer-After-Current-Job (IPP/1.1 Pause-Printer
clarified), Pause-Printer-After-All-Current-Jobs
3. Added Deactivate-Printer and Activate-Printer which do
Disable-Printer, Pause-Printer-After-Current-Job, and only allow query,
Send-Document, Send-URI, and Activate-Printer operations. This is a clearer
"shutdown" that can be brought back up using the protocol.
4. Clarified that Shutdown-Printer cannot be brought back via the
protocol, though added Startup-Printer for hosted implementations to
instantiate a fresh copy of the Printer object.
5. Changed the name of Pause-Current-Job to Suspend-Current-Job, since
other jobs can be processed on the Printer (unlike Pause-Printer).
6. Added the Terminology section
7. Added the Requirements and Use Cases section
8. Added pictures of chained Printers, Printer fan-out, and Printer
fan-in.
9. Added the concept of subordinate Printers and the
"subordinate-printers-supported" (1setOf uri) Printer Description attribute
to describe the configuration.
10. Added the forwarding rules: IPP Printer objects MUST NOT forward
Printer operations to subordinate IPP Printer objects, except for the
chained Printer configuration. IPP Printer objects MUST forward Job
operations to the intended Job object.
11. Removed the "synchronize" operation attribute from all operations.
12. Renamed 'standby' to 'deactivated' Printer state reason.
13. Added 'moving-to-paused-all' Printer state reason for use with
Pause-Printer-After-All-Current-Jobs
14. Added 'printer-deactivated' Printer state reason for use with
Deactivate-Printer.
15. Renamed job-paused' to 'job-suspended' to go with the rename
Suspend-Current-Job operation.
16. Renamed 'server-error-printer-is-in-standby-mode' status code to
'server-error-printer-is-deactivate'.
17. Grouped attributes that come in pairs.
18. Changed Shutdown-Printer so that there is no operation to come back
to life, except Startup-Printer which starts a new instance (but there can
only be one instance per Printer object).
1.2 Changes to the November 1, 1999 version to make the November 16,
1999 version
1. Formally defined IPP Printer fan-out, IPP Printer fan-in, and output
device fan-out. Added figures to show IPP Printer fan-out and IPP Printer
fan-in.
2. Added "parent-printers-supported (1setOf uri) Printer Description
attribute to point back up the Printer hierarchy.
3. Added the requirements for forwarding operations that affect Jobs
and for not forwarding operations that affect Printers.
4. Added "original-requesting-user-name" (name(MAX)) to represent the
original end user, not the parent Printer's host.
5. Changed the default for "when" for the Pause-Printer operation from
'after-current-job' to 'now', since that is the behavior in IPP/1.1 where
the "when" operation attribute is not defined.
6. Allowed a non-leaf Printer to have only one subordinate Printer.
7. Changed most of the "parent" Printer terminology to "non-leaf"
Printer to contrast more clearly with "leaf" Printer objects. The term
"parent" is only used when talking about a subordinate's immediate parent
Printer object.
8. Added "original-requesting-user-name" (name (MAX)) to the list of
READ-ONLY Job Description attributes.
There are 10 issues remaining:
ISSUE 01: Do we want to define whether the response to the client for Job
operations can happen before the non-leaf Printer gets the response from its
subordinate Printer or MUST the non-leaf Printer wait until its gets the
response from its subordinate Printer?
ISSUE 02 - The "requesting-user-name" operation attribute is the parent
Printer's host, not the original requesting user, correct?)
ISSUE 03 - Presumably the "job-originating-user-name" remains as the
authenticated original user, not the parent Printer's authenticated host,
correct?
ISSUE 04 - What new 'moving-to-xxx' and 'xxx' values do we need to support
the new operations defined in this document?
ISSUE 05 - 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 06 - Or should the Printer's "printer-state" attribute be
independent of the Pause Printer operations so that the 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 07: Would a better name for Pause-Printer-After-All-Current-Jobs be
Hold-Future-Jobs? Unfortunately, unlike
Pause-Printer-After-All-Current-Jobs which gets to 'paused', the state
transition would just be to 'idle' when all of the current jobs have
completed? But what operation would undo this condition?
Do-Not-Hold-Future-Jobs, Release-All-Jobs? Or how about having a single
Schedule-Jobs operation that has a parameter that says whether to hold all
future jobs or not?
ISSUE 08: Any better name than 'moving-to-paused-all' Printer state reason
to distinguish Pause-Printer-After-All-Current-Jobs from
Pause-Printer-After-Current-Job which uses 'moving-to-paused'?
ISSUE 09: Or should the Printer's "printer-state" attribute be independent
of the Pause Printer operations so that the 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 10: Should Cancel-Current-Job really be moved to Set3 as a Device
operation, i.e., Cancel-Current-Device-Job or do we need both a Printer and
a Device operation that cancels the current job?