draft-ietf-ipp-ops-set2-00.txt   draft-ietf-ipp-ops-set2-01.txt 
INTERNET-DRAFT Carl Kugler INTERNET-DRAFT Carl Kugler
<draft-ietf-ipp-ops-set2-00.txt> IBM Corporation <draft-ietf-ipp-ops-set2-01.txt> IBM Corporation
T. Hastings T. Hastings
Xerox Corporation Xerox Corporation
H. Lewis H. Lewis
IBM Corporation IBM Corporation
September 19, 1999 July 6, 2000
Internet Printing Protocol (IPP):
Job and Printer Administrative Operations
Internet Printing Protocol/1.1: Set2 Operations Copyright (C) The Internet Society (2000). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working provisions of Section 10 of [rfc2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress". or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 1, line 27 skipping to change at page 1, line 30
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress". or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies 14 additional OPTIONAL operations for use with This document specifies the following 16 additional OPTIONAL operations
the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566]
[ipp-mod, ipp-pro]. These operations are 7 Printer object operations and IPP/1.1 [ipp-mod, ipp-pro]. :
that operators/administrators may perform on a Printer object:
Set-Printer-Attributes
Enable-Printer
Disable-Printer
Reset-Printer
Restart-Printer
Non-Process-Run-Out
Shutdown-Printer
and 7 Job object operations that end-users may perform on their jobs and
operators/administrators may perform on any job, depending on
circumstances:
Set-Job-Attributes
Reprocess-Job
Cancel-Current-Job (though the target is the Printer object)
Expires: March 19, 200
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
Pause-Current-Job (though the target is the Printer object) Printer operations: Job operations:
Resume-Job Enable-Printer and Disable-Printer Reprocess-Job
Promote-Job Pause-Printer-After-Current-Job Cancel-Current-Job
Space-Current-Job (though the target is the Printer object) Hold-New-Jobs and Release-Held- Suspend-Current-Job and Resume-Job
New-Jobs
Deactivate-Printer and Activate- Promote-Job
Printer
Restart-Printer Redirect-Job
Shutdown-Printer and Startup- Schedule-Job-After
Printer
In addition, two operation attributes are defined: "printer-message- New Printer Description attributes: "subordinate-printers-supported",
from-operator" and "job-message-from-operator" are included to set the "parent-printers-supported", and "redirection-printers-supported".
corresponding Printer and Job Description attributes with the same New "printer-state-reasons" values: 'hold-new-jobs' and 'deactivated'.
names. And the "when" operation attribute is added to the IPP/1.1 New "job-state-reasons" attribute values: 'job-suspended'.
Pause-Printer operation. New 'forwarded-operation-failed' event code.
New status code: 'server-error-printer-is-deactivated'.
Finally, new status codes: 'client-error-attributes-not-settable' and Expires: January 6, 2001
'server-error-printer-is-in-standby-mode' are added.
The scope of IPP, is characterized in RFC2526 "Design Goals for an The scope of IPP, is characterized in RFC2526 "Design Goals for an
Internet Printing Protocol". It is not the intent of this document to 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 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 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 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 similar fashion to the Set1 extensions which referred to IPP/1.0 and
were later incorporated into IPP/1.1. 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]. This version
includes the comments discussed at the IPP telecon, on 6/23/1999,
6/30/1999, at the IETF IPP WG meeting, 7/7/99-7/8/99, in Copenhagen, and
the IPP telecon, 7/17/1999, the August, 1999 IPP meeting in Alaska and
subsequent phone conferences and discussions. Specifically, the 9/16
update refers to this set of extensions simply as "Set2" rather than
using the term "Administrative" which was misleading, controversial and
incorrect as an overall description. Also, two new attributes have been
proposed to clarify the intent of each operation in terms of its target,
the Printer vs. the Print Job. Unresolved ISSUES are highlighted like
this in the .doc and .pdf files.
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
The full set of IPP documents includes: The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567] Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568] Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics (this document) Internet Printing Protocol/1.1: Model and Semantics [IPP-MOD]
Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO] Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG] Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [RFC2569] Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that are administrators. It calls out a subset of end user requirements that are
skipping to change at page 4, line 5 skipping to change at page 3, line 5
is intended to help them understand IPP/1.1 and some of the is intended to help them understand IPP/1.1 and some of the
considerations that may assist them in the design of their client and/or considerations that may assist them in the design of their client and/or
IPP object implementations. For example, a typical order of processing IPP object implementations. For example, a typical order of processing
requests is given, including error checking. Motivation for some of the requests is given, including error checking. Motivation for some of the
specification decisions is also included. specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon) to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations. implementations.
Expires: March 19, 2000 Expires: January 6, 2001
Table of Contents
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 1 Introduction.....................................................6
Table of Contents 2 Terminology......................................................6
2.1 Conformance Terminology.......................................6
2.2 Other terminology.............................................6
1. Introduction.....................................................6 3 Requirements and Use Cases.......................................7
3.1 List of the Printer and Device Operations....................11
2. New objects......................................................6 4 Use of the Printer object to represent IPP Printer fan-out and IPP
2.1 Interpreter object............................................6 Printer fan-in.....................................................11
4.1 IPP Printer Fan-Out..........................................12
4.2 IPP Printer Fan-In...........................................12
4.3 Printer object attributes used to represent Printer fan-out and
Printer fan-in....................................................13
4.4 Subordinate Printer URI......................................13
4.5 Printer object attributes used to represent Output Device Fan-Out
.............................................................14
4.6 Figures to show all possible configurations..................15
4.7 Forwarding requests..........................................17
4.7.1 Forwarding requests that affect Printer objects..........17
4.7.2 Forwarding requests that affect Jobs.....................18
3. New Operation attributes.........................................6 5 New Operation attributes........................................20
3.1 New operation attribute: "printer-message-from-operator"
(text(127))6
3.2 New operation attribute: "job-message-from-operator" (text(127))
8
3.3 New operation attribute for Get-Printer-Attributes: "factory-
settings" (boolean)................................................9
3.4 New operation attribute for Pause-Printer: "when" (type2 keyword)
10
3.5 New OPTIONAL operation attribute for any Job or Printer operation:
"device-name" (name(127)).........................................11
3.5.1 Revised text for [ipp-mod] for the "device-name" extension12
3.6 Summary of the operation attributes for the Printer operations13
3.7 Summary of the operation attributes for the Job operations...13
4. New Printer Description Attributes..............................15 6 New Printer Description Attributes..............................21
4.1 printer-settable-attributes (1setOf type2 keyword)...........15 6.1 subordinate-printers-supported (1setOf uri)..................22
4.2 interpreter-settable-attributes (1setOf type2 keyword).......15 6.2 parent-printers-supported (1setOf uri).......................22
4.3 job-settable-attributes (1setOf type2 keyword)...............16 6.3 redirection-printers-supported (1setOf uri)..................22
4.4 printer-controls-other-protocols (boolean)...................16
4.5 printer-message-time (integer(MIN:MAX))......................18
4.6 printer-message-date-time (dateTime).........................19
4.7 printer-message-operation (type2 keyword)....................19
4.8 when-values-supported (1setOf type2 keyword).................20
4.9 device-names-supported (1setOf name(127))....................21
5. Additional values for "printer-state-reasons" and "job-state-reasons" 7 Additional Values for "printer-state-reasons"...................22
attributes.........................................................21 7.1 'hold-new-jobs'..............................................23
5.1 Value for "printer-state-reasons": 'standby'................21 7.2 'deactivated'................................................23
5.2 Value for "job-state-reasons": 'job-paused'.................22
6. New status codes................................................22 8 Additional Values for "job-state-reasons".......................23
6.1 New status code: 'client-error-attributes-not-settable'......22 8.1 'job-suspended'..............................................23
6.2 New status code: 'server-error-printer-is-in-standby-mode'...23
7. Summary of Set 2 operations and Operation-Id Assignments........23 9 Additional events...............................................23
7.1 Printer Operations...........................................24
7.1.1 Set-Printer-Attributes Operation.........................24
7.1.2 Disable-Printer Operation................................29
7.1.3 Enable-Printer Operation.................................30
7.1.4 Reset-Printer operation..................................31
7.1.5 Restart-Printer operation................................32
7.1.6 Non-Process-Run-Out Operation............................33
Expires: March 19, 2000 10 Additional status codes........................................23
10.1'server-error-printer-is-deactivated' (0x????)...............24
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 11 Definition of the Printer Operations...........................24
11.1The Disable and Enable Printer Operations....................26
11.1.1 Disable-Printer Operation................................26
11.1.2 Enable-Printer Operation.................................27
11.2The Pause and Resume Printer Operations......................27
11.2.1 Pause-Printer-After-Current-Job operation................28
11.3Hold and Release New Jobs operations.........................30
11.3.1 Hold-New-Jobs operation..................................30
11.3.2 Release-Held-New-Jobs operation..........................30
7.1.7 Shutdown-Printer Operation...............................34 Expires: January 6, 2001
7.2 Job Operations...............................................36 11.4Deactivate and Activate Printer Operations...................31
7.2.1 Set-Job-Attributes.......................................36 11.4.1 Deactivate-Printer operation.............................31
7.2.2 Reprocess-Job Operation..................................40 11.4.2 Activate-Printer operation...............................32
7.2.3 Cancel-Current-Job Operation.............................40 11.5Restart-Printer, Shutdown-Printer, and Startup-Printer operations
7.2.4 Pause-Current-Job operation..............................41 .............................................................32
7.2.5 Resume-Job operation.....................................43 11.5.1 Restart-Printer operation................................33
7.2.6 Promote-Job operation....................................43 11.5.2 Shutdown-Printer Operation...............................34
7.2.7 Space-Current-Job operation..............................44 11.5.3 Startup-Printer operation................................34
8. IANA Considerations.............................................45 12 Definition of the Job Operations...............................36
12.1Reprocess-Job Operation......................................37
12.2Cancel-Current-Job Operation.................................38
12.3Suspend and Resume Job operations............................39
12.3.1 Suspend-Current-Job operation............................39
12.3.2 Resume-Job operation.....................................40
12.4Promote-Job operation........................................41
12.5Redirect-Job operation.......................................41
12.6Schedule-Job-After operation.................................43
9. Internationalization Considerations.............................45 13 Conformance Requirements.......................................45
10.Security Considerations........................................46 14 IANA Considerations............................................46
11.Author's Addresses.............................................46 15 Internationalization Considerations............................46
12.References.....................................................46 16 Security Considerations........................................46
13.Change History.................................................47 17 Author's Addresses.............................................46
13.1Changes to the July 19, 1999 version to make the September 19,
1999 version......................................................47
13.2Changes to the June 30, 1999 version to make the July 19, 1999
version 47
14.Appendix A: Full Copyright Statement...........................49 18 References.....................................................47
Expires: March 19, 2000 19 Appendix A: Full Copyright Statement...........................48
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 List of Tables
Table 1 - List of Printer Operations and corresponding Device Operations
.................................................................11
Table 2 - Forwarding operations that affect Printer objects..........17
Table 3 - Forwarding operations that affect Jobs objects.............18
Table 4 - Operation attribute support for Printer Operations..........20
Table 5 - Operation attribute support for Job operations.............21
Table 6 - Printer Operation Operation-Id assignments.................24
Table 7 - Pause and Resume Printer and Device Operations.............28
Table 8 - Job operation Operation-Id assignments.....................36
Table 9 - Conformance Requirement Dependencies for Operations........45
Table 10- Conformance Requirement Dependencies for "printer-state-
reasons" Values..................................................45
Table 11- Conformance Requirement Dependencies for "job-state-reasons"
Values...........................................................46
1. Introduction List of Figures
Figure 1 - Embedded Printer object...................................15
Figure 2 - Hosted Printer object.....................................15
Figure 3 - Output Device fan out.....................................15
Expires: January 6, 2001
Figure 4 - Chained IPP Printer.......................................16
Figure 5 - IPP Printer fan out.......................................16
Figure 6 - IPP Printer fan in........................................16
Expires: January 6, 2001
1 Introduction
The Internet Printing Protocol (IPP) is an application level protocol The Internet Printing Protocol (IPP) is an application level protocol
that can be used for distributed printing using Internet tools and that can be used for distributed printing using Internet tools and
technologies. IPP version 1.1 (IPP/1.1) focuses only on end user technologies. IPP version 1.1 ([ipp-mod, ipp-pro]) focuses on end user
functionality with a few administrative operations included. This functionality with a few administrative operations included. This
document defines additional OPTIONAL end user, operation, and document defines additional OPTIONAL end user, operator, and
administrator operations used to control Jobs and Printers. This administrator operations used to control Jobs and Printers. This
document is a registration proposal for an extension to IPP/1.0 and document is a registration proposal for an extension to IPP/1.0 and
IPP/1.1 following the registration procedures in those documents. IPP/1.1 following the registration procedures in those documents.
2. New objects 2 Terminology
This section defines the new Interpreter object.
2.1 Interpreter object
The Interpreter object models the document format interpreters that are
contained in the Printer object. Depending on implementation, the
Printer object attributes whose values depend on the interpreter, i.e.,
on the "document-format" of the document being processed, are considered
to be Interpreter object attributes instead. A Get-Printer-Attributes
operations returns Printer and Interpreter objects as specified in the
"requested-attributes" supplied by the client. Depending on the value
of the "document-format" attribute supplied by the client in the Get-
Printer-Attributes request (or the "document-format-default", if the
client omits the "document-format" attribute), selects the corresponding
Interpreter object.
Note: the addition of the Interpreter object is completely compatible
with IPP/1.0 and IPP/1.1 (see the description of the "document-format"
operation attribute in [ipp-mod] section 3.2.5.1 Get-Printer-Attributes
request). The protocol and semantics are the same whether or not the
Interpreter object is used to distinguish attributes that depend on the
"document-format".
3. New Operation attributes This section defines terminology used throughout this document.
This section defines the new "printer-message-from-operation" and "job- 2.1 Conformance Terminology
message-from-operator" operation attributes that set the corresponding
Printer and Job Description attributes.
3.1 New operation attribute: "printer-message-from-operator" Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
(text(127)) MAY, NEED NOT, and OPTIONAL, have special meaning relating to
conformance. These terms are defined in [ipp-mod] section 12.1 on
conformance terminology, most of which is taken from RFC 2119 [RFC2119].
Type of registration: attribute The following specialization of these terms apply to this document:
Expires: March 19, 2000 REQUIRED: if an implementation supports the extensions described in
this document, it MUST support a REQUIRED feature.
OPTIONAL: if an implementation supports the extensions described in
this document, it MAY support an OPTIONAL feature.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 2.2 Other terminology
Proposed keyword name of this attribute: "printer-message-from- This document uses terms such as "attributes", "keywords", and
operator" "support". These terms have special meaning and are defined in the
Types of attribute (Operation, Job Template, Job Description, Printer model terminology [ipp-mod] section 12.2. In addition, the following
Description): Operation capitalized terms are defined.
Operations to be used with if the attribute is an operation attribute:
See below
Object (Job, Printer, etc. if bound to an object): Printer (already in
IPP/1.0 and IPP/1.1)
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
text(127)
Specification of this attribute (follow the style of IPP Model Section IPP Printer object (or Printer for short) - a software abstraction
4.2): defined by [ipp-mod].
"printer-message-from-operator" (text(127)) Printer Operation - an operation whose target is an IPP Printer
The client OPTIONALLY supplies this attribute. The Printer object object and whose effect is on the Printer object.
SHOULD supports this operation attribute if it supports the
corresponding Printer Description attribute. The value of this
attribute is a message from the operator about the Printer object
on which the operator is performing the operation. If supported,
the Printer copies the value to the Printer's "printer-message-
from-operator" Printer Description attribute (see [ipp-mod] section
4.4.25), automatically sets the value of the Printer's "printer-
message-time" with the current value of the Printer's "printer-up-
time" attribute, the value of the "printer-message-date-time" with
the current value of the Printer's printer-current-date-time"
attribute, and the value of the Printer's "printer-message-
operation" with the operation-id value of this operation (see [ipp-
mod] section 4.4.15).
If the client omits this attribute, the Printer does not change the Output Device - the physical imaging mechanism that an IPP Printer
value of its "printer-message-from-operator", "printer-message- controls. Note: while this term is capitalized in this
time", "printer-message-date-time", and "printer-message-operation" specification (but not in [ipp-mod]), there is no formal object
Printer Description attributes. called an Output Device.
If the client supplies this attribute with a zero-length text value Device Operation - an operation whose target is an IPP Printer object
or with a value consisting solely of white space, the Printer and whose defined effect is on an Output Device.
copies that value as any other value to the Printer's "printer-
message-from-operator" and sets the "printer-message-time",
"printer-message-date-time", and "printer-message-operation"
attributes. Supplying such a value is the way that the operator
indicates that there is no longer a printer message from the
operator (rather than using the "out-of-band" 'no-value' value).
This operation attribute is defined for use with the following operator Output Device Fan-Out - a configuration in which an IPP Printer
operations on the Printer object: controls more that one output-device.
Pause-Printer - see [ipp-mod] section 3.2.7 Printer fan-out - a configuration in which an IPP Printer object
Resume-Printer - see [ipp-mod] section 3.2.8 controls more than one Subordinate IPP Printer object.
Purge-Jobs - see [ipp-mod] section 3.2.9
Disable-Printer - see section 7.1.2
Expires: March 19, 2000 Expires: January 6, 2001
Printer fan-in - a configuration in which an IPP Printer object is
controlled by more than one IPP Printer object.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Subordinate Printer - an IPP Printer object that is controlled by
another IPP Printer object. Such a Subordinate Printer MAY have
one or more Subordinate Printers.
Enable-Printer - see section 7.1.3 Leaf Printer - a Subordinate Printer that has no Subordinate
Reset-Printer - see section 7.1.4 Printers.
Restart-Printer - see section 7.1.5
Non-Process-Run-Out - see section 7.1.6
Shutdown-Printer - see section 7.1.7
The "printer-message-from-operator" operation attribute MUST NOT be Non-Leaf Printer - an IPP Printer object that has one or more
supported as an operation attribute for the Set-Printer-Attributes Subordinate Printers.
operation. If the operator wants to set the Printer's "printer-message-
from-operator" Printer Description attribute when issuing the Set-
Printer-Attributes operation, the client supplies the "printer-message-
from-operator" with its new value as one of the Printer Description
attributes in Group 2 in the request. The Printer also updates the
Printer's "printer-message-date-time" and "printer-message-operation"
Printer Description attributes. If the client does not explicitly
supply the "printer-message-from-operator" with its new value, the
Printer leaves the value of the Printer's "printer-message-from-
operator" Printer Description attribute unchanged.
3.2 New operation attribute: "job-message-from-operator" (text(127)) Chained Printer - a Non-Leaf Printer that has exactly one Subordinate
Printer.
Type of registration: attribute Job Creation operations - IPP operations that create a Job object:
Proposed keyword name of this attribute: "job-message-from-operator" Print-Job, Print-URI, and Create-Job.
Types of attribute (Operation, Job Template, Job Description, Printer
Description): Operation
Operations to be used with if the attribute is an operation attribute:
See below
Object (Job, Printer, etc. if bound to an object): Job (already in
IPP/1.0 and IPP/1.1)
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
text(127)
Specification of this attribute (follow the style of IPP Model Section 3 Requirements and Use Cases
4.2):
"job-message-from-operator" (text(127)) The following requirements and usage cover both the "Job and Printer
The client OPTIONALLY supplies this attribute. The Printer object Administrative Operations" (this document)and the "Device Administrative
SHOULD supports this operation attribute if it supports the Operations" (see [ipp-device-ops]). The requirements are presented here
corresponding Job Description attribute. The value of this together to show the parallelism.
attribute is a message from the operator about the Job object on
which the operator has just performed an operation. If supported,
the Printer copies the value to the Job's "job-message-from-
operator" Job Description attribute (see [ipp-mod] section 4.3.16).
If the client omits this attribute, the Printer does not change the 1.Have separate operations for affecting the IPP Printer versus
value of its "printer-message-from-operator" Job Description affecting the Output Device, so its clear what the intent of each is
attribute. and implementers can implement one or the other or both.
If the client supplies this attribute with a zero-length text value 2.Support fan-out of Printer objects.
or with a value consisting solely of white space, the Printer
Expires: March 19, 2000 3.Support fan-out of Output Devices.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 4.Support fan-in of Printer objects, as long as it doesn't make the
semantics more complicated when not supporting fan-in.
copies that value as any other value to the job's "job-message- 5.Support fan-in of output objects, as long as it doesn't make the
from-operator". Supplying such a value is the way that the semantics more complicated when not supporting fan-in.
operator indicates that there is no longer a job message from the
operator (rather than using the "out-of-band" 'no-value' value).
Note: There are no corresponding 'job-message-time", "job-message- 6.Instead of having operation attributes that alter the behavior of the
date-time", and "job-message-operation" Job Description attributes, operation significantly, have separate operations, so that it is
since the usual lifetime of a job is limited. simple and clear to a client which semantics the Printer is
supporting (by querying the "operations-supported" attribute) and it
is simple to describe the capabilities of a Printer implementation in
written documentation (just list the OPTIONAL operations supported).
This operation attribute is defined for use with the following operator 7.Need a Printer Operation to prevent a Printer object from accepting
operations on the Job object: 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.
Cancel-Job - see [ipp-mod] section 3.2.4 Usage: Operator is preparing to take the IPP Printer out of service
Hold-Job - see [ipp-mod] section 3.3.5 or to change the configuration of the IPP Printer.
Release-Job - see [ipp-mod] section 3.3.6
Restart-Job - see [ipp-mod] section 3.3.7
Reprocess-Job - see section 7.2.2
Cancel-Current-Job - see section 7.2.3
Pause-Current-Job - see section 7.2.4
Resume-Job - see section 7.2.5
Promote-Job - see section 7.2.6
Space-Current-Job - see section 7.2.7
The "job-message-from-operator" operation attribute MUST NOT be Suggested name and operations: Disable-Printer and Enable-Printer
supported as an operation attribute for the Set-Job-Attributes
operation. If the operator wants to set the Job's "job-message-from-
operator" Job Description attribute when issuing the Set-Job-Attributes
operation, the client supplies the "job-message-from-operator" with its
new value as one of the Job Description attributes in Group 2 in the
request. Otherwise, the Printer leaves the value of the Job's "job-
message-from-operator" Job Description attribute unchanged by not
explicitly setting the attribute.
3.3 New operation attribute for Get-Printer-Attributes: "factory- Expires: January 6, 2001
settings" (boolean)
Type of registration: attribute 8.Need a Device Operation to prevent an Output Device from accepting
Proposed keyword name of this attribute: "factory-settings" any new jobs from any job submission protocol and a companion one to
Types of attribute (Operation, Job Template, Job Description, Printer restore the Output Device to accepting any jobs.
Description): Operation
Operations to be used with if the attribute is an operation attribute:
Get-Printer-Attributes
Object (Job, Printer, etc. if bound to an object): N/A
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
boolean
Specification of this attribute (follow the style of IPP Model Section Usage: Operator is preparing to take the Output Device out of
4.2): service.
Expires: March 19, 2000 Suggested name and operations: Disable-Device and Enable Device
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 9.Need a Printer Operation to stop the processing after the current IPP
job completes and not start processing any additional IPP jobs
(either by scheduling the jobs or sending them to the Output Device),
but continue to accept new IPP jobs. Need a companion operation to
start processing/sending IPP jobs again.
"factory-settings" (boolean) Usage: Operator wants to gracefully stop the IPP Printer at the next
The client OPTIONALLY supplies this attribute. The Printer object job boundary. The Pause-Printer-After-Current-Job operation is also
OPTIONALLY supports this attribute, if it supports the Set-Printer- invoked implicitly by the Deactivate-Printer and the Shutdown-Printer
Attributes operation. If the client omits this attribute or Operations.
supplies the 'false' value, the Printer returns the current values
of the requested attributes that are settable, i.e., the values
that have been set by previous Set-Printer-Attributes. If the
client supplies the 'true' value, the Printer returns the factory
settings, i.e., the inherent values supported by the implementation
as shipped from the manufacturer or established at install time.
This operation attribute allows an operator to determine which
values are supported in an implementation after having modified a
settable attribute. Attributes that are not settable are not
affected by this operation attribute, so that the Printer returns
the same values for non-settable attribute when either the 'true'
or 'false' value has been supplied. If this operation attribute is
supported, both values MUST be supported.
3.4 New operation attribute for Pause-Printer: "when" (type2 keyword) Suggested name and operations: Pause-Printer-After-Current-Job,
(IPP/1.1) Resume-Printer
Type of registration: attribute 10. Need a Device Operation to stop the processing the current job
Proposed keyword name of this attribute: "when" "immediately", no matter what protocol. Its like the Pause button on
Types of attribute (Operation, Job Template, Job Description, Printer the Output Device. This operation is for emergencies. The stop
Description): Operation point depends on implementation, but can be mid page, end of page,
Operations to be used with if the attribute is an operation attribute: end of sheet, or after a few sheets for Output Devices that can't
Pause-Printer, Reset-Printer, Non-Process-Run-Out, Shutdown-Printer, and stop that quickly. The paper path isn't run out. Need a companion
Pause-Current-Job operation to start processing the current any-protocol job without
Object (Job, Printer, etc. if bound to an object): N/A losing any thing.
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
type2 keyword
Specification of this attribute (follow the style of IPP Model Section Usage: Operator sees something bad about to happen, such as the
4.2): paper is about to jam, or the toner is running out, or the device is
"when" (type2 keyword) overheating or wants to add more paper.
The client OPTIONALLY supplies this attribute. The Printer object
OPTIONALLY supports this attribute, if it supports this operation.
The value of this attribute indicates when to pause, reset, or
shutdown the printer. If the client omits this attribute, the
Printer assumes the 'after-current-job' value. The 'after-current-
job' value is REQUIRED to be supported if the "when" attribute is
supported; the remaining values are OPTIONAL.
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 Suggested name and operations: Pause-Device-Now, Resume-Device
Expires: March 19, 2000 11. Need a Printer Operation to stop the processing of IPP jobs after
all of the currently accepted jobs have been processed, but any newly
accepted jobs go into the 'processing-held' state.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 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 another
operation after reconfiguring. He repeats the two operations to
restore the Output Device to its normal media.
"when" supported. The client may specify a value of when and the Suggested name and operations: Hold-New-Jobs, Release-Held-New-Jobs
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.
Standard keyword values are: 12. Need a Device Operation to stop the processing the current any-
'now' - cancel the currently printing job(s) and shutdown the protocol job at a convenient point, such as after the current copy
Printer. Jobs in the 'held' and 'pending' state remain (or end of job if last or only copy). Need a companion operation to
in those states.
'after-current-copy' - shutdown the Printer after the current
job finishes printing its current copy. Jobs in the
'held' and 'pending' state remain in those states.
'after-current-job' - shutdown the Printer after the current
job finishes printing (all its copies). Jobs in the
'held' and 'pending' state remain in those states.
'after-all' - shutdown the Printer after all 'pending' jobs
finish printing. Jobs in the 'held' state remain in the
'held' state.
3.5 New OPTIONAL operation attribute for any Job or Printer operation: Expires: January 6, 2001
"device-name" (name(127)) start processing the current any-protocol job or next job without
losing any thing.
Type of registration: attribute Usage: The operator wants to empty the output bin that is near full.
Proposed keyword name of this attribute: "device-name" The paper path is run out.
Types of attribute (Operation, Job Template, Job Description, Printer
Description): Operation
Operations to be used with if the attribute is an operation attribute:
all
Object (Job, Printer, etc. if bound to an object): N/A
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
name(127)
Specification of this attribute (follow the style of IPP Model Section Suggested name and operations: Pause-Device-After-Current-Copy,
4.2): Resume-Device
"device-name" (name(127))
This OPTIONAL Printer operation attribute contains the name of a
device which is associated with this Printer object. The named
device is the actual target of the specified Printer operation,
that is, the Printer object MUST pass the operation through to the
device rather than affecting the Printer object specified by the
"printer-uri" operation attribute. See the Job object attribute
"output-device-assigned" in [IPP-MOD] which identifies the named
device that the job was assigned to by the Printer object. See the
Printer object attribute "device-names-supported" in section 4.9 of
this document.
ISSUE 2 - Shouldn't the Printer object also be affected? In other 13. Need a Device Operation that always pauses on a device-defined
words, if the "device-name" is supplied with the Pause-Printer 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.
Expires: March 19, 2000 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.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Suggested name and operations: Pause-Device-After-Current-Job,
Resume-Device
operation to pause the actual device, shouldn't the Printer object 14. Need a Printer Operation that combines Disable-Printer, Pause-
also enter the 'stopped' state with the 'paused' "printer-state- Printer-After-Current-Job, and rejects all other Job, Printer, and
reasons" value set? 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.
ISSUE 3 - An implementation is free to support the "device-name" Usage: The administrator wants to reconfigure the Printer object
operation attribute on any operation, but NEED NOT support it on using the Set-Printer-Attributes operation without disturbing the
all operations, if it supports it on some, correct? 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.
ISSUE 4 - Could we specify a minimum set of operations which, if Suggested name and operation: Deactivate-Printer, Activate-Printer
supported, MUST also support the "device-name" operation attribute,
if the implementation supports the "device-name" operation
attribute on any operation?
3.5.1 Revised text for [ipp-mod] for the "device-name" extension 15. Need a Device Operation that combines Disable-Device, Pause-Device-
After-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.
The "device-name" extension recommends that the following text be added Usage: The field service person wants to open up the device without
to the IPP-MOD document in section 3.2, "Printer Operations": disturbing the current in process work, perhaps to replace staples,
or replace the toner cartridge.
All Printer operations are directed at Printer objects OR at named Suggested name and operation: Deactivate-Device, Activate-Device
devices associated with Printer objects. A client MUST always
supply the "printer-uri" operation attribute in order to identify
the correct target of the operation. A client MAY also supply the
"device-name" operation attribute in order to pass the operation to
the named device (rather than affecting the Printer object
specified by "printer-uri")."
ISSUE 5 (repeat of 2) - Shouldn't the Printer object also be 16. Need a Printer Operation to recover from the IPP Printer software
affected? In other words, if the "device-name" is supplied with that has gotten confused (run out of heap memory or gotten into a
the Pause-Printer operation to pause the actual device, shouldn't state that it doesn't seem to be able to get out of). This is a
the Printer object also enter the 'stopped' state with the 'paused' condition that shouldn't happen, but does in real life. Any volatile
"printer-state-reasons" value set? information is saved if possible before the software is re-
Expires: March 19, 2000 Expires: January 6, 2001
initialized. No companion operation is needed to undo this. We
don't want to go back to the "confused" state :-).
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Usage: The IPP Printer software has gotten confused or isn't
responding properly.
3.6 Summary of the operation attributes for the Printer operations Suggested name and operation: Restart-Printer
The following table shows the operation attributes for the Printer 17. Need a Device Operation to recover from the Output Device hardware
operations that a client MAY supply in a request. Operation parameters and software that has gotten confused (gotten into a state that it
and attributes that a client MUST supply are not shown. Also doesn't seem to be able to get out of, run out of heap memory, etc.).
"requesting-user-name" is not shown, though it is RECOMMENDED that a This is a condition that shouldn't happen, but does in real life.
client supply it in every request. This is the same and has the same options as the Printer MIB reset.
Legend: No companion operation is needed to undo this. We don't want to go
R - REQUIRED for a Printer to support back to the "confused" state :-).
O - OPTIONAL for a Printer to support; the Printer ignores the
attribute if not supported
Operation Pau Resu Pur Get- Set- Enab Disa Res Rest Non Shu Usage: The Output Device has gotten confused or need resetting to
Attribute se- me- ge- Print Print le- ble- et- art- - t some initial conditions.
Pri Prin Job er- er- Prin Prin Pri Prin Pro dow
nte ter s Attri Attri t ter nte ter ces n-
r butes butes r s- Pri
Run nte
- r
Out
document- R R Suggested name and operation: Reset-Device
format
factory- O 18. Need a Printer Operation to put the IPP Printer object out of
settings business with no way in the protocol to bring that instantiation back
to life (but see Startup-Printer which brings up exactly one new
instantiation to life with the same URL). Any volatile information
is saved if possible.
printer- O O O O O O O O Usage: The Printer is being moved or the building's power is being
message- shut off.
from-
operator
job-type O O Suggested name and operation: Shutdown-Printer
when O O O 19. Need a Printer Operation to bring an IPP Printer to life when there
is an already running host.
reset- R Usage: After the host is started (by means outside the IPP
function 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.
synchronize O Suggested name and operation: Startup-Printer
shutdown- R 20. Need a Device Operation to power off the Output Device after
function 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.
device-name O O O O O O O O O O O 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.
3.7 Summary of the operation attributes for the Job operations Suggested name and operation: Power-Off-Device
The following table shows the operation attributes for the Job Expires: January 6, 2001
operations that a client MAY supply in a request. Operation attributes
that specify the Printer or Job object as the target are shown in the
first two rows, respectively. Other operation attributes and parameters
Expires: March 19, 2000 21. Need a Device Operation to startup a powered-off device.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Usage: After a Power-Off-Device, if the device can be powered back
up (possibly by an intervening host that supports the Device
Operation).
that a client MUST supply are not shown. Also "requesting-user-name" is Suggest name and operation: Power-On-Device
not shown, though it is RECOMMENDED that a client supply it in every
request.
Legend:
R - REQUIRED for a Printer to support
O - OPTIONAL for a Printer to support; the Printer ignores the
attribute if not supported
Operation Can Canc Ho Re Spa Pau Re Get- Set- Rest Repr Pro 3.1 List of the Printer and Device Operations
Attribute cel el- ld le ce- se- su Job- Job- art- oces mot
- Curr - as Cur Cur me Attr Attr Job s- e-
Job ent- Jo e- ren ren - ibut ibut Job Job
Job b Jo t- t- Jo es es
b Job Job b
printer-uri R R R The list of Printer and the corresponding Device Operations is shown in
Table 1:
printer- R R R R R R R R R Table 1 - List of Printer Operations and corresponding Device Operations
uri/job-id
or job-uri
job-id R R R Printer Operation Corresponding Device Operation
equivalent
(see [ipp-device-ops])
requested- R Disable-Printer Disable-Device
attributes
back-space O Enable-Printer Enable-Device
forward- O Pause-Printer (IPP/1.1 - Pause-Device-Now
space [ipp-mod] - one
interpretation)
synchronize O O no Pause-Device-After-Current-Copy
when O O Pause-Printer-After-Current- Pause-Device-After-Current-Job
Job
job- O O O O O O O O O Resume-Printer (IPP/1.1 - Resume-Device
message- [ipp-mod])
from-
operator
message O O O O O O O O Hold-New-Jobs no
[to-
operator]
job-hold- O* O* O** Release-Held-New-Jobs no
until
device-name O O O O O O O O O O O O Deactivate-Printer Deactivate-Device
* The Printer MUST support the "job-hold-until" operation attribute Activate-Printer Activate-Device
if it supports the "job-hold-until" Job Template attribute.
** The Printer MUST support the "job-hold-until" operation attribute if
it supports the Set-Job-Attributes operation, so that the client can
hold the job with the Reprocess-Job operation and the modify the job
before releasing it to be processed.
Expires: March 19, 2000 Purge-Jobs (IPP/1.1 - [ipp- Purge-Device
mod])
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Restart-Printer Reset-Device
4. New Printer Description Attributes Shutdown-Printer Power-Off-Device
The following new Printer Description attributes are needed to support Startup-Printer Power-On-Device
the new operations defined in this document.
4.1 printer-settable-attributes (1setOf type2 keyword) There are no conformance dependencies between Printer Operations and
Device Operations. Either MAY be supported without supporting the
corresponding operations.
Type of registration: attribute 4 Use of the Printer object to represent IPP Printer fan-out and IPP
Proposed keyword name of this attribute: printer-settable-attributes Printer fan-in
Types of attribute (Operation, Job Template, Job Description, Printer
Description): Printer Description
Operations to be used with if the attribute is an operation attribute:
N/A
Object (Job, Printer, etc. if bound to an object): Printer
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
1setOf type2 keyword
If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2): Yes
If this is a Job Template attribute, how does its specification depend
on the value of the "multiple-document-handling" attribute: N/A
Specification of this attribute (follow the style of IPP Model Section
4.2):
4.4.? printer-settable-attributes (1setOf type2 keyword) This section defines how the Printer object MAY be used to represent IPP
Printer fan-out and IPP Printer fan-in. Fan-out is where an IPP Printer
This READ-ONLY Printer attribute identifies the Printer object Expires: January 6, 2001
attributes that are settable in this implementation, i.e., that are
settable using the Set-Printer-Attributes operations. This attribute
MUST be supported if the Set-Printer-Attributes operations is supported.
The Printer MUST reject attempts to set any Printer attributes that are
not in this list, returning the 'client-error-attributes-not-settable'
status code (see section 6.1). The value of this attribute MAY depend
on the value of the "document-format" operation attribute supplied in
the Get-Printer-Attributes operation (see [ipp-mod] section 3.2.5.1).
4.2 interpreter-settable-attributes (1setOf type2 keyword) is used to represent other IPP Printer objects. Fan-in is where several
IPP Printer objects are used to represent another IPP Printer object.
Type of registration: attribute 4.1 IPP Printer Fan-Out
Proposed keyword name of this attribute: interpreter-settable-
attributes
Types of attribute (Operation, Job Template, Job Description, Printer
Description): Printer Description
Operations to be used with if the attribute is an operation attribute:
N/A
Object (Job, Printer, etc. if bound to an object): Printer
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
1setOf type2 keyword
If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2): Yes
Expires: March 19, 2000 The IPP/1.1 Model and Semantics introduces the semantic concept of an
IPP Printer object that represents more than one Output Device (see
[ipp-mod] section 2.1). This concept is called "Output Device Fan-Out".
However, there was no way to represent the individual states of the
Output Devices or to perform operations on a specific Output Device when
there was fan-out. This document generalizes the semantics of the
Printer object to represent such Subordinate fan-out Output Devices as
IPP Printer objects. This concept is called "Printer object fan-out".
A Printer object that has a Subordinate Printer object is called a Non-
Leaf Printer object. Thus a Non-Leaf Printer object supports one or
more Subordinate Printer objects in order to represent Printer object
fan-out. A Printer object that does not have any Subordinate Printer
objects is called a Leaf Printer object.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Each Non-Leaf Printer object submits jobs to its immediate Subordinate
Printers and otherwise controls the Subordinate Printers using IPP or
other protocols. Whether pending jobs are kept in the Non-Leaf Printer
until a Subordinate Printer can accept them or are kept in the
Subordinate Printers depends on implementation and/or configuration
policy. Furthermore, a Subordinate Printer object MAY, in turn, have
Subordinate Printer objects. Thus a Printer object can be both a Non-
Leaf Printer and a Subordinate Printer.
If this is a Job Template attribute, how does its specification depend A Subordinate Printer object MUST be a conforming Printer object, so it
on the value of the "multiple-document-handling" attribute: N/A MUST support all of the REQUIRED operations and attributes. However,
Specification of this attribute (follow the style of IPP Model Section with access control, the Subordinate Printer MAY be configured so that
4.2): end-user clients are not permitted to perform any operations (or just
Get-Printer-Attributes) while one or more Non-Leaf Printer object(s) are
permitted to perform any operation.
4.4.? interpreter-settable-attributes (1setOf type2 keyword) 4.2 IPP Printer Fan-In
This READ-ONLY Printer attribute identifies the Interpreter object (see The IPP/1.1 Model and Semantics did not preclude the semantic concept of
section 2.1) attributes that are settable in this implementation, i.e., multiple IPP Printer objects that represent a single Output Device (see
that are settable using the Set-Printer-Attributes operations. This [ipp-mod] section 2.1). However, there was no way for the client to
attribute MUST be supported if the Set-Printer-Attributes operations is determine that there was a fan-in configuration, nor was there a way to
supported. The Printer MUST reject attempts to set any Printer or perform operations on the Subordinate device. This specification
Interpreter attributes that are not in this list, returning the 'client- generalizes the semantics of the Printer object to allow several Non-
error-attributes-not-settable' status code (see section 6.1). The value Leaf IPP Printer objects to represent a single Subordinate Printer
of this attribute MAY depend on the value of the "document-format" object. Thus a Non-Leaf Printer object MAY share a Subordinate Printer
operation attribute supplied in the Get-Printer-Attributes operation object with one or more other Non-Leaf Printer objects in order to
(see [ipp-mod] section 3.2.5.1). represent IPP Printer fan-in.
4.3 job-settable-attributes (1setOf type2 keyword) As with fan-out (see section 4.1), when a Printer object is a Non-Leaf
Printer, it MUST NOT have an associated Output Device. As with fan-out,
a Leaf Printer object has one or more associated Output Devices. As
with fan-out, the Non-Leaf Printer objects submit jobs to their
Type of registration: attribute Expires: January 6, 2001
Proposed keyword name of this attribute: job-settable-attributes
Types of attribute (Operation, Job Template, Job Description, Printer
Description): Printer Description
Operations to be used with if the attribute is an operation attribute:
N/A
Object (Job, Printer, etc. if bound to an object): Printer
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
1setOf type2 keyword
If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2): Yes
If this is a Job Template attribute, how does its specification depend
on the value of the "multiple-document-handling" attribute: N/A
Specification of this attribute (follow the style of IPP Model Section
4.2):
4.4.? job-settable-attributes (1setOf type2 keyword) Subordinate Printer objects and otherwise control the Subordinate
Printer. As with fan-out, whether pending jobs are kept in the Non-Leaf
Printers until the Subordinate Printer can accept them or are kept in
the Subordinate Printer depends on implementation and/or configuration
policy.
This READ-ONLY Printer attribute identifies the Job object attributes 4.3 Printer object attributes used to represent Printer fan-out and
that are settable in this implementation, i.e., that are settable using Printer fan-in
the Set-Job-Attributes operations. This attribute MUST be supported if
the Set-Job-Attributes operations is supported. The Printer MUST reject
attempts to set any Job attributes that are not in this list, returning
the 'client-error-attributes-not-settable' status code (see section
6.1).
4.4 printer-controls-other-protocols (boolean) The following Printer Description attributes are defined to represent
the relationship between Printer object(s) and their Subordinate Printer
object(s):
Type of registration: attribute 1."subordinate-printers-supported" (1setOf uri) - contains the URI of
Proposed keyword name of this attribute: printer-controls-other- the immediate Subordinate Printer object(s).
protocols
Expires: March 19, 2000 2."parent-printers-supported (1setOf uri) - contains the URI of the
Non-Leaf printer object(s) for which this Printer object is the
immediate Subordinate, i.e., this Printer's immediate "parent" or
"parents".
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 4.4 Subordinate Printer URI
Types of attribute (Operation, Job Template, Job Description, Printer Each Subordinate Printer object has a URI which is used as the target of
Description): Printer Description each operation on the Subordinate Printer. The means for configuring
Operations to be used with if the attribute is an operation attribute: URIs for Subordinate Printer objects is implementation-dependent as are
N/A all URIs. However, there are two distinct approaches:
Object (Job, Printer, etc. if bound to an object): Printer
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
boolean
If attribute syntax is 'keyword' or 'enum', is it type2 or type3: N/A
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2): No
If this is a Job Template attribute, how does its specification depend
on the value of the "multiple-document-handling" attribute: N/A
Specification of this attribute (follow the style of IPP Model Section
4.2):
4.4.? printer-controls-other-protocols (boolean) a. When the implementation wants to make sure that no operation on
a Subordinate Printer object as a target "sneaks by" the parent
Printer object (or the Subordinate Printer is fronting for a device
that is not networked), the host part of the URI specifies the host
of the parent Printer. Then the parent Printer object can easily
reflect the state of the Subordinate Printer objects in the
parent's Printer object state and state reasons as the operation
passes "through" the parent Printer object.
This Printer attribute indicates whether operations, such as Disable- b. When the Subordinate Printer is networked and the implementation
Printer, Pause-Printer, etc., affect non-IPP protocols that may be allows operations to go directly to the Subordinate Printer (with
supported. It is RECOMMENDED that IPP control other non-IPP protocols. proper access control) without knowledge of the parent Printer
However, this attribute permits an implementation to indicate explicitly object, the host part of the URI is different than the host part of
whether it does affect other protocols or not. the parent Printer object. In such a case, the parent Printer
object MUST keep its "printer-state" and "printer-state-reasons" up
to date, either by polling the Subordinate Printer object or by
subscribing to events with the Subordinate Printer object (see
[ipp-not-spec] for means to subscribe to event notification when
the Subordinate Printer object supports IPP notification).
A 'false' value indicates that IPP operations only affect jobs submitted Expires: January 6, 2001
by the IPP Protocol. For example, a 'true' value indicates that a
Disable-Printer operation prevents all protocols from submitting jobs,
not just the IPP protocol. An another example, a 'true' value indicates
that the Pause-Printer operation would pause the current job, no matter
what job submission protocol had submitted it.
ISSUE 6: Ok that the "printer-controls-other-protocols" Printer 4.5 Printer object attributes used to represent Output Device Fan-Out
Description attribute is just a boolean, or do we need a list of
operations that affect non-IPP protocols?
TH> It would be more flexible to allow per-operation control, so Only Leaf IPP Printer objects are allowed to have one or more associated
change from "printer-controls-other-protocols" Printer Description Output Devices. Each Leaf Printer object MAY support the "output-
attribute to "operations-affecting-other-protocols (1setOf type2 devices-supported" (1setOf name(127)) to indicate the user-friendly
enum). The values are defined by the "operations-supported (1setOf name(s) of the Output Device(s) that the Leaf Printer object represents.
type2 enum)" operation. It is RECOMMENDED that each Leaf Printer object have only one associated
Output Device, so that the individual Output Devices can be represented
completely and controlled completely by clients. In other words, the
Leaf Printer's "output-devices-supported" attribute SHOULD have only one
value.
HRL> The situation is already complex in that SNMP or IPP (possibly Non-Leaf Printer MUST NOT have associated Output Devices. However, a
others?) may "compete" or "conflict" is managing the printer. Per- Non-Leaf Printer SHOULD support an "output-devices-supported" (1setOf
operation control does nothing to alleviate this and may make the name(127)) Printer Description attribute that contains all the values of
situation even more complex. Suggest leave as is. its immediate Subordinate Printers. Since such Subordinate Printers MAY
be Leaf or Non-Leaf, the same rules apply to them, etc. Thus any Non-
Leaf Printer SHOULD have an "output-devices-supported" (1setOf
name(127)) attribute that contains all the values of the Output Devices
associated with Leaf Printers of its complete sub-tree.
As with any Printer Description attribute that this specification does When adding, removing, or changing a configuration of Printers and
not list as READ-ONLY, an implementation MAY allow a client to change Output Devices, there can be moments in time when the tree structure is
the value of this attribute using Set-Printer-Attributes, thereby not consistent. In other words, times when a Non-Leaf Printer's
changing the way that the IPP operations affect other non-IPP protocols. "subordinate-printers-supported" does not agree with the Subordinate
An implementation MAY also support other means to change the value of Printer's "parent-printers-supported". Therefore, the operator SHOULD
this attribute, such as via the console or at installation time. first Deactivate all Printers that are being configured in this way,
update all pointer attributes, and then reactivate. A useful client
tool would validate a tree structure before Activating the Printers
involved.
Expires: March 19, 2000 Expires: January 6, 2001
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 4.6 Figures to show all possible configurations
ISSUE 7: Is IPP intended for printer management. The issue is still Figure 1, Figure 2, and Figure 3 are taken from [ipp-mod] to show the
undetermined? configurations possible with IPP/1.0 and IPP/1.1 where all Printer
TH> I think it is natural and so far there is not much overlap with objects are Leaf Printer objects. The remaining figures show additional
any MIB. If and when we do get overlap, we need to make sure that the configurations that this document defines using Non-Leaf and Leaf
semantics are the same. Printer objects. Legend for all figures:
HRL> I think it is clear that IPP is moving in this direction. I leave ----> indicates a network protocol with the direction of its requests
this issue open for further discussion, however, because I believe we
need to be as clear as possible about the possible conflicts of two
management protocols originating form one organization (SNMP and IPP)
and provide some guidelines.
4.5 printer-message-time (integer(MIN:MAX)) ##### indicates a Printer object which is either:
- embedded in an Output Device or
- hosted in a server. The Printer object
might or might not be capable of queuing/spooling.
Type of registration: attribute any indicates any network protocol or direct
Proposed keyword name of this attribute: printer-message-time connect, including IPP
Types of attribute (Operation, Job Template, Job Description, Printer Output Device
Description): Printer Description +---------------+
Operations to be used with if the attribute is an operation attribute: | ########### |
N/A O +--------+ | # (Leaf) # |
Object (Job, Printer, etc. if bound to an object): Printer /|\ | client |------------IPP-----------------># Printer # |
Attribute syntax(es) (include 1setOf and range as in Section 4.2): / \ +--------+ | # Object # |
integer(MIN:MAX) | ########### |
If attribute syntax is 'keyword' or 'enum', is it type2 or type3: N/A +---------------+
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2): No
If this is a Job Template attribute, how does its specification depend
on the value of the "multiple-document-handling" attribute: N/A
Specification of this attribute (follow the style of IPP Model Section
4.2):
4.4.? printer-message-time (integer(MIN:MAX)) Figure 1 - Embedded Printer object
This READ-ONLY Printer Description attribute contains the time that the ########### Output Device
Printer's "printer-message-from-operator" was changed by the operator O +--------+ # (Leaf) # +---------------+
using any operation where the client supplied the "printer-message-from- /|\ | client |---IPP----># Printer #---any->| |
operator" operation attribute (see section 3.1) or was explicitly set / \ +--------+ # object # | |
using the Set-Printer-Attributes operation (see section 7.1.1). This ########### +---------------+
attribute allows the users to know when the "printer-message-from-
operator" attribute was last set.
The Printer sets the value of this attribute by copying the value of the Figure 2 - Hosted Printer object
Printer's "printer-up-time" attribute (see [ipp-mod] section 4.3.14).
If the Printer resets its "printer-up-time" attribute to 1 on power-up,
then it MUST change the value of the "printer-message-time" to 0 or a
negative number as specified in [ipp-mod] section 4.3.14.
Note: This attribute helps users better understand the context for the +---------------+
"printer-message-from-operator" message. | |
+->| Output Device |
########### any/ | |
O +--------+ # (Leaf) # / +---------------+
/|\ | client |---IPP----># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
+->| Output Device |
| |
+---------------+
Expires: March 19, 2000 Figure 3 - Output Device fan out
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Expires: January 6, 2001
########### ###########
O +--------+ # Non-Leaf# # subord. #
/|\ | client |---IPP----># Printer #---IPP----># Printer #
/ \ +--------+ # object # # object #
########### ###########
4.6 printer-message-date-time (dateTime) The Subordinate Printer can be a Non-Leaf Printer as in Figure 4 to
Figure 6, or can be a Leaf Printer as in Figure 1 to Figure 3.
Type of registration: attribute Figure 4 - Chained IPP Printer
Proposed keyword name of this attribute: printer-message-date-time
Types of attribute (Operation, Job Template, Job Description, Printer
Description): Printer Description
Operations to be used with if the attribute is an operation attribute:
N/A
Object (Job, Printer, etc. if bound to an object): Printer
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
dateTime
If attribute syntax is 'keyword' or 'enum', is it type2 or type3: N/A
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2): No
If this is a Job Template attribute, how does its specification depend
on the value of the "multiple-document-handling" attribute: N/A
Specification of this attribute (follow the style of IPP Model Section
4.2):
4.4.? printer-message-date-time (dateTime) +------IPP--------------------->###########
/ +---># subord. #
/ / # Printer #
/ ########### any # object #
O +--------+ # Non-Leaf# / ###########
/|\ | client |---IPP----># Printer #--*
/ \ +--------+ # object # \
\ ########### any ###########
\ \ # subord. #
\ +---># Printer #
+------IPP---------------------># object #
###########
This READ-ONLY Printer Description attribute contains the date and time The Subordinate Printer can be a Non-Leaf Printer as in Figure 4 to
that the Printer's "printer-message-from-operator" was changed by the Figure 6, or can be a Leaf Printer as in Figure 1 to Figure 3.
operator using any operation where the client supplied the "printer-
message-from-operator" operation attribute (see section 3.1) or was
explicitly set using the Set-Printer-Attributes operation (see section
7.1.1). This attribute allows the users to know when the "printer-
message-from-operator" attribute was last set. This attribute MUST be
supported if the Printer supports both the "printer-message-from-
operator" and the "printer-current-date-time" attributes.
Note: This attribute helps users better understand the context for the Figure 5 - IPP Printer fan out
"printer-message-from-operator" message.
4.7 printer-message-operation (type2 keyword) (Non-Leaf)
###########
# Non-Leaf#
+---># Printer #-+
/ # object # \
IPP ########### \ ###########
O +--------+ / +-IPP-># subord. #
/|\ | client |--+-----------IPP---------------># Printer #
/ \ +--------+ \ +-IPP-># object #
IPP ########### / ###########
\ # Non-Leaf# /
+---># Printer #-+
# object #
###########
(Non-Leaf)
The Subordinate Printer can be a Non-Leaf Printer as in Figure 4, Figure
5, or Figure 6, or can be a Leaf Printer as in Figure 1, Figure 2, or
Figure 3.
Type of registration: attribute Figure 6 - IPP Printer fan in
Proposed keyword name of this attribute: printer-message-operation
Types of attribute (Operation, Job Template, Job Description, Printer
Description): Printer Description
Operations to be used with if the attribute is an operation attribute:
N/A
Object (Job, Printer, etc. if bound to an object): Printer
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
type2 enum
If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2): No
If this is a Job Template attribute, how does its specification depend
on the value of the "multiple-document-handling" attribute: N/A
Expires: March 19, 2000 Expires: January 6, 2001
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 4.7 Forwarding requests
Specification of this attribute (follow the style of IPP Model Section This section describes the forwarding of Job and Printer requests to
4.2): Subordinate Printer objects.
4.4.? printer-message-operation (type2 enum) 4.7.1 Forwarding requests that affect Printer objects
This READ-ONLY Printer Description attribute contains the operation that In Printer fan-out, Printer fan-in, and Chained Printers, the Non-Leaf
was used to changed the Printer's "printer-message-from-operator" by the IPP Printer object MUST NOT forward the operations that affect Printer
operator using any operation where the client supplied the "printer- objects to its Subordinate Printer objects. If a client wants to
message-from-operator" operation attribute (see section 3.1) or explicitly target a Subordinate Printer, the client MUST specify the URI
explicitly set using the Set-Printer-Attributes operation (see section of the Subordinate Printer. The client can determine the URI of any
7.1.1). This attribute allows the users to know which operation was Subordinate Printers by querying the Printer's "subordinate-printers-
used to change the "printer-message-from-operator" attribute when it was supported (1setOf uri) attribute (see section 6.1).
last set.
Note: This attribute helps users better understand the context for the Table 2 lists the operations that affect Printer objects and the
"printer-message-from-operator" message. forwarding behavior that a Non-Leaf Printer MUST exhibit to its
immediate Subordinate Printers. Operations that affect jobs have a
different forwarding rule (see section 0 and Table 3):
4.8 when-values-supported (1setOf type2 keyword) Table 2 - Forwarding operations that affect Printer objects
Type of registration: attribute Printer Operation Non-Leaf Printer action
Proposed keyword name of this attribute: when-values-supported Printer Operations:
Types of attribute (Operation, Job Template, Job Description, Printer Enable-Printer MUST NOT forward to any of its Subordinate
Description): Printer Description Printers
Operations to be used with if the attribute is an operation attribute: Disable-Printer MUST NOT forward to any of its Subordinate
N/A Printers
Object (Job, Printer, etc. if bound to an object): Printer Hold-New-Jobs MUST NOT forward to any of its Subordinate
Attribute syntax(es) (include 1setOf and range as in Section 4.2): Printers
1setOf type2 keyword Release-Held-New- MUST NOT forward to any of its Subordinate
If attribute syntax is 'keyword' or 'enum', is it type2 or type3: type2 Jobs Printers
If this is a Printer attribute, MAY the value returned depend on Deactivate-Printer MUST NOT forward to any of its Subordinate
"document-format" (See Section 6.2): No Printers
If this is a Job Template attribute, how does its specification depend Activate-Printer MUST NOT forward to any of its Subordinate
on the value of the "multiple-document-handling" attribute: N/A Printers
Specification of this attribute (follow the style of IPP Model Section Restart-Printer MUST NOT forward to any of its Subordinate
4.2): Printers
Shutdown-Printer MUST NOT forward to any of its Subordinate
Printers
Startup-Printer MUST NOT forward to any of its Subordinate
Printers
IPP/1.1 Printer See [ipp-mod]
Operations:
Get-Printer- MUST NOT forward to any of its Subordinate
Attributes Printers
Pause-Printer MUST NOT forward to any of its Subordinate
Printers
Resume-Printer MUST NOT forward to any of its Subordinate
Printers
Set operations: See [ipp-set-ops]
Set-Printer- MUST NOT forward to any of its Subordinate
Attributes Printers
4.4.? when-values-supported (1setOf type2 keyword) Expires: January 6, 2001
This READ-ONLY Printer Description attribute contains the supported Forwarding requests that affect Jobs
values for the "when" operation attribute in any operation. The
operations include: Pause-Printer, Reset-Printer, Shutdown-Printer, and
Pause-Current-Job. For Pause-Current-Job, only the 'now' and 'after-
current-copy' values are defined. So the other values: 'after-current-
job' and 'after-all', if present in this attribute, don't apply to
Pause-Current-Job).
Expires: March 19, 2000 Unlike Printer Operations that only affect Printer objects (see section
0), a Non-Leaf Printer object MUST forward operations that directly
affect jobs to the appropriate Job object(s) in one or more of its
immediate Subordinate Printer objects. Forwarding is REQUIRED since the
purpose of such a Job operation is to affect the indicated job which
itself may have been forwarded. Such forwarding MAY be immediate or
queued, depending on the operation and the implementation. For example,
a Non-Leaf Printer object MAY queue/spool jobs, feeding a job at a time
to its Subordinate Printer(s), or MAY forward jobs immediately to one of
its Subordinate Printers. In either case, the Non-Leaf Printer object
is forwarding Job Creation operations to one of its Subordinate
Printers. Only the time of forwarding of the Job Creation operations
depends on whether the policy is to queue/spool jobs in the Non-Leaf
Printer or the Subordinate Printer.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 When a Non-Leaf Printer object creates a Job object in its Subordinate
Printer, whether that Non-Leaf Printer object keeps a fully formed Job
object or just keeps a mapping from the "job-ids" that it assigned to
those assigned by its Subordinate Printer object is IMPLEMENTATION-
DEPENDENT. In either case, the Non-Leaf Printer MUST be able to accept
and carry out future Job operations that specify the "job-id" that the
Non-Leaf Printer assigned and returned to the job submitting client.
4.9 device-names-supported (1setOf name(127)) Table 3 lists the operations that directly affect jobs and the
forwarding behavior that a Non-Leaf Printer MUST exhibit to its
Subordinate Printers:
ISSUE 8 - For consistency with [ipp-mod], shouldn't this be singular Table 3 - Forwarding operations that affect Jobs objects
even though it is multi-valued, i.e., device-name-supported (1setOf
name(127))?
This OPTIONAL Printer attribute contains at least one device name which Job operation
is associated with this Printer object. It OPTIONALLY contains more Non-Leaf Printer action
than one device name which is associated with this Printer object, i.e.,
fan-out, see [ipp-mod] section 2.1. A Printer object which does not
have an associated named device MUST NOT support this attribute.
An Administrator determines device names and configures this attribute Job operations:
to contain those device names via IPP Set-Printer-Attributes operation Reprocess-Job MUST forward to the appropriate Job in one of
(see section 7.1.1) or by some means outside the scope of this document. its Subordinate Printers
The precise format of these device names is implementation dependent and Cancel- MUST NOT forward
MAY depend on the protocol stack and the directory namespace. Current-Job
Resume-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Promote-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
IPP/1.1 Printer
Operations:
Print-Job MUST forward immediately or queue to the
appropriate Subordinate Printer
Print-URI MUST forward immediately or queue to the
appropriate Subordinate Printer
Validate-Job MUST forward to the appropriate Subordinate
Printer
Create-Job MUST forward immediately or queue to the
appropriate Subordinate Printer
Note: The new attribute "device-names-supported" will also enhance the Expires: January 6, 2001
usefulness of the IPP/1.1 Job object attribute "output-device-assigned" Get-Jobs MUST forward to all its Subordinate Printers
(see [ipp-mod] section 4.3.13). The "output-device-assigned" Job Purge-Jobs MUST forward to all its Subordinate Printers
attribute identifies the output device to which the Printer object has IPP/1.1 Job
assigned a job, for example, when a single Printer object is supporting operations:
multiple devices. Send-Document MUST forward immediately or queue to the
appropriate Job in one of its Subordinate
Printers
Send-URI MUST forward immediately or queue to the
appropriate Job in one of its Subordinate
Printers
Cancel-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Get-Job- MUST forward to the appropriate Job in one of
Attributes its Subordinate Printers, if the Non-Leaf
Printer doesn't know the complete status of the
Job object
Hold-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Release-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Restart-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
IPP Set operations: See [ipp-set-ops]
Set-Job- MUST forward to the appropriate Job in one of
Attributes its Subordinate Printers
See also the operation attribute "device-name" in section 3.5 of this When a Printer receives a request that REQUIRES forwarding, it does so
document. on a "best efforts basis", and returns a response to its client without
waiting for responses from any of its Subordinate Printers. Such
forwarded requests could fail. In order for a client to become aware of
such a condition, a new 'forwarded-operation-failed' event is defined,
which a client can subscribe to (see section [ipp-ntfy]).
5. Additional values for "printer-state-reasons" and "job-state-reasons" The following Job Description attributes are defined to help represent
attributes Job relationships for fan-out and forwarding of jobs:
The following values are added to the "printer-state-reasons" and "job- 1."output-device-assigned" (name(127)) - from [ipp-mod]: This attribute
state-reasons" for use with the operations defined in this document. identifies the Output Device to which the Printer object has assigned
this job. If an Output Device implements an embedded Printer object,
the Printer object NEED NOT set this attribute. If a print server
implements a Printer object, the value MAY be empty (zero-length
string) or not returned until the Printer object assigns an Output
Device to the job. This attribute is particularly useful when a
single Printer object supports multiple devices (so called "fan-
out").
5.1 Value for "printer-state-reasons": 'standby' 2."original-requesting-user-name" (name(MAX)) - operation attribute
containing the user name of the original user, i.e., corresponds to
the "requesting-user-name" operation attribute that the original
client supplied to the first Printer object. The IPP/1.1
"requesting-user-name" operation attribute (see [ipp-mod]) is updated
by each client to be itself on each hop, i.e., the "requesting-user-
name" is the client forwarding the request, not the original client.
The "job-originating-user-name" Job Description attribute remains as
Type of registration: type2 keyword attribute value Expires: January 6, 2001
Name of attribute to which this keyword specification is to be added: the authenticated original user, not the parent Printer's
printer-state-reasons authenticated host, and is forwarded by each client without changing
Proposed keyword name of this keyword value: standby the value.
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):
Expires: March 19, 2000 5 New Operation attributes
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 This section summarizes the usage of the new "printer-message-from-
operation" and "job-message-from-operator" operation attributes that set
the corresponding Printer and Job Description attributes. These
operation attributes are defined for most of the Device and Job
operations that operators are likely to perform, respectively, so that
operators can indicate the reasons for their actions. See [ipp-set-ops]
for the definition of these operation attributes.
Table 4 shows the operation attributes that are defined for use with the
Printer Operations.
Legend:
R - REQUIRED for a Printer to support
O - OPTIONAL for a Printer to support; the Printer ignores the
attribute if not supported
<blank> - not defined for use with the operation; the Printer
ignores the attribute
'standby': The Printer has been shutdown in standby mode. Only Table 4 - Operation attribute support for Printer Operations
Restart-Printer and Get-Printer-Attributes operations are accepted
in this state; all other operations are rejected with the 'server-
error-printer-is-in-standby-mode'.
5.2 Value for "job-state-reasons": 'job-paused' Operation Pause- Hold- Purge- Get- Enabl Rest Shut
Attribute Printer, New- Jobs Printe e- art- down
Pause- Jobs, r- Print Prin -
Printer- Release- Attrib , ter Prin
After- Held- utes, Disab ter,
Current- New-Jobs Set- le- Star
Job, Printe Print tup-
Resume- r- er Prin
Printer Attrib ter
utes
Type of registration: type2 keyword attribute value attributes- R R R R R R R
Name of attribute to which this keyword specification is to be added: charset
job-state-reasons
Proposed keyword name of this keyword value: job-paused
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):
'job-paused': The job has been paused while processing using the
Pause-Current-Job operations and other jobs can be processed on the
Printer. The Job can be resumed using the Resume-Job operation
which removes this value.
6. New status codes attributes- R R R R R R R
natural-
language
This section defines new status codes used by the operations defined in printer-uri R R R R R R R
this document.
6.1 New status code: 'client-error-attributes-not-settable' requesting- R R R R R R R
user-name
Type of registration: status code printer- O O O O O O
Keyword symbolic name of this status code value: 'client-error- message-
attributes-not-settable' from-
Numeric value (to be assigned by the IPP Designated Expert in operator
consultation with IANA):
Operations that this status code may be used with: Set-Printer-
Attributes, Set-Job-Attributes
Specification of this status code (follow the style of IPP Model Section
13 APPENDIX B: Status Codes and Suggested Status Code Messages):
13.1.4.20 client-error-attributes-not-settable (0x0413) Table 5 shows the operation attributes that are defined for use with the
Job operations.
Legend:
R - REQUIRED for a Printer to support
In a Set-Printer-Attributes or Set-Job-Attributes request, if the Expires: January 6, 2001
Printer object does not support one or more attributes as settable, the O - OPTIONAL for a Printer to support; the Printer ignores the
Printer object MUST return this status code. The Printer object MUST attribute if supplied, but not supported
also return in the Unsupported Attributes Group all the attributes <blank> - not defined for use with the operation; the Printer
and/or values supplied by the client that are not settable. See [ipp- ignores the attribute
mod] section 3.1.7. For example, if the request indicates 'job-state',
all implementations MUST reject the request. As another example, if the
request indicates an attribute that is supported, but not settable by
this implementation, such as, say, "printer-name", the implementation
rejects the request.
Expires: March 19, 2000 Table 5 - Operation attribute support for Job operations
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Operation Can Canc Hol Sus Re Get- Rest Repr Pro Red Sch
Attribute cel el- d- pen su Job- art- oces mot ire edu
- Curr Job d- me Attrib Job s- e- ct- le-
Job ent- , Cur - utes, Job Job Job Job
Job Rel ren Jo Set- -
eas t- b Job- Aft
e- Job Attrib er
Job utes
6.2 New status code: 'server-error-printer-is-in-standby-mode' attributes- R R R R R R R R R R R
charset
Type of registration: status code attributes- R R R R R R R R R R R
Keyword symbolic name of this status code value: 'server-error-printer- natural-
is-in-standby-mode' language
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA):
Operations that this status code may be used with: Shutdown-Printer
Specification of this status code (follow the style of IPP Model Section
13 APPENDIX B: Status Codes and Suggested Status Code Messages):
13.1.5.8 server-error-printer-is-in-standby-mode printer-uri R R R R R R R R R R R
The Printer has been shutdown and is only accepting the Restart-Printer job-uri R R R R R R R R R
(see section 7.1.5) and Get-Printer-Attributes operations. An operator
can perform the Restart-Printer operation to allow the Printer to accept
other operations.
7. Summary of Set 2 operations and Operation-Id Assignments job-id R R R R R R R R R R R
The Set 2 operations are summarized in the following table: requesting- R R R R R R R R R R R
user-name
Operation Name Operati Brief description job- O O O O O O O O O O
on-Id message-
from-
operator
Set-Printer- 0x?? Sets attribute values of the target message O O O O O O O O O
Attributes Printer object [to-
operator]
Enable-Printer 0x?? Allows the target Printer to accept job-hold- O* O**
create job operations until
Disable-Printer 0x?? Prevents the target Printer from * The Printer MUST support the "job-hold-until" operation attribute
accepting create job operations if it supports the "job-hold-until" Job Template attribute.
** The Printer MUST support the "job-hold-until" operation attribute if
it supports the Set-Job-Attributes operation, so that the client can
hold the job with the Reprocess-Job operation and the modify the job
before releasing it to be processed.
Reset-Printer 0x?? Resets the target Printer to one of 6 New Printer Description Attributes
several indicated ways
Restart-Printer 0x?? Restarts the target Printer from a The following new Printer Description attributes are needed to support
standby shutdown mode the new operations defined in this document.
Non-Process- 0x?? Moves the last printed sheet(s) to the Expires: January 6, 2001
Run-Out exit or stacker
Shutdown- 0x?? Shuts down the target Printer in 6.1 subordinate-printers-supported (1setOf uri)
Printer several ways
Set-Job- 0x?? Sets attribute values of the target Job This Printer attribute is REQUIRED if an implementation supports
Attributes object Subordinate Printers (see section 4) and contains the URIs of the
immediate Subordinate Printer object(s) associated with this Printer
object. Each Non-Leaf Printer object MUST support this Printer
Description attribute. A Leaf Printer object either does not support
the "subordinate-printers-supported" attribute or does so with the 'no-
value' out-of-band value (see [ipp-mod] section 4.1), depending on
implementation.
Reprocess-Job 0x?? Creates a copy of a completed target The precise format of the Subordinate Printer URIs is implementation
job with a new Job ID and processes it dependent (see section 4.4).
Cancel-Current- 0x?? Cancels the current job on the target If the Printer object does not have an associated Output Device, the
Job Printer or the specified job if it is Printer MAY automatically copy the value of the Subordinate Printer
the current job object's "printer-name" MAY be used to populate the Job object's
"output-device-assigned" attribute (see [ipp-mod] section 4.3.13). The
"output-device-assigned" Job attribute identifies the Output Device to
which the Printer object has assigned a job, for example, when a single
Printer object is supporting Device fan-out or Printer fan-out.
Pause-Current- 0x?? Pauses the current processing job on 6.2 parent-printers-supported (1setOf uri)
Job the target Printer or the specified job
if it is the current job, allowing
other jobs to be processed instead
Resume-Job 0x?? Resume the paused target job This Printer attribute is REQUIRED if an implementation supports
Subordinate Printers (see section 4) and contains the URI of the Non-
Leaf printer object(s) for which this Printer object is the immediate
Subordinate, i.e., this Printer's immediate "parent" or "parents". Each
Subordinate Printer object MUST support this Printer Description
attribute. A Printer that has no parents, either does not support the
"parent-printers-supported" attribute or does so with the 'no-value'
out-of-band value (see [ipp-mod] section 4.1), depending on
implementation.
Expires: March 19, 2000 6.3 redirection-printers-supported (1setOf uri)
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 This Printer attribute is REQUIRED if an implementation supports the
Redirect-Job operation (see section 12.5). It specifies the URIs that
the Printer supports for redirection jobs to other Printers (on the same
server).
Operation Name Operati Brief description 7 Additional Values for "printer-state-reasons"
on-Id
Promote-Job 0x?? Promote the pending target job to be This section defines additional values for the "printer-state-reasons"
next after the current job(s) complete Printer Description attribute.
Space-Current- 0x?? Skips or repeats the specified number Expires: January 6, 2001
Job of impressions for the current job on
the target Printer or the specified job
if it is the current job
All of the operations in this registration proposal specification are 7.1 'hold-new-jobs'
OPTIONAL for an IPP object to support. Unless the specification of an
OPTIONAL operation requires support of another OPTIONAL operation,
conforming implementations may support any combination of these
operations.
7.1 Printer Operations 'hold-new-jobs': The operator has issued the Hold-New-Jobs operation
(see section 0) or other means, but the output-device(s) are taking
an appreciable time to stop. Later, when all output has stopped,
the "printer-state" becomes 'stopped', and the 'paused' value
replaces the 'moving-to-paused' value in the "printer-state-
reasons" attribute. This value MUST be supported, if the Hold-New-
Jobs operation is supported and the implementation takes
significant time to pause a device in certain circumstances.
All Printer operations are directed at Printer objects. A client MUST 7.2 'deactivated'
always supply the "printer-uri" operation attribute in order to identify
the correct target of the operation. These descriptions assume all of
the common semantics of IPP/1.1 Model and Semantics document [ipp-mod]
section 3.1.
7.1.1 Set-Printer-Attributes Operation 'deactivated': A client has issued a Deactivate-Printer operation
for the Printer object (see section 0) and the Printer is in the
process of becoming deactivated or has become deactivated. The
Printer MUST reject all requests except Activate-Printer, queries
(Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs, etc.), Send-
Document, and Send-URI (so that partial job submission can be
completed - see section 0) and return the 'server-error-service-
unavailable' status code.
Type of registration: operation 8 Additional Values for "job-state-reasons"
Proposed name of this operation: Set-Printer-Attributes
Object Target: Printer
Specification of this operation:
This OPTIONAL operation allows a client to set the values of the This section defines additional values for the "job-state-reasons" Job
attributes of a Printer object. In the request, the client supplies Description attribute.
the set of Printer attribute names and values that are to be set. In
the response, the Printer object returns success or rejects the request
with indications of which attribute or attributes could not be set.
How the Printer object validates the client-supplied attributes in the 8.1 'job-suspended'
Set-Printer-Attributes request is implementation-dependent, since there
are no corresponding Printer attributes that specify the allowed values
that may be set on the Printer object.
The Printer MUST accept this operation in any state, i.e., for any of 'job-suspended': The job has been suspended while processing using
the values of the Printer object's "printer-state" attribute. the Suspend-Current-Job operation and other jobs can be processed
on the Printer. The Job can be resumed using the Resume-Job
operation which removes this value.
7.1.1.1 Settable and READ-ONLY Printer Description attributes 9 Additional events
If the Printer supports the "printer-message-from-operator" Printer The following Printer events are defined for use with [ipp-ntfy]:
Description attribute (see [ipp-mod] section 4.4.25) and the client
explicitly supplies a new value for the "printer-message-from-operator"
in the request, then the Printer MUST set the "printer-message-from-
Expires: March 19, 2000 'forwarded-operation-failed' - an operation that a Printer forwarded
to a Subordinate Printer (see section 4.7) failed.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 10 Additional status codes
operator" Printer attribute to this new value and MUST also set the This section defines new status codes used by the operations defined in
"printer-message-time", "printer-message-date-time", and "printer- this document.
message-operation" attributes, if supported (see sections 4.5, 4.6, and
4.7).
If the Printer supports the Set-Printer-Attributes operation, then it Expires: January 6, 2001
SHOULD support setting of:
all Job Template Default ("xxx-default") attributes 10.1 'server-error-printer-is-deactivated' (0x????)
all Job Template Supported ("xxx-supported") attributes
all Job Template Ready ("xxx-ready") attributes
that the implementation supports (see [ipp-mod] section 4.2 and The Printer has been deactivated using the Deactivate-Printer operation
extensions). and is only accepting the Activate-Printer (see section 0), Get-Job-
Attributes, Get-Jobs, Get-Printer-Attributes, and any other Get-Xxxx
operations. An operator can perform the Activate-Printer operation to
allow the Printer to accept other operations.
The following Printer Description attributes (see [ipp-mod] section 4.4) 11 Definition of the Printer Operations
MUST NOT be settable, i.e., they are READ-ONLY:
printer-state All Printer Operations are directed at Printer objects. A client MUST
printer-state-reasons always supply the "printer-uri" operation attribute in order to identify
printer-state-message the correct target of the operation. These descriptions assume all of
printer-is-accepting-jobs - see Enable-Printer/Disable-Printer the common semantics of IPP/1.1 Model and Semantics document [ipp-mod]
queued-job-count section 3.1.
printer-message-time - see Set-Printer-Attributes when setting
"printer-message-from-operator"
printer-message-date-time - see Set-Printer-Attributes when setting
"printer-message-from-operator"
printer-message-operation - see Set-Printer-Attributes when setting
"printer-message-from-operator"
when-values-supported
printer-up-time
settable-attributes
The remaining Printer Description attributes MAY be settable using the The Set 2 Printer Operations are summarized in Table 6:
Set-Printer-Attributes operation, depending on implementation. If "xxx-
supported" Printer Description attribute are settable, then they MUST
affect the behavior of the implementation. If they are READ-ONLY then
they reflect the implementation and cannot be changed using the Set-
Printer-Attributes operation. Consider the following examples:
For example, if the "operations-supported" Printer Description Table 6 - Printer Operation Operation-Id assignments
attribute (see [ipp-mod] section 4.4.15) is settable, then changing
its value MUST affect the operations that the implementation
accepts or rejects. Such an implementation will need to be able to
reject values for operations that it contains no code support for.
As another example, if the "ipp-versions-supported" Printer Operation Name Operati Brief description
Description attribute (see [ipp-mod] section 4.4.14) is settable, on-Id
then changing its value MUST affect the protocol versions that are Enable-Printer 0x?? Allows the target Printer to accept Job
accepted or rejected. Such an implementation will need to be able Creation operations
to reject values for operations that it contains no code support Disable-Printer 0x?? Prevents the target Printer from
for. accepting Job Creation operations
Pause-Printer- 0x?? Pause the Printer after the current job
After-Current- has been sent to the Output Device.
Job
Hold-New-Jobs 0x?? Finishes processing all currently
pending jobs. Any new jobs are placed
in the 'pending-held' state.
Release-Held- 0x?? Release all jobs to the 'pending' state
New-Jobs that had been held by the effect of a
previous Hold-New-Jobs operation and
condition the Printer to no longer hold
new jobs.
Deactivate- 0x?? Puts the Printer into a read-only
Printer deactivated state.
Activate- 0x?? Restores the Printer to normal activity
Printer
Restart-Printer 0x?? Restarts the target Printer and re-
initializes the software
Shutdown- 0x?? Shuts down the target Printer so that
Printer it cannot be restarted or queried
Startup-Printer 0x?? Starts up the instance of the Printer
object
Expires: March 19, 2000 All of the operations in this document are OPTIONAL for an IPP object to
support. Unless the specification of an OPTIONAL operation requires
support of another OPTIONAL operation, conforming implementations may
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Expires: January 6, 2001
See the "factory-settings" operation attribute (see section 3.3) for a support any combination of these operations. Many of the operations
way to query the implementation supported values using the Get-Printer- come in pairs and so both are REQUIRED if either one is implemented.
Attributes operation. See the "reset-function" operation attribute of
the Reset-Printer operation (see section 7.1.4) for a way to restore the
values to the factory settings.
Access Rights: Authentication and access control (see [ipp-mod] sections Expires: January 6, 2001
1, 8.3, and 8.5) apply to this operation.
Most Printer attributes will require administrator privileges to set, 11.1 The Disable and Enable Printer Operations
such as "xxx-supported", while some will require operator privileges
only, such as "media-ready" and "printer-message-from-operator". Which
attributes require which privileges depends on implementation and MAY
depend on site policy.
7.1.1.2 Set-Printer-Attributes Request This section defines the OPTIONAL Disable-Printer and Enable-Printer
operations that stop and start the IPP Printer object from accepting new
IPP jobs. If either of these operations are supported, both MUST be
supported.
The following sets of attributes are part of the Set-Printer-Attributes These operations allow the operator to control whether or not the
Request: Printer will accept new Job Creation (Print-Job, Print-URI, and Create-
Job) operations. These operations have no other effect on the Printer,
so that the Printer continues to accept all other operations and
continues to schedule and process jobs normally. In other words, these
operation control the "input of new jobs" to the IPP Printer while the
Pause and Resume operations (see section 11.2) independently control the
"output of new jobs" from the IPP Printer to the Output Device.
Group 1: Operation Attributes The Disable-Printer and Enable-Printer operations MUST NOT affect the
submission of jobs using other job submission protocols to the
associated Output Device; the Disable and Enable Device Operations (see
[ipp-device-ops]) are intended to stop the acceptance of all jobs by the
associated Output Device(s).
Natural Language and Character Set: Disable-Printer Operation
The "attributes-charset" and "attributes-natural-language"
attributes as described in [ipp-mod] section 3.1.4.1.
Target: This OPTIONAL operation allows a client to stop the Printer object from
The "printer-uri" (uri) operation attribute which is the target for accepting new jobs, i.e., cause the Printer to reject subsequent Job
this operation as described in [ipp-mod] section 3.1.5. Creation operations and return the 'server-error-not-accepting-jobs'
status code. The Printer still accepts all other operations, including
Validate-Job, Send-Document and Send-URI operations. Thus a Disable-
Printer operation allows a client to continue submitting multiple
documents of a multiple document job if the Create-Job operation had
already been accepted. All previously created or submitted Jobs and
currently processing Jobs continue unaffected.
Requesting User Name: The IPP Printer MUST accept the request in any state. The Printer sets
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied the value of its "printer-is-accepting-jobs" READ-ONLY Printer
by the client as described in [ipp-mod] section 8.3. Description attribute to 'false' (see [ipp-mod] section 4.4.20), no
matter what the previous value was. This operation has no immediate or
direct effect on the Printer's "printer-state" and "printer-state-
reasons" attributes.
"document-format" (mimeMediaType): Access Rights: The authenticated user (see [ipp-mod] section 8.3)
The client SHOULD supply this attribute. The Printer object MUST performing this operation must be an operator or administrator of the
support this attribute. This attribute is useful for a client to Printer object (see [ipp-mod] Sections 1 and 8.5).
select the Interpreter object to which the attribute modification
should be applied. Each Printer object is modeled to contain one
or more Interpreter objects. Those Printer attributes whose values
vary from Interpreter to Interpreter, are modeled as Interpreter
objects, while those that do not are Printer object attributes.
Thus the target of a Get-Printer-Attributes or Set-Printer-
Attributes operation is either the Printer object or the
Interpreter object identified by the "document-format" operation
attribute supplied by the client. Except for Get-Printer-
Attributes and Set-Printer-Attributes, there are no other
operations with the Interpreter object as a target. See [ipp-mod]
section 3.2.5.1 "Get-Printer-Attributes Request".
Expires: March 19, 2000 The Disable-Printer Request and Disable-Printer Response have the same
attribute groups and attributes as the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
message-from-operator" operation attribute (see section 5).
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Expires: January 6, 2001
If a client wants to set an attribute of all of the Interpreter Enable-Printer Operation
objects to the same value, it can query the Printer's "document-
format-supported" Printer Description attribute and perform
separate Set-Printer-Attributes for each document format supported.
ISSUE 9: Do we need a way to get and/or set the "xxx" attribute This OPTIONAL operation allows a client to start the Printer object
for all Interpreter objects in one Get-Printer-Attributes or Set- accepting jobs, i.e., cause the Printer to accept subsequent Job
Printer-Attributes operation? Or is it sufficient for a client to Creation operations. The Printer still accepts all other operations.
provide the equivalent functionality by stepping through all the All previously submitted Jobs and currently processing Jobs continue
values of the "document-formats-supported" with repeating the Get unaffected.
or Set operation?
ISSUE 10: Ok to add the Interpreter object, even though it doesn't The IPP Printer MUST accept the request in any state. The Printer sets
solve all of the attribute constraint problems. At least it gives the value of its "printer-is-accepting-jobs" READ-ONLY Printer
us a more object-based description of the semantics. When we do Description attribute to 'true' (see [ipp-mod] section 4.4.20), no
add some sort of Printer Description attribute that enumerates matter what the previous value was. This operation has no immediate or
combinations of Job attribute values that may not be used in direction effect on the Printer's "printer-state" and "printer-state-
combination (like PPD file constraints), it can include the reasons" attributes.
"document-format" attribute among them. So introducing the
Interpreter object in no way precludes a complete constraint
description mechanism in the future.
If the Printer object does not distinguish between different sets Access Rights: The authenticated user (see [ipp-mod] section 8.3)
of supported values for each different document format when performing this operation must be an operator or administrator of the
validating jobs in the create and Validate-Job operations, it MUST Printer object (see [ipp-mod] Sections 1 and 8.5).
NOT distinguish between different document formats in the Set-
Printer-Attributes operation. If the Printer object does
distinguish between different sets of supported values for each
different document format specified by the client, this
specialization applies only to the same Printer attributes as the
Get-Printer-Attributes operation (see [ipp-mod] section 3.2.5.1).
If the client omits this "document-format" operation attribute, the The Enable-Printer Request and Enable-Printer Response have the same
Printer object MUST respond as if the attribute had been supplied attribute groups and attributes as the Pause-Printer operation (see
with the value of the Printer object's "document-format-default" [ipp-mod] sections 3.2.8.1 and 3.2.8.2), including the new "printer-
attribute. It is recommended that the client always supply a value message-from-operator" operation attribute (see section 5).
for "document-format", since the Printer object's "document-format-
default" may be 'application/octet-stream', in which case the set
attributes and values are for the union of the document formats
that the Printer can automatically sense. For more details, see
the description of the 'mimeMediaType' attribute syntax in [ipp-
mod] section 4.1.9.
If the client supplies a value for the "document-format" Operation 11.2 The Pause and Resume Printer Operations
attribute that is not supported by the Printer, i.e., is not among
the values of the Printer object's "document-format-supported"
attribute, the Printer object MUST reject the operation and return
the 'client-error-document-format-not-supported' status code.
Group 2: Printer Attributes This section leaves the OPTIONAL IPP/1.1 Pause-Printer (see [ipp-mod]
sections 3.2.7) to be ambiguous as to whether or not it stops the
Printer immediately or after the current job and defines the OPTIONAL
Pause-Printer-After-All-Current-Jobs operation to be after the current
job. These operations affect the scheduling of IPP jobs. If either of
these Pause Printer operations are supported, then the Resume-Printer
operation MUST be supported.
Expires: March 19, 2000 These operations allow the operator to control whether or not the
Printer will send new IPP jobs to the associated Output Device(s) that
the IPP Printer object represents. These operations have no other
effect on the Printer, so that the Printer continues to accept all
operations. In other words, these operation control the "output of new
jobs" to the Output Device(s) while the Disable and Enable Printer
Operations (see section 11.1) independently control the "input of new
jobs" to the IPP Printer.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 The Pause and Resume Printer Operations MUST NOT affect jobs that were
submitted using other job submission protocols to the associated Output
Device; the Pause and Resume Device Operations (see [ipp-device-ops])
are intended to stop the acceptance of all jobs by the associated Output
Device(s).
The client MUST supply a set of Printer attributes as defined in Expires: January 6, 2001
[ipp-mod] section 4.2 Job Template Attributes ("xxx-default", "xxx-
supported", and "xxx-ready" attributes) and section 4.4 Printer
Description Attributes. Each Printer attribute supplied in Group 2
replaces the value(s) of the corresponding Printer attribute on the
target Printer object. If a Printer object attribute had not been
configured yet and so had the 'no-value' out-of-band value (see
[ipp-mod] 4.1), the supplied value(s) replace the 'no-value' value.
For attributes that can have multiple values (1setOf), all values
supplied by the client replace all values of the corresponding
Printer object attribute.
7.1.1.3 Set-Printer-Attributes Response This document and [ipp-device-ops] define distinct operations in order
to disambiguate the Pause-Printer operation as shown in Table 7. The
Printer Operations affect only Jobs submitted using IPP, while the
Device Operations affect all jobs no matter what job submission protocol
was used to submit them to the Output Device.
The Printer object returns the following sets of attributes as part of Table 7 - Pause and Resume Printer and Device Operations
the Get-Printer-Attributes Response:
Group 1: Operation Attributes Pause and Resume Printer Description
and Device Operations
Status Message: IPP/1.1 Pause Printer Stops the IPP Printer from sending
In addition to the REQUIRED status code returned in every response, new IPP Jobs to the Output Device(s)
the response OPTIONALLY includes a "status-message" (text(255)) either immediately or after the
and/or a "detailed-status-message" (text(MAX)) operation attribute current job completes, depending on
as described in [ipp-mod] sections 13 and 3.1.6. implementation, as defined in [ipp-
mod].
Pause-Printer-After- Stops the IPP Printer from sending
Current-Job new IPP Jobs to the Output Device(s)
after the current jobs finish
Resume-Printer Starts the IPP Printer sending IPP
Jobs to the Output Device again.
Pause-Device-Now Stops the Output Device immediately
from producing marked media (current
page, sheet, depending on
implementation) for any job. Like the
Pause button on the Output Device.
Pause-Device-After- Stops the Output Device from
Current-Copy producing marked media after the
current copy of the current job.
Pause-Device-After- Stops the Output Device from
Current-Job producing marked media after the
current job.
Resume-Device Starts the Output Device processing
any jobs again.
Natural Language and Character Set: Pause-Printer-After-Current-Job operation
The "attributes-charset" and "attributes-natural-language"
attributes as described in [ipp-mod] section 3.1.4.2.
Group 2: Unsupported Attributes This OPTIONAL operation allows a client to stop the Printer object from
starting to send IPP jobs to any of its Output Devices or Subordinate
Printers. If the IPP Printer is in the middle of sending an IPP job to
an Output Device or Subordinate Printer, the IPP Printer MUST complete
sending that Job. However, after receiving this operation, the IPP
Printer MUST NOT start to send any additional IPP jobs to any of its
Output Devices or Subordinate Printers. In addition, after having
received this operation, the IPP Printer MUST NOT start processing any
more jobs, so additional jobs MUST NOT enter the 'processing' state.
See [ipp-mod] section 3.1.7 for details on returning Unsupported If the IPP Printer is not sending an IPP Job to the Output Device or
Attributes. Subordinate Printer (whether or not the Output Device or Subordinate
Printer is busy processing any jobs), the IPP Printer object transitions
immediately to the 'stopped' state by setting its "printer-state"
attribute to 'stopped', removing the 'moving-to-paused' value, if
In the case of attributes that are supported, but are not settable Expires: January 6, 2001
by the implementation, i.e., are not among the values of the
Printer's "settable-attributes" Printer Description attribute (see
section 4.1), the Printer object returns the client-supplied
attribute(s) with a substituted value of 'not-supported' (same out-
of-band value as for attributes that are not supported). This
value's syntax type is "out-of-band" and its encoding is defined by
special rules for "out-of-band" values in the "Encoding and
Transport" document [IPP-PRO]. Its value indicates that the
attribute is either not settable or is not supported at all.
ISSUE 11: Why not have a separate out-of-band 'not-settable' present, from its "printer-state-reasons" attribute, and adding the
value, so that the client can distinguish between the cases of the 'paused' value to its "printer-state-reasons" attribute.
attribute isn't supported versus the attribute is supported, but is
not settable? True, the client can query the "settable-attributes"
Expires: March 19, 2000 If the implementation will take appreciable time to complete sending an
IPP job that it has started sending to an Output Device or Subordinate
Printer, the IPP Printer adds the 'moving-to-paused' value to the
Printer object's "printer-state-reasons" attribute (see section [ipp-
mod] 4.4.12). When the IPP Printer has completed sending IPP jobs that
it was in the process of sending, the Printer object transitions to the
'stopped' state by setting its "printer-state" attribute to 'stopped',
removing the 'moving-to-paused' value, if present, from its "printer-
state-reasons" attribute, and adding the 'paused' value to its "printer-
state-reasons" attribute.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 This operation MUST NOT affect the acceptance of Job Creation requests
(see Disable-Printer section 0).
to see which attributes can be set, before or after issuing the For any jobs that are 'pending' or 'pending-held', the 'printer-stopped'
Set-Printer-Attributes operation. value of the jobs' "job-state-reasons" attribute also applies. However,
TH> I think that providing a separate out-of-band code is useful, the IPP Printer NEED NOT update those jobs' "job-state-reasons"
since a reply could contain both unsupported attributes and ones that attributes and only need return the 'printer-stopped' value when those
were supported, but are not settable in this implementation. jobs are queried using the Get-Job-Attributes or Get-Jobs operations
(so-called "lazy evaluation").
HRL> What's wrong with what's already described? How is the new The IPP Printer MUST accept the request in any state and transition the
proposal better? Printer to the indicated new "printer-state" and MUST add the indicated
value to "printer-state-reasons" attribute before returning as follows:
7.1.2 Disable-Printer Operation Current New "printer IPP Printer's response status
"printer- "printer- -state- code and action:
state" state" reasons"
REQUIRED/OPTIONAL state
transition for a Printer to
support
Type of registration: operation 'idle' 'stopped' 'paused' REQUIRED: 'successful-ok'
Proposed name of this operation: Disable-Printer
Object Target: Printer
Specification of this operation:
This OPTIONAL operation allows a client to stop the Printer object from 'processing' 'processing' 'moving- OPTIONAL: 'successful-ok';
accepting jobs, i.e., cause the Printer to reject subsequent create job to- Later, when the IPP Printer has
operations (Print-Job, Print-URI, and Create-Job operation) and return paused' finished sending IPP jobs to an
the 'server-error-not-accepting-jobs' status code. The Printer still Output Device, the "printer-
accepts all other operations. All previously submitted Jobs and state" becomes 'stopped', and
currently processing Jobs continue unaffected. The Printer sets the the 'paused' value replaces the
value of its "printer-is-accepting-jobs" READ-ONLY Printer Description 'moving-to-paused' value in the
attribute to 'false' (see [ipp-mod] section 4.4.20), no matter what the "printer-state-reasons"
previous value was. This operation has no immediate effect on the attribute
Printer's "printer-state" and "printer-state-reasons" attributes.
Note: Use the Enable-Printer operation (section 7.1.3) to enable a 'processing' 'stopped' 'paused' REQUIRED: 'successful-ok'; the
Printer to accept Jobs again. IPP Printer wasn't in the middle
of sending an IPP job to an
Output Device
If the Disable-Printer operation is supported, then the Enable-Printer 'stopped' 'stopped' 'paused' REQUIRED: 'successful-ok'
operation MUST be supported, and vice-versa.
Note: Use the Enable-Printer and Disable-Printer operations to allow or Access Rights: The authenticated user (see [ipp-mod] section 8.3)
prevent input to a Printer. Use the Pause-Printer and Resume-Printer performing this operation must be an operator or administrator of the
operations to prevent or allow output from the Printer. Printer object (see [ipp-mod] Sections 1 and 8.5).
Whether or not the Disable-Printer operation stops jobs that are Expires: January 6, 2001
submitted using job submission protocols other than IPP, depends on
implementation, i.e., on whether the IPP protocol is being used as a
universal management protocol or just to manage IPP jobs, respectively.
See "printer-controls-other-protocols" (section 4.4).
Access Rights: Authentication and access control (see [ipp-mod] sections The Pause-Printer-After-Current-Job Request and Pause-Printer-After-
1, 8.3, and 8.5) apply to this operation. Current-Job Response have the same attribute groups and attributes as
the Pause-Printer operation (see [ipp-mod] sections 3.2.7.1 and
3.2.7.2), including the new "printer-message-from-operator" operation
attribute (see section 5).
The Disable-Printer Request and Disable-Printer Response have the same 11.3 Hold and Release New Jobs operations
attribute groups and attributes as the Resume-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
message-from-operator" operation attribute (see section 3.1), and with
Expires: March 19, 2000 This section defines operations to condition the Printer to hold any new
jobs and to release them.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Hold-New-Jobs operation
the addition of the following Group 1 operation attribute in the This OPTIONAL operation allows a client to condition the Printer to
request: complete the current 'pending' and 'processing' IPP Jobs but not start
processing any subsequently created IPP Jobs. If the IPP Printer is in
the middle of sending an IPP job to an Output Device or Subordinate
Printer, the IPP Printer MUST complete sending that Job. Furthermore,
the IPP Printer MUST send all of the current 'pending' IPP Jobs to the
Output Device(s) or Subordinate IPP Printer object(s). Any subsequently
received Job Creation operations will cause the IPP Printer to put the
Job into the 'pending-held' state with the 'job-held-on-create' value
being added to the job's "job-state-reasons" attribute. Thus all newly
accepted jobs will be automatically held by the Printer.
"job-type" (type2 keyword): When the Printer completes all of the 'pending' and 'processing' jobs,
The client OPTIONALLY supplies this attribute. The Printer object it enters the 'idle' state as usual. An operator that is monitoring
OPTIONALLY supports this attribute. The value of this attribute Printer state changes will know when the Printer has completed all
indicates the type of job to be disabled. If the client omits this current jobs because the Printer enters the 'idle' state.
attribute, the Printer assumes the 'network-jobs' value.
Standard keyword values are: This operation MUST NOT affect the acceptance of Job Creation requests
'network-jobs' - disable jobs submitted using the create job (see Disable-Printer section 0), except to put the Jobs into the
operations. 'pending-held' state, instead of the 'pending' or 'processing' state.
'walk-up-jobs' - disable jobs submitted locally, such as
walkup copy jobs
'all-jobs' - disable all type of jobs
7.1.3 Enable-Printer Operation The IPP Printer MUST accept the request in any state, MUST NOT
transition the Printer to any other "printer-state", and MUST add the
'hold-new-jobs' value to the Printer's "printer-state-reasons" attribute
(whether the value was present or not).
Type of registration: operation Access Rights: The authenticated user (see [ipp-mod] section 8.3)
Proposed name of this operation: Enable-Printer performing this operation must be an operator or administrator of the
Object Target: Printer Printer object (see [ipp-mod] Sections 1 and 8.5).
Specification of this operation:
This OPTIONAL operation allows a client to start the Printer object The Hold-New-Jobs Request and Hold-New-Jobs Response have the same
accepting jobs, i.e., cause the Printer to accept subsequent create job attribute groups and attributes as the Pause-Printer operation (see
operations (Print-Job, Print-URI, and Create-Job operation). The [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
Printer still accepts all other operations. All previously submitted message-from-operator" operation attribute (see section 5).
Jobs and currently processing Jobs continue unaffected. The Printer
sets the value of its "printer-is-accepting-jobs" READ-ONLY Printer
Description attribute to 'true' (see [ipp-mod] section 4.4.20), no
matter what the previous value was. This operation has no immediate
effect on the Printer's "printer-state" and "printer-state-reasons"
attributes.
Note: Use the Disable-Printer operation (section 7.1.2) to stop a Release-Held-New-Jobs operation
Printer from accepting Jobs.
If the Enable-Printer operation is supported, then the Disable-Printer This OPTIONAL operation allows a client to undo the effect of a previous
operation MUST be supported, and vice-versa. Hold-New-Jobs operation. In particular, the Printer releases all of the
Note: Use the Enable-Printer and Disable-Printer operations to allow or Expires: January 6, 2001
prevent input to a Printer. Use the Pause-Printer and Resume-Printer
operations to prevent or allow output from the Printer.
Whether or not the Enable-Printer operation allows acceptance of jobs jobs that it had held as a consequence of a Hold-New-Jobs operations,
that are submitted using job submission protocols other than IPP, i.e., while the 'hold-new-jobs' value was present in the Printer's
depends on implementation, i.e., on whether the IPP protocol is being "printer-state-reasons" attribute. In addition, the Printer MUST accept
used as a universal management protocol or just to manage IPP jobs, this request in any state, MUST NOT transition the Printer to any other
respectively. See "printer-controls-other-protocols" (section 4.4). "printer-state", and MUST remove the 'hold-new-jobs' value from its
"printer-state-reasons" attribute (whether the value was present or not)
so that the Printer no longer holds newly created jobs.
Access Rights: Authentication and access control (see [ipp-mod] sections Access Rights: The authenticated user (see [ipp-mod] section 8.3)
1, 8.3, and 8.5) apply to this operation. performing this operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).
Expires: March 19, 2000 The Release-Held-New-Jobs Request and Release-Held-New-Jobs Response
have the same attribute groups and attributes as the Pause-Printer
operation (see [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the
new "printer-message-from-operator" operation attribute (see section 5).
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 11.4 Deactivate and Activate Printer Operations
The Enable-Printer Request and Enable-Printer Response have the same This section defines the OPTIONAL Deactivate-Printer and Activate-
attribute groups and attributes as the Resume-Printer operation (see Printer operations that stop and start the IPP Printer object from
[ipp-mod] sections 3.2.8.1 and 3.2.8.2), including the new "printer- accepting all requests except queries and performing work. If either of
message-from-operator" operation attribute (see section 3.1), and with these operations are supported, both MUST be supported.
the addition of the following Group 1 operation attribute in the
request:
"job-type" (type2 keyword): These operations allow the operator to put the Printer into a dormant
The client OPTIONALLY supplies this attribute. The Printer object read-only condition and to take it out of such a condition. These
OPTIONALLY supports this attribute. The value of this attribute operations are a combination of the Deactivate and Pause operations,
indicates the type of job to be enabled. If the client omits this plus preventing the acceptance of any other requests, except queries.
attribute, the Printer assumes the 'network-jobs' value.
Standard keyword values are: The Deactivate and Activate Printer Operations MUST NOT affect the
'network-jobs' - enable jobs submitted using the create job submission of jobs using other job submission protocols to the
associated Output Device; the Deactivate and Activate Device Operations
(see [ipp-device-ops]) are intended to stop the associated Output
Device(s) from performing work and accepting operations, except query
operations. operations.
'walk-up-jobs' - enable jobs submitted locally, such as walkup
copy jobs
'all-jobs' - enable all types of jobs
7.1.4 Reset-Printer operation Deactivate-Printer operation
Type of registration: operation
Proposed name of this operation: Reset-Printer
Object Target: Printer
Specification of this operation:
This OPTIONAL operation allows a client to reset the Printer in a number
of ways, depending on the "reset-function" operation attribute. The
keyword values of this attribute map one-to-one to the enum values that
the NMS writes into the prtGeneralReset object in the Printer MIB
[RFC1759] to affect a reset operation. As in the Printer MIB, the
'reset-to-nvram' (soft reset) value MUST be supported, if this operation
is supported. The other values are OPTIONAL.
As is says in the Printer MIB specification, if a device does not have
NVRAM (non-volatile RAM), the device MUST none-the-less respond to this
operation for the 'reset-to-nvram' value with some sort of warm reset
that resets the device to some implementation-defined state that is
preferably under control of the system administrator by some means
outside the scope of the Printer MIB and this document.
The effect of this operation on the currently processing job(s), if any,
is not specified by this document. Note: If this operation does affect
the current job(s), it is expected that the operator would issue this
operation on a Printer in the 'idle' state after disabling the Printer
with the Disable operation in order to prevent a job from inadvertently
being affected by this operation.
The Printer object MUST accept this operation in any state and This OPTIONAL operation allows a client to stop the Printer object from
transition the Printer object to the 'idle' state. starting to send IPP jobs to any of its Output Devices or Subordinate
Printers (Pause-Printer-After-Current-Job) and stop the Printer object
from accepting any, but query requests. The Printer performs a Disable-
Printer and a Pause-Printer-After-Current-Job operation immediately,
including use of all of the "printer-state-reasons" if these two
operations cannot be completed immediately. In addition, the Printer
MUST immediately reject all requests, except Activate-Printer, queries
(Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs, etc.), Send-
Document, and Send-URI (so that partial job submission can be completed
- see section 0) and return the 'server-error-service-unavailable'
status code.
Expires: March 19, 2000 Expires: January 6, 2001
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 The IPP Printer MUST accept the request in any state. Immediately, the
Printer MUST set the 'deactivated' value in its "printer-state-reasons"
attribute. Note: neither the Disable-Printer nor the Pause-Printer-
After-Current-Job set the 'deactivated' value.
Access Rights: Authentication and access control (see [ipp-mod] sections Access Rights: The authenticated user (see [ipp-mod] section 8.3)
1, 8.3, and 8.5) apply to this operation. performing this operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).
The Reset-Printer Request and Reset-Printer Response have the same The Deactivate-Printer Request and Deactivate-Printer Response have the
attribute groups and attributes as the Pause-Printer operation (see same attribute groups and attributes as the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer- [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
message-from-operator" operation attribute (see section 3.1), the new message-from-operator" operation attribute (see section 5).
"when" operation attribute (see section 3.4), and with the addition of
the following Group 1 operation attributes in the request:
"reset-function" (type3 keyword):
The client OPTIONALLY supplies this attribute. The Printer object
MUST support this attribute, if it supports this operation. The
value of this attribute indicates the reset function to be
performed. If the client omits this attribute, the Printer assumes
the 'reset-to-nvram' value.
Standard keyword values are:
'power-cycle-reset' - Cold start, i.e., to the state when the
device is powered up.
'reset-to-nvram' - Warm start.
'reset-to-factory-defaults' - reset NVRAM to factory defaults,
i.e. to factory settings and/or values established at
install time.
7.1.5 Restart-Printer operation
Type of registration: operation Activate-Printer operation
Proposed name of this operation: Restart-Printer
Object Target: Printer
Specification of this operation:
This OPTIONAL operation allows a client to restart a Printer that has This OPTIONAL operation allows a client to undo the effects of the
previously been shutdown in standby mode (see section 7.1.7). Standby Deactivate-Printer, i.e., allow the Printer object to start sending IPP
mode is indicated by the Printer's "printer-state" being 'stopped' and jobs to any of its Output Devices or Subordinate Printers (Pause-
its "printer-state-reasons" including the 'standby' and 'paused' values. Printer-After-Current-Job) and start the Printer object from accepting
If the Printer is not in standby mode, the Printer MUST reject this any requests. The Printer performs an Enable-Printer and a Resume-
operation and return the 'client-error-not-possible' status code. Printer operation immediately. In addition, the Printer MUST
immediately start accepting all requests.
ISSUE 12: What state does the Printer comes back up on Restart-Printer The IPP Printer MUST accept the request in any state. Immediately, the
and how can the client control? Printer MUST immediately remove the 'deactivated' value from its
Possible alternatives: "printer-state-reasons" attribute (whether present or not).
a. Restart-Printer always brings the Printer up Disabled ("printer- Access Rights: The authenticated user (see [ipp-mod] section 8.3)
is-accepting-jobs" = 'false') and Paused ("printer-state" = performing this operation must be an operator or administrator of the
'stopped', and "printer-state-reasons" = 'paused') which is the Printer object (see [ipp-mod] Sections 1 and 8.5).
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
Expires: March 19, 2000 The Activate-Printer Request and Activate-Printer Response have the same
attribute groups and attributes as the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
message-from-operator" operation attribute (see section 5).
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 11.5Restart-Printer, Shutdown-Printer, and Startup-Printer operations
without changing the Restart-Printer operation, and can have the This section defines the OPTIONAL Restart-Printer, Shutdown-Printer, and
same GUI interface as b: Startup-Printer operations that initialize, shutdown, and startup the
Printer object, respectively. Each of these operations is OPTIONAL and
any combination MAY be supported.
b. Add a REQUIRED operation attribute to Restart-Printer, something The Restart-Printer, Shutdown-Printer, and Startup-Printer operations
like "printer-condition" with values: 'disabled-and-paused', MUST NOT affect the submission of jobs using other job submission
'enabled-and-paused', and 'enabled-and-idle'. protocols to the associated Output Device; the Reset-Device and Power-
Off-Device Operations (see [ipp-device-ops]) are intended to initialize
or power off the associated Output Device(s).
TH 7/26: Remove the Shutdown-Printer 'standby' mode concept. Expires: January 6, 2001
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 Restart-Printer operation
disable or enable it? Don't understand 2nd half of this issue
resolution.
If the Restart-Printer operation is supported, then the Shutdown-Printer This OPTIONAL operation allows a client to restart a Printer object
operation MUST be supported, since the Restart-Printer operation is whose operation is in need of initialization because of incorrect or
meaningful only after a Shutdown-Printer operation has been performed. erratic behavior, i.e., perform the effect of a software re-boot. The
However, if the Shutdown-Printer operation is supported, the Restart- implementation MUST attempt to save any information about Jobs and the
Printer NEED NOT be supported. Printer object before re-initializing. However, this operation MAY have
drastic consequences on the running system, so the operator should first
try the Deactivate-Printer to minimize the effect on the current state
of the system. The effects of previous Disable-Printer, Pause Printer,
and Deactivate-Printer operations are lost.
Issue 13: Why? This is backward, if you ask me (HRL). The IPP Printer MUST accept the request in any state. The Printer
object MUST initialize its Printer's "printer-state" to 'idle', remove
the state reasons from its "printer-state-reasons" attribute, and its
"printer-is-accepting-jobs" attribute to 'true'.
Access Rights: Authentication and access control (see [ipp-mod] sections Access Rights: The authenticated user (see [ipp-mod] section 8.3)
1, 8.3, and 8.5) apply to this operation. performing this operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).
The Restart-Printer Request and Restart-Printer Response have the same The Restart-Printer Request and Restart-Printer Response have the same
attribute groups and attributes as the Resume-Printer operation (see attribute groups and attributes as the Pause-Printer operation (see
[ipp-mod] sections 3.2.8.1 and 3.2.8.2), including the new "printer- [ipp-mod] sections 3.2.8.1 and 3.2.8.2), including the new "printer-
message-from-operator" operation attribute (see section 3.1) and the message-from-operator" operation attribute (see section 5).
following Group 1 operation attribute:
7.1.6 Non-Process-Run-Out Operation
ISSUE 14 - 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?
Type of registration: operation
Proposed name of this operation: Non-Process-Run-Out
Object Target: Printer
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
Specification of this operation:
This OPTIONAL operation effectively moves the last printed sheet to the
exit or stacker. The terminology is common to long path continuous forms
devices but may have applicability on shorter devices or in cut-sheet
applications.
Access Rights: Authentication and access control (see [ipp-mod] sections
1, 8.3, and 8.5) apply to this operation.
The Non-Process-Run-Out Request and Non-Process-Run-Out Response have
the same attribute groups and attributes as the Pause-Printer operation
(see [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new
"printer-message-from-operator" operation attribute (see section 3.1)
and the new "when" operation attribute (see section 3.4).
7.1.7 Shutdown-Printer Operation Expires: January 6, 2001
Type of registration: operation Shutdown-Printer Operation
Proposed name of this operation: Shutdown-Printer
Object Target: Printer
Specification of this operation:
This OPTIONAL operation allows a client to shutdown a Printer, i.e., This OPTIONAL operation allows a client to shutdown a Printer, i.e.,
stop processing jobs and power off in some implementation-dependent stop processing jobs and make the Printer object no longer available for
manner. The purpose of Shutdown-Printer is to shutdown the Printer for any operations using the IPP protocol without losing any jobs. There is
an extended period, not to reset the device(s) or modify a Printer no way to bring the instance of the Printer object back to being used,
attribute. See Reset-Printer (section 7.1.4) for the way to reset the except for the Startup-Printer (see section 0) which starts up a new
device(s). See the Disable-Printer operation (section 7.1.2) for a way instance of the Printer object for hosted implementations. The purpose
of Shutdown-Printer is to shutdown the Printer for an extended period,
not to reset the device(s) or modify a Printer attribute. See Restart-
Printer (section 0), Startup-Printer (section ), and Reset-Device [ipp-
device-ops] for the way to initialize the software or reset the Output
Device(s). See the Disable-Printer operation (section 11.1) for a way
for the client to stop the Printer from accepting Job Creation requests for the client to stop the Printer from accepting Job Creation requests
without stopping processing or shutting down. without stopping processing or shutting down.
The Printer is disabled immediately (see the Disable-Printer operation The Printer MUST add the 'shutdown' value (see [ipp-mod] section 4.4.11)
in section 7.1.2). The Printer adds the 'shutdown' value (see [ipp-mod] immediately to its "printer-state-reasons" Printer Description attribute
section 4.4.11) to its "printer-state-reasons" Printer Description and performs a Deactivate-Printer operation (see section 0) which
attribute. The "when" operation attribute specifies how much processing performs a Disable-Printer and Pause-Printer-After-Current-Job
occurs before the Printer is paused (see [ipp-mod] section 3.2.7) and operation).
the shutdown is complete. All other requests continue to be accepted
until the printer is powered down.
ISSUE 15 - 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
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
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?
Whether or not the Shutdown-Printer operation affects jobs that were Note: In order to shutdown the Printer after all the currently
submitted to the device using job submission protocols other than IPP, submitted jobs have completed, the operator issues a Disable-Printer
depends on implementation, i.e., on whether the IPP protocol is being operation (see section 0) and then waits until all the jobs have
used as a universal management protocol or just to manage IPP jobs, completed and the Printer goes into the 'idle' state before issuing the
respectively. See "printer-controls-other-protocols" (section 4.4). Shutdown-Printer operation.
The Printer object MUST accept this operation in any state and The Printer object MUST accept this operation in any state and
transition the Printer object to the 'idle' state. transition the Printer object through the "printer-states" and "printer-
state-reasons" defined for the Pause-Printer-After-Current-Job operation
until the activity is completed and the Printer object disappears.
Access Rights: Authentication and access control (see [ipp-mod] sections Access Rights: The authenticated user (see [ipp-mod] section 8.3)
1, 8.3, and 8.5) apply to this operation. performing this operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).
The Shutdown-Printer Request and Shutdown-Printer Response have the same The Shutdown-Printer Request and Shutdown-Printer Response have the same
attribute groups and attributes as the Pause-Printer operation (see attribute groups and attributes as the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer- [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
message-from-operator" operation attribute (see section 3.1), the new message-from-operator" operation attribute (see section 5).
"when" operation attribute (see section 3.4), and with the addition of
the following Group 1 operation attributes in the request:
"shutdown-function" (type2 keyword)
The client OPTIONALLY supplies this attribute. The Printer object
OPTIONALLY supports this attribute. This attribute indicates which
shutdown function is to be performed.
Standard keyword values are: Startup-Printer operation
'standby' - shutdown the Printer, but leave it in standby-mode
(disabled and paused), which means that Get-Printer-
Attributes and Restart-Printer operations are accepted.
'power-off' - shutdown the Printer and power it off. No
operations are accepted after power off.
"synchronize" (boolean) This OPTIONAL operation allows a client to startup an instance of a
The client OPTIONALLY supplies this attribute. The Printer object Printer object, provided that there isn't one already instantiated. The
OPTIONALLY supports this attribute. This attribute indicates purpose of Startup-Printer is to allow a hosted implementation of the
whether or not the printer is to synchronize the checkpoint data IPP Printer object (i.e., a Server that implements an IPP Printer on
for the current job ("when" = 'now') with the pages that have behalf of a networked or local Output Device) to be started after the
actually printed. If the value of the "when" attribute is not host is available (by means outside this document). See Restart-Printer
'now' or the "when" attribute is not supplied, then the (section 0) and Reset-Device [ipp-device-ops] for the way to initialize
"synchronize" attribute has no meaning and the Printer MUST ignore the software or reset the Output Device(s) when the IPP Printer object
it. If this attribute is supported, then a value of 'true' implies has already been instantiated.
that the Printer will be able to resume the job at the point of
synchronization when the Printer is restarted. If the
implementation does not support resuming a job (either
automatically or with the Resume-Job operation) after a Shutdown-
Printer with "when" = 'now', then it does not implement this
Expires: March 19, 2000 Expires: January 6, 2001
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 The host MUST accept this operation only when the Printer object has not
been instantiated. If the Printer object already exists, the host must
return the 'client-error-not-possible' status code.
attribute. In this case, check-pointing implies that the job may The result of this operation MUST be with the Printer object's "printer-
be resumed in the future, exactly from the point and in the state state" set to 'idle', the state reasons removed from its "printer-state-
and resource context from which it left off. reasons" attribute, and its "printer-is-accepting-jobs" attribute set to
'false'. Then the operator can reconfigure the Printer before
performing an Enable-Printer operation. However, when a Printer is
first powered up, it is RECOMMENDED that its "printer-is-accepting-jobs"
attribute be set to 'true' in order to achieve easy "out of the box"
operation.
If the Printer supports this attribute but the client does not Access Rights: The authenticated user (see [ipp-mod] section 8.3)
supply it, the Printer is assumed to perform synchronization performing this operation must be an operator or administrator of the
('true' behavior). If the Printer does not support this attribute, Printer object (see [ipp-mod] Sections 1 and 8.5).
the Printer is assumed to not synchronize ('false' behavior).
ISSUE 16: Is the current job automatically restarted when the The Shutdown-Printer Request and Shutdown-Printer Response have the same
Printer is restarted? Or does some client have to issue a Restart- attribute groups and attributes as the Pause-Printer operation (see
Job operation? [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
The question is moot, if we remove the Restart-Job operation, as message-from-operator" operation attribute (see section 5).
suggested:
TH 7/26: Remove the Shutdown-Printer 'standby' mode concept. Expires: January 6, 2001
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?
7.2 Job Operations 12 Definition of the Job Operations
All Job operations are directed at Job objects. A client MUST always All Job operations are directed at Job objects. A client MUST always
supply some means of identifying the Job object in order to identify the supply some means of identifying the Job object in order to identify the
correct target of the operation. That job identification MAY either be correct target of the operation. That job identification MAY either be
a single Job URI or a combination of a Printer URI with a Job ID. The a single Job URI or a combination of a Printer URI with a Job ID. The
IPP object implementation MUST support both forms of identification for IPP object implementation MUST support both forms of identification for
every job. every job.
7.2.1 Set-Job-Attributes The Job Operations are summarized in Table 8:
Type of registration: operation
Proposed name of this operation: Set-Job-Attributes
Object Target: Job
Specification of this operation:
This OPTIONAL operation allows a client to set the values of the
attributes of a Job object. In the request, the client supplies the
set of Job attribute names and values that are to be set. In the
response, the IPP object returns success or rejects the request with
indications of which attribute or attributes could not be set.
This operation is almost identical to the Set-Printer-Attributes
operation (see section 7.1.1). The only differences are that the Set-
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
Job-Attributes operation is directed at a Job object rather than a
Printer object, there is no "document-format" operation attribute used
when setting a Job object, and the validation is the same as the create
job operations, i.e., depends on the "xxx-supported" Printer Description
attributes.
The validation of the Set-Job-Attributes request is performed as if the
job had been submitted originally with the new values and with "ipp-
attribute-fidelity" set to 'true', i.e., all modified attributes MUST be
supported along with the attributes not modified. If such a create job
operation would have been accepted, then the Set-Job-Attributes MUST be
accepted. If such a create job operation would have been rejected, then
the Set-Job-Attributes MUST be rejected and the Job MUST be unchanged.
The IPP object MUST accept or reject the request based on the job's
current state and transition the job to the indicated new state as
follows:
Current "job- New "job- IPP object's response status
state" state" code and action:
'pending' 'pending' 'successful-ok'
'pending' 'pending- 'successful-ok' - needed
held' resources are not ready
'pending-held' 'pending- 'successful-ok'
held'
'pending-held' 'pending' 'successful-ok' - needed
resources are ready
'processing' 'processing' 'successful-ok' or 'client-
error-not-possible' depending on
the attributes being set,
whether the job has started
marking media, and/or
implementation
'processing- 'processing- 'successful-ok' or 'client-
stopped' stopped' error-not-possible' depending on
the attributes being set,
whether the job has started
marking media, and/or
implementation
'completed' 'completed' 'client-error-not-possible'
'canceled' 'canceled' 'client-error-not-possible'
'aborted' 'aborted' 'client-error-not-possible'
7.2.1.1 Settable and READ-ONLY Job Description attributes
If the Printer supports the "job-message-from-operator" Job Description
attribute (see [ipp-mod] section 4.3.16) and the client explicitly
supplies a new value for the "job-message-from-operator" in the request,
then the Printer MUST set the "job-message-from-operator" Job attribute
to this new value.
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
If the Printer supports the Set-Job-Attributes operation, then it SHOULD
support setting of:
all Job Template ("xxx") attributes (see [ipp-mod] section 4.2 and
extensions)
that the implementation supports.
The following Job Description attributes (see [ipp-mod] section 4.3)
MUST NOT be settable, i.e., they are READ-ONLY:
job-uri
job-id
job-printer-uri
job-more-info
job-originating-user-name - set in create operation
job-state
job-state-reasons
job-state-message
number-of-documents
output-device-assigned
time-at-creation
time-at-processing
time-at-completed
job-printer-up-time
date-time-at-creation
date-time-at-processing
date-time-at-completed
number-of-intervening-jobs
job-k-octets
job-k-octets-processed
job-impressions-completed
job-media-sheets-completed
attributes-charset - set in create operation
attributes-natural-language - set in create operation
The remaining Job Description attributes MAY be settable using the Set-
Job-Attributes operation, depending on implementation.
Whether or not the Set-Job-Attributes operation affects jobs that are
submitted using job submission protocols other than IPP, depends on
implementation, i.e., on whether the IPP protocol is being used as a
universal management protocol or just to manage IPP jobs, respectively.
See "printer-controls-other-protocols" (section 4.4).
Access Rights: Authentication and access control (see [ipp-mod] sections
1, 8.3, and 8.5) apply to this operation.
7.2.1.2 Set-Job-Attributes Request
The following sets of attributes are part of the Set-Job-Attributes
Request:
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in [ipp-mod] section 3.1.4.1.
Target:
Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX))
or (2) the "job-uri" (uri) operation attribute(s) which define the
target for this operation as described in [ipp-mod] section 3.1.5.
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
by the client as described in [ipp-mod] section 8.3.
Group 2: Job Attributes
The client MUST supply a set of Job attributes as defined in [ipp-
mod] section 4.2 Job Template Attributes ("xxx" attributes) and
section 4.3 Job Description Attributes. Each Job attribute
supplied in Group 2 replaces the value(s) of the corresponding Job
attribute on the target Job object. For attributes that can have
multiple values (1setOf), all values supplied by the client replace
all values of the corresponding Job object attribute.
7.2.1.3 Set-Job-Attributes Response
The Printer object returns the following sets of attributes as part of
the Set-Job-Attributes Response:
Group 1: Operation Attributes
Status Message:
In addition to the REQUIRED status code returned in every response,
the response OPTIONALLY includes a "status-message" (text(255))
and/or a "detailed-status-message" (text(MAX)) operation attribute
as described in [ipp-mod] sections 13 and 3.1.6.
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in [ipp-mod] section 3.1.4.2.
Group 2: Unsupported Attributes
See [ipp-mod] section 3.1.7 for details on returning Unsupported
Attributes.
The attributes returned are the same as for the create operation
with the same new attribute values. In the case of attributes that
are supported, but are not settable by the implementation, i.e.,
Expires: March 19, 2000 Table 8 - Job operation Operation-Id assignments
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Operation Name Operati Brief description
on-Id
Reprocess-Job 0x?? Creates a copy of a completed target
job with a new Job ID and processes it
Cancel-Current- 0x?? Cancels the current job on the target
Job Printer or the specified job if it is
the current job
Suspend- 0x?? Suspends the current processing job on
Current-Job the target Printer or the specified job
if it is the current job, allowing
other jobs to be processed instead
Resume-Job 0x?? Resume the suspended target job
Promote-Job 0x?? Promote the pending target job to be
next after the current job(s) complete
Redirect-Job 0x?? Redirect the target job to the
specified Printer on the same server.
Schedule-Job- 0x?? Schedule the target job immediately
After after the specified job, all other
scheduling factors being equal.
are not among the values of the Printer's "settable-attributes" Expires: January 6, 2001
Printer Description attribute (see section 4.1), the Printer object
returns the client-supplied attribute(s) with a substituted value
of 'not-supported' (same out-of-band value as for attributes that
are not supported). This value's syntax type is "out-of-band" and
its encoding is defined by special rules for "out-of-band" values
in the "Encoding and Transport" document [IPP-PRO]. Its value
indicates that the attribute is either not settable or is not
supported at all.
7.2.2 Reprocess-Job Operation 12.1 Reprocess-Job Operation
This OPTIONAL operation is a create job operation that allows a client This OPTIONAL operation is a create job operation that allows a client
to re-process a copy of a job that had been retained in the queue after to re-process a copy of a job that had been retained in the queue after
processing completed, was canceled, or was aborted (see [ipp-mod] processing completed, was canceled, or was aborted (see [ipp-mod]
section 4.3.7.2). This operation is the same as the Restart-Job section 4.3.7.2). This operation is the same as the Restart-Job
operation (see [ipp-mod] section 3.3.7), except that the Printer creates operation (see [ipp-mod] section 3.3.7), except that the Printer creates
a new job that is a copy of the target job and the target job is a new job that is a copy of the target job and the target job is
unchanged. The new job is assigned new values to the "job-uri" and unchanged. The new job is assigned new values to the "job-uri" and
"job-id" attributes and the new job's Job Description attributes that "job-id" attributes and the new job's Job Description attributes that
accumulate job progress, such as "job-impressions-completed", "job- accumulate job progress, such as "job-impressions-completed", "job-
skipping to change at page 40, line 43 skipping to change at page 38, line 5
Reprocess-Job operations have been performed on it. Reprocess-Job operations have been performed on it.
If the Set-Job-Attributes operation is supported, then the "job-hold- If the Set-Job-Attributes operation is supported, then the "job-hold-
until" operation attribute MUST be supported with at least the until" operation attribute MUST be supported with at least the
'indefinite' value, so that a client can modify the new job before it is 'indefinite' value, so that a client can modify the new job before it is
scheduled for processing using the Set-Job-Attributes operation. After scheduled for processing using the Set-Job-Attributes operation. After
modifying the job, the client can release the job for processing, by modifying the job, the client can release the job for processing, by
using the Release-Job operation specifying the newly assigned "job-uri" using the Release-Job operation specifying the newly assigned "job-uri"
or "job-id" for the new job. or "job-id" for the new job.
7.2.3 Cancel-Current-Job Operation Expires: January 6, 2001
12.2 Cancel-Current-Job Operation
This OPTIONAL operation allows a client to cancel the current job on the This OPTIONAL operation allows a client to cancel the current job on the
target Printer or the specified job if it is the current job on the target Printer or the specified job if it is the current job on the
Printer. See [ipp-mod] section 3.3.3 for the semantics of canceling a Printer. See [ipp-mod] section 3.3.3 for the semantics of canceling a
job. Since a Job might already be marking by the time a Cancel-Current- job. Since a Job might already be marking by the time a Cancel-Current-
Job is received, some media sheet pages might be printed before the job Job is received, some media sheet pages might be printed before the job
is actually terminated. is actually terminated.
If the client does not supply a "job-id" operation attribute, the If the client does not supply a "job-id" operation attribute, the
Printer MUST accept the request and cancel the current job if there is a Printer MUST accept the request and cancel the current job if there is a
current job in the 'processing' or 'processing-stopped' state; current job in the 'processing' or 'processing-stopped' state;
otherwise, it MUST reject the request and return the 'client-error-not- otherwise, it MUST reject the request and return the 'client-error-not-
possible' status code. If more than one job is in the 'processing' or possible' status code. If more than one job is in the 'processing' or
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
'processing-stopped' states, the one that is marking is canceled and the 'processing-stopped' states, the one that is marking is canceled and the
others are unaffected. others are unaffected.
Warning: On a shared printer, there is a race condition. Between the Warning: On a shared printer, there is a race condition. Between the
time that a user issues this operation and its acceptance, the current time that a user issues this operation and its acceptance, the current
job might change to a different job. If the user or operator is job might change to a different job. If the user or operator is
authenticated to cancel the new job, the wrong job is canceled. To authenticated to cancel the new job, the wrong job is canceled. To
prevent this race from canceling the wrong job, the client MAY supply prevent this race from canceling the wrong job, the client MAY supply
the "job-id" operation attribute which is checked against the current the "job-id" operation attribute which is checked against the current
job's job-id. If the job identified by the "job-id" attribute is not job's job-id. If the job identified by the "job-id" attribute is not
the current job on the Printer, i.e., is not in the 'processing' or the current job on the Printer, i.e., is not in the 'processing' or
'processing-stopped' states, the Printer MUST reject this operation and 'processing-stopped' states, the Printer MUST reject this operation and
return the 'client-error-not-possible' status code. Otherwise, the return the 'client-error-not-possible' status code. Otherwise, the
Printer cancels the specified job. Printer cancels the specified job.
Access Rights: Authentication and access control (see [ipp-mod] sections Access Rights: The authenticated user (see [ipp-mod] section 8.3)
1, 8.3, and 8.5) apply to this operation. performing this operation must either be the job owner (as determined in
the Job Creation operation) or an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).
The Cancel-Current-Job Request and Cancel-Current-Job Response have the The Cancel-Current-Job Request and Cancel-Current-Job Response have the
same attribute groups and attributes as the Resume-Printer operation same attribute groups and attributes as the Resume-Printer operation
(see [ipp-mod] section 3.2.8), including the new "job-message-from- (see [ipp-mod] section 3.2.8), including the new "job-message-from-
operator" operation attribute (see section 3.2), with the addition of operator" operation attribute (see section 5), with the addition of the
the following Group 1 Operation attributes in the request: following Group 1 Operation attributes in the request:
"job-id" (integer(1:MAX)): "job-id" (integer(1:MAX)):
The client OPTIONALLY supplies this Operation attribute in order to The client OPTIONALLY supplies this Operation attribute in order to
verify that the identified job is still the current job on the verify that the identified job is still the current job on the
target Printer object. The IPP object MUST supports this operation target Printer object. The IPP object MUST supports this operation
attribute, if it supports this operation. attribute, if it supports this operation.
7.2.4 Pause-Current-Job operation Expires: January 6, 2001
12.3 Suspend and Resume Job operations
This section defines the Suspend-Current-Job and Resume-Job operations.
These operations allow an operator or user to suspend a job while it is
processing and allow other jobs to be processed and the resume the
suspended job at a later point in time without losing any of the output.
If either of these operations is supported, they both MUST be supported.
The Hold-Job and Release-Job operations ([ipp-mod] section 3.3.5) are
for holding and releasing held jobs, not suspending and resuming
suspended jobs.
Suspend-Current-Job operation
This OPTIONAL operation allows a client to stop the current job on the This OPTIONAL operation allows a client to stop the current job on the
target Printer or the specified job if it is the current job on the target Printer or the specified job if it is the current job on the
Printer, and allow other jobs to be processed instead. The Printer Printer, and allow other jobs to be processed instead. The Printer
moves the current job or the target job to the 'processing-stopped' moves the current job or the target job to the 'processing-stopped'
state and sets the 'job-paused' value in the job's "job-state-reasons" state and sets the 'job-suspended' value (see section 8.1) in the job's
attribute and processes other jobs. "job-state-reasons" attribute and processes other jobs.
If the client does not supply a "job-id" operation attribute, the If the client does not supply a "job-id" operation attribute, the
Printer MUST accept the request and pause the current job if there is a Printer MUST accept the request and suspend the current job if there is
current job in the 'processing' or 'processing-stopped' state; a current job in the 'processing' or 'processing-stopped' state;
otherwise, it MUST reject the request and return the 'client-error-not- otherwise, it MUST reject the request and return the 'client-error-not-
possible' status code. If more than one job is in the 'processing' or possible' status code. If more than one job is in the 'processing' or
'processing-stopped' states, all of them are paused. 'processing-stopped' states, all of them are suspended.
Warning: On a shared printer, there is a race condition. Between the Warning: On a shared printer, there is a race condition. Between the
time that a user issues this operation and its acceptance, the current time that a user issues this operation and its acceptance, the current
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
job might change to a different job. If the user or operator is job might change to a different job. If the user or operator is
authenticated to pause the new job, the wrong job is paused. To prevent authenticated to suspend the new job, the wrong job is suspended. To
this race from pausing the wrong job, the client MAY supply the "job-id" prevent this race from pausing the wrong job, the client MAY supply the
operation attribute which is checked against the current job's job-id. "job-id" operation attribute which is checked against the current job's
If the job identified by the "job-id" attribute is not the current job job-id. If the job identified by the "job-id" attribute is not the
on the Printer, i.e., is not in the 'processing' or 'processing-stopped' current job on the Printer, i.e., is not in the 'processing' or
states, the Printer MUST reject this operation and return the 'client- 'processing-stopped' states, the Printer MUST reject this operation and
error-not-possible' status code. Otherwise, the Printer pauses the return the 'client-error-not-possible' status code. Otherwise, the
specified job and processed other jobs. Printer suspends the specified job and processed other jobs.
A paused job is resumed using the Resume-Job operation (see section The Printer MUST reject a Resume-Job request (and return the 'client-
7.2.5). If the Pause-Current-Job operation is supported, then the error-not-possible') for a job that has been suspended , i.e., for a job
Resume-Job operation MUST be supported, and vice-versa. in the 'processing-stopped' state, with the 'job-suspended' value in its
"job-state-reasons" attribute.
The Printer MUST reject a Release-Job request (and return the 'client- Access Rights: The authenticated user (see [ipp-mod] section 8.3)
error-not-possible') for a job that has been paused , i.e., for a job in performing this operation must either be the job owner (as determined in
the 'processing-stopped' state, with the 'job-paused' value in its "job- the Job Creation operation) or an operator or administrator of the
state-reasons" attribute. The Hold-Job and Release-Job operations are Printer object (see [ipp-mod] Sections 1 and 8.5).
for holding and releasing held jobs, not pausing and resuming paused
jobs.
Access Rights: Authentication and access control (see [ipp-mod] sections Expires: January 6, 2001
1, 8.3, and 8.5) apply to this operation.
The Pause-Current-Job Request and Pause-Current-Job Response have the The Suspend-Current-Job Request and Suspend-Current-Job Response have
same attribute groups and attributes as the Resume-Printer operation the same attribute groups and attributes as the Pause-Printer operation
(see [ipp-mod] section 3.2.8 ), including the new "job-message-from- (see [ipp-mod] section 3.2.8 ), including the new "job-message-from-
operator" operation attribute (see section 3.2), the new "when" operator" operation attribute (see section 5), with the addition of the
operation attribute (see section 3.4), with the addition of the
following Group 1 Operation attributes in the request: following Group 1 Operation attributes in the request:
"job-id" (integer(1:MAX)): "job-id" (integer(1:MAX)):
The client OPTIONALLY supplies this Operation attribute in order to The client OPTIONALLY supplies this Operation attribute in order to
verify that the identified job is still the current job on the verify that the identified job is still the current job on the
target Printer object. The IPP object MUST supports this operation target Printer object. The IPP object MUST supports this operation
attribute, if it supports this operation. attribute, if it supports this operation.
"synchronize" (boolean) Resume-Job operation
The client OPTIONALLY supplies this attribute. The Printer object
OPTIONALLY supports this attribute. This attribute indicates
whether or not the printer is to synchronize the checkpoint data
for the current job being paused with the pages that have actually
printed. If this attribute is supported, then a value of 'true'
implies that the Printer will be able to resume the job at the
point of synchronization when the job is resumed.
If the Printer supports this attribute but the client does not
supply it, the Printer is assumed to perform synchronization
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
('true' behavior). If the Printer does not support this attribute,
the Printer is assumed to not synchronize ('false' behavior).
7.2.5 Resume-Job operation
This OPTIONAL operation allows a client to stop the target job and allow This OPTIONAL operation allows a client to resume the target job at the
other jobs to be processed instead. The Printer moves the target job to point where it was suspended. The Printer moves the target job to the
the 'pending' state and removes the 'job-paused' value from the job's 'pending' state and removes the 'job-suspended' value from the job's
"job-state-reasons" attribute. "job-state-reasons" attribute.
If the target job is not in the 'processing-stopped' state with the If the target job is not in the 'processing-stopped' state with the
'job-paused' value in the job's "job-state-reasons" attribute, the 'job-suspended' value in the job's "job-state-reasons" attribute, the
Printer rejects the request and returns the 'client-error-not-possible' Printer MUST reject the request and return the 'client-error-not-
status code, since the job was not paused. possible' status code, since the job was not suspended.
If the Resume-Job operation is supported, then the Pause-Current-Job
operation MUST be supported, and vice-versa.
Access Rights: Authentication and access control (see [ipp-mod] sections Access Rights: The authenticated user (see [ipp-mod] section 8.3)
1, 8.3, and 8.5) apply to this operation. performing this operation must either be the job owner (as determined in
the Job Creation operation) or an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).
The Resume-Job Request and Resume-Job Response have the same attribute The Resume-Job Request and Resume-Job Response have the same attribute
groups and attributes as the Release-Job operation (see [ipp-mod] groups and attributes as the Release-Job operation (see [ipp-mod]
section 3.3.6), including the new "job-message-from-operator" operation section 3.3.6), including the new "job-message-from-operator" operation
attribute (see section 3.2). attribute (see section 5).
7.2.6 Promote-Job operation Expires: January 6, 2001
12.4 Promote-Job operation
This OPTIONAL operation allows a client to make the pending target job This OPTIONAL operation allows a client to make the pending target job
be processed next after the current job completes. This operation is be processed next after the current job completes. This operation is
specially useful in a production printing environment where the operator specially useful in a production printing environment where the operator
is involved in job scheduling. is involved in job scheduling.
If the target job is in the 'pending' state, this operation does not If the target job is in the 'pending' state, this operation does not
change the job's state, but causes the job to be processed after the change the job's state, but causes the job to be processed after the
current job(s) complete. If the target job is not in the 'pending' current job(s) complete. If the target job is not in the 'pending'
state, the Printer rejects the request and returns the 'client-error- state, the Printer rejects the request and returns the 'client-error-
not-possible' status code. The Printer returns the target job not-possible' status code. The Printer returns the target job
immediately after the current job(s) in a Get-Jobs response (see [ipp- immediately after the current job(s) in a Get-Jobs response (see [ipp-
mod] section 3.2.6) for the 'not-completed' jobs. mod] section 3.2.6) for the 'not-completed' jobs.
When the current job completes, is canceled, paused, or aborted, the When the current job completes, is canceled, suspended, or aborted, the
target of this operation is processed next. target of this operation is processed next.
If a client issues this request (again) before the target of the If a client issues this request (again) before the target of the
operation of the original request started processing, the target of this operation of the original request started processing, the target of this
new request is scheduled before the previous job that was to be new request is scheduled before the previous job that was to be
processed next. processed next.
Expires: March 19, 2000 IPP is specified not to require queues for job scheduling, since there
are other implementation techniques for scheduling multiple jobs, such
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 as re-evaluating a criteria function for each job on a scheduling cycle.
However, if an implementation does implement queues for jobs, then the
Note: IPP is specified not to require queues for job scheduling, since Promote-Job puts the specified job at the front of the queue. A
there are other implementations for scheduling multiple jobs. However, subsequent Promote-Job before the first job starts processing puts that
if an implementation does implement queues for jobs, then the Promote- specified job at the front of the queue, so that it is "in front" of the
Job puts the specified job at the front of the queue. A subsequent
Promote-Job before the first job starts processing puts that specified
job at the front of the queue, so that it is "in front" of the
previously promoted job. previously promoted job.
Access Rights: Authentication and access control (see [ipp-mod] sections Access Rights: The authenticated user (see [ipp-mod] section 8.3)
1, 8.3, and 8.5) apply to this operation. performing this operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).
The Promote-Job Request and Promote-Job Response have the same attribute The Promote-Job Request and Promote-Job Response have the same attribute
groups and attributes as the Cancel-Job operation (see [ipp-mod] section groups and attributes as the Cancel-Job operation (see [ipp-mod] section
3.3.3), including the new "job-message-from-operator" operation 3.3.3), including the new "job-message-from-operator" operation
attribute (see section 3.2). attribute (see section 5).
7.2.7 Space-Current-Job operation 12.5 Redirect-Job operation
This OPTIONAL operation allows a client to repeat or skip a specified This OPTIONAL operation allows a client to redirect a not-completed job
number of impressions for the current job on the target Printer or the to another Printer on the same server. Redirect-Job is defined to be a
specified job if it is the current job on the Printer. The Printer Job Creation operation, along with the Print-Job, Print-URI, and Create-
repeats or skips the indicated number of impressions specified by the Job operations. Thus all semantics that apply to Job Creation
"back-space" or "forward-space" operation attribute, respectively. This operations also apply to this operation. For example, the new Printer
operation is typically supported in a continuous forms implementation validates the job using all of its "xxx-supported" attributes and either
for synchronizing the web after forms run out or media change. accepts or rejects the job. If the job is rejected, it remains in its
If the client does not supply a "job-id" operation attribute, the Expires: January 6, 2001
Printer MUST accept this request in any state, whether or not there is a
current job, and advance or backspace the media the indicated number of
impressions specified by the "back-space" or "forward-space" operation
attribute, respectively. If more than one job is in the 'processing' or
'processing-stopped' states, the one that is marking is spaced and the
others are unaffected.
It is reasonable, although not MANDATORY), to perform Space-Current-Job original state before the Redirect-Job operation was attempted. As an
while the Printer is 'stopped', paused, or 'processing'. Between the other example, the Job inherits the defaults for the new Printer (since
time that a user issues this operation and its acceptance, the current the defaults aren't copied onto the Job object when it is created, but
job might change to a different job. To prevent this race from spacing are applied when the job is processed - see [ipp-mod]). Finally, this
the wrong job, the client MAY supply the "job-id" operation attribute operation generates a 'job-created' event as does any Job Creation
which is checked against the current job's job-id. If the job Operation.
identified by the "job-id" attribute is not the current job on the
Printer, i.e., is not in the 'processing' or 'processing-stopped'
states, or is not the job that has impressions in the media path even if
the job has completed, the Printer MUST reject this operation and return
the 'client-error-not-possible' status code. Otherwise, the Printer
advances or backspaces the media the indicated number of impressions
specified by the "back-space" or "forward-space" operation attribute,
respectively.
Expires: March 19, 2000 In order to preserver the "ipp-attribute-fidelity" semantics that the
original client supplied when the job was first created, each Job
Creation Operation copies the "ipp-attributes-fidelity" (boolean)
operation attribute o the job as a Job Description attribute, if the
Redirect-Job operation is supported. Then the "ipp-attribute-fidelity"
attribute is re-used by the new Printer during its job validation,
unless the client performing the Redirect-Job operation supplies the
"ipp-attribute-fidelity" operation attribute.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 This operation is limited to redirecting a job to another Printer on the
same server. Thus the same copy of the job MAY be used, depending on
implementation. Also, depending on implementation, the new Printer MAY
generate a new job-id and job-uri, or use the same one. In either case
the response contains the "job-id" and "job-uri" for the redirected job
as for any Job Creation operation. If the new Printer does assign a new
"job-id" and "job-uri", then it MUST automatically update an Per-Job
Subscription objects that are associated with the job.
Access Rights: Authentication and access control (see [ipp-mod] sections The Printer MUST accept this operation whenever the job is in the
1, 8.3, and 8.5) apply to this operation. 'pending' or 'pending-held' states. The Printer MUST reject this
operation whenever the job is in the 'completed', 'aborted', or
'canceled' states and return the 'client-error-not-possible' status
code. Whether the Printer accepts this operation when the job is in the
'processing' or 'processing-stopped' states depends on implementation.
The Space-Current-Job Request and Space-Current-Job Response have the Access Rights: The authenticated user (see [ipp-mod] section 8.3)
same attribute groups and attributes as the Resume-Printer operation performing this operation must either be the job owner (as determined in
(see [ipp-mod] section 3.2.8), including the new "job-message-from- the Job Creation operation) or an operator or administrator of the
operator" operation attribute (see section 3.2), with the addition of Printer object (see [ipp-mod] Sections 1 and 8.5).
the following Group 1 Operation attributes in the request:
"job-id" (integer(1:MAX)): The Redirect-Job Request have the same attribute groups and attributes
as the Create-Job operation (see [ipp-mod] section 3.2.4), plus the new
"job-message-from-operator" operation attribute (see section 5). In
addition, the following operation attributes are defined:
The client OPTIONALLY supplies this Operation attribute in order to Target:
verify that the identified job is still the current job on the Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX))
target Printer object. The IPP object MUST supports this operation or (2) the "job-uri" (uri) operation attribute(s) which define the
attribute, if it supports this operation. target for this operation as described in [ipp-mod] section 3.1.5.
The client MUST supply this attribute and the Printer MUST support
it.
"back-space" (integer(1:MAX)): new-printer-uri (uri):
The URI of another Printer on the same server. The client MUST
supply this attribute and the Printer MUST support it.
The client OPTIONALLY supplies this Operation attribute. The IPP Expires: January 6, 2001
object OPTIONALLY supports this operation attribute, if it is able ipp-attribute-fidelity (boolean):
to repeat impressions. The client MAY supply this attribute, but the Printer MUST support
it. It indicates whether or not the Job Template attributes on the
Job object MUST be supported by the new Printer. If the client
omits this attribute, the new Printer uses the value copied to the
job as a Job Description attribute when the job was originally
created. The Job Description attribute is not affected by the
value supplied in this request, so that the original user's intent
is preserved across multiple Redirect-Job operations.
If the client supplies a value that specifies more impressions than The Redirect-Job Response has the same attribute groups, attributes, and
the job has performed, the job is positioned at the beginning status codes as the Create-Job operation (see [ipp-mod] section 3.2.4).
without any indication. The following status codes have particular meaning for this operation:
"forward-space" (integer(1:MAX)): 'client-error-not-possible' - the job was in the 'completed',
'aborted', or 'canceled' states or the implementation does not
support the Redirect-Job operation on a job when it is in the
'processing' or 'processing-stopped' states.
'client-error-not-found' - the target job was not found.
'client-error-attributes-or-values-not-supported' - the specified
Printer is not supported for redirection, i.e., the URI was not
amongst the Printer's "redirection-printers-supported" (1setOf
uri).
The client OPTIONALLY supplies this Operation attribute. The IPP 12.6 Schedule-Job-After operation
object OPTIONALLY supports this operation attribute, if it is able
to skip impressions.
If the client supplies a value that specifies more impressions than This OPTIONAL operation allows a client to request the Printer to
remain in the job, the job is positioned at the end without any schedule the target job so that it will be processed immediately after
indication. the specified job, all other scheduling factors being equal.
8. IANA Considerations IPP is specified not to require queues for job scheduling, since there
are other implementation techniques for scheduling multiple jobs, such
as re-evaluating a criteria function for each job on a scheduling cycle.
However, if an implementation does implement queues for jobs, then the
Schedule-Job-After operation puts the specified job immediately after
the specified job in the queue. A subsequent Schedule-Job-After
operation specifying the same job will cause its target job to be placed
after that job, even though it is between the first target job and the
specified job. For example, suppose the job queue consisted of jobs: A,
B, C, D, and E, in that order. A Schedule-Job-After with job E as the
target and B as the specified job would result in the following queue:
A, B, E, C, D. A subsequent Schedule-Job-After with Job D as the target
and B as the specified job would result in the following queue: A, B,
D, E, C. In other words, the link between the two jobs in a Schedule-
Job-After is ephemeral, rather than setting an attribute of either of
the jobs.
The operations and attributes in this registration proposal will be If the target job is not in the 'pending' state, the Printer MUST reject
published by IANA according to the procedures in RFC 2566 [rfc2566] the request and returns the 'client-error-not-possible' status code,
section 6.4 for operations with the following URL: since the job cannot have its position changed. The predecessor job can
be in the 'pending', 'processing', or 'processing-stopped' states.
ftp.isi.edu/iana/assignments/ipp/operations/set2.txt Expires: January 6, 2001
9. Internationalization Considerations Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).
This document has the same localization considerations as the [ipp-mod]. The Schedule-Job-After Request have the same attribute groups and
attributes as the Cancel-Job operation (see [ipp-mod] section 3.3.3),
plus the new "job-message-from-operator" operation attribute (see
section 5). In addition, the following operation attributes are
defined:
Expires: March 19, 2000 "predecessor-job-id":
The client OPTIONALLY supplies this attribute. The Printer MUST
support it, if it supports this operation. This attribute
specifies the job after which the target job is to be scheduled.
If the client omits this attribute, the Printer MUST schedule the
target job next, i.e., after the current job, if any.
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 The Schedule-Job-After Response has the same attribute groups,
attributes, and status codes as the Cancel-Job operation (see [ipp-mod]
section 3.3.3). The following status codes have particular meaning for
this operation:
10. Security Considerations 'client-error-not-possible' - the target job was not in the 'pending'
state or the predecessor job was no in the 'pending', 'processing',
or 'processing-stopped' states.
'client-error-not-found' - either the target job or the predecessor
job was not found.
The IPP Model and Semantics document [ipp-mod] discusses high level Expires: January 6, 2001
security requirements (Client Authentication, Server Authentication and
Operation Privacy). Client Authentication is the mechanism by which the
client proves its identity to the server in a secure manner. Server
Authentication is the mechanism by which the server proves its identity
to the client in a secure manner. Operation Privacy is defined as a
mechanism for protecting operations from eavesdropping.
11. Author's Addresses 13 Conformance Requirements
Carl Kugler The Job and Printer Administrative operations defined in this document
IBM are OPTIONAL operations. However, some operations MUST be implemented
Boulder CA if others are implemented as shown in Table 9.
Phone: (303) 924-5060 Table 9 - Conformance Requirement Dependencies for Operations
FAX:
e-mail: kugler@us.ibm.com
Tom Hastings Operations REQUIRED If any of these operations are supported:
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
Phone: 310-333-6413 Enable-Printer Disable-Printer
Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com
Harry Lewis Disable-Printer Enable-Printer
IBM
Boulder CA
Phone: (303) 924-5337 Pause-Printer Resume-Printer
FAX:
e-mail: harryl@us.ibm.com
12. References Resume-Printer Pause-Printer, Pause-Printer-After-Current-Job
[ipp-mod] Hold-New-Jobs Release-Held-New-Jobs
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
ipp-model-v11-03.txt>, June, 1999.
[RFC2566] Release-Held-New-Jobs Hold-New-Jobs
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April 1999.
Expires: March 19, 2000 Activate-Printer, Deactivate-Printer
Disable-Printer,
Pause-Printer-After-
Current-Job
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Deactivate-Printer, Activate-Printer
Enable-Printer,
Resume-Printer
13. Change History Restart-Printer none
This section summarizes the changes. Each sub-section is in reverse Shutdown-Printer none
chronological order.
13.1 Changes to the July 19, 1999 version to make the September 19, 1999 Startup-Printer none
version
The following changes to the July 19, 1999 version to make the September Reprocess-Job none
19, 1999 version as a result of the IPP WG meeting in Alaska, 8/99:
1.Refer to proposal as "Set2" rather than "Administrative" operations. Cancel-Current-Job none
2.Revise the emphasis on administrator throughout the document, Resume-Job Suspend-Current-Job
although the word administrator remains wherever appropriate.
3.Convert non-process-run-out from an operations attribute to an Suspend-Current-Job Resume-Job
operation.
4.Added Issue 21: For all these "access" caveats, why not just say... Promote-Job none
'authentication and access control (see ipp-mod sections 1, 8.3 and
8.5) applies to this operation".?
5.Added Issue 22: Why? This is backward, if you ask me (HRL). Table 10 and Table 11list the "printer-state-reasons" and "job-state-
reasons" values that are REQUIRED if the indicated operations are
supported.
6.Per resolution of Issue 2, the "settable-attributes" Printer Table 10- Conformance Requirement Dependencies for "printer-state-
Description attribute, was replaced with three Printer Description reasons" Values
attributes: "printer-settable-attributes", "job-settable-
attributes", and "interpreter-settable-attributes". The latter for
those implementations that have different values for Printer
attributes in the Get-Printer-Attributes and Set-Printer-Attributes
operations, depending on the value of the "document-format" operation
attribute supplied by the client. If and when we get a Document
object, then we can add a "document-settable-attributes" Printer
Description attribute.
7.Added the Interpreter object. "printer-state- Conforman If any of the following Printer
reasons" values: ce Operations are supported:
Requireme
nt
13.2 Changes to the June 30, 1999 version to make the July 19, 1999 'paused' REQUIRED Pause-Printer, Pause-Printer-After-
version Current-Job, or Deactivate-Printer
The following changes to the June 30, 1999 version to make the July 19, 'hold-new-jobs' REQUIRED Hold-New-Jobs
1999 version as a result of the IPP WG meeting in Copenhagen, 7/7/99-
7/8/99, and the IPP telecon, 7/14/1999:
1.Sections 2.1 and 2.2: Clarified that the way to remove a message 'moving-to-paused' OPTIONAL Pause-Printer, Pause-Printer-After-
from the operator was for the client to supply a zero-length or all
Expires: March 19, 2000 Expires: January 6, 2001
Current-Job, Deactivate-Printer
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 'deactivated' REQUIED Deactivate-Printer
white space text string which is copied as usual to the "xxx-message- Table 11- Conformance Requirement Dependencies for "job-state-reasons"
from-operator" attribute. Values
2.Section 2.3: Added "factory-settings" (boolean) operation attribute "job-state-reasons" Conforman If any of the following Job operations
to the Get-Printer-Attributes operation. values: ce are supported:
Requireme
nt
3.Section 2.4: Added the "when" operation attribute to the Pause- 'job-suspended' REQUIRED Suspend-Current-Job
Current-Job operation.
4.Section 2.4: Made the "when" operation attribute OPTIONAL for use 'printer-stopped' REQUIRED always REQUIRED
in operations (Pause-Printer, Reset-Printer, Shutdown-Printer, and
Pause-Current-Job operations).
5.Sections 2.5: Added table of operation attributes for the Printer 14 IANA Considerations
operations to make it easy to compare.
6.Sections 2.6: Added table of operation attributes for the Job The operations and attributes in this registration proposal will be
operations to make it easy to compare. published by IANA according to the procedures in RFC 2566 [rfc2566]
section 6.4 for operations with the following URL:
7.Section 3.1: Added "settable-attributes" (1setOf type2 keyword) ftp.isi.edu/iana/assignments/ipp/operations/ipp-admin-ops.txt
READ-ONLY Printer Description attribute.
8.Section 3.2: Added "printer-controls-other-protocols" (boolean) 15 Internationalization Considerations
Printer Description attribute
9.Section 3.3: Added the READ-ONLY "printer-message-time" This document has the same localization considerations as the [ipp-mod].
(integer(MIN:MAX)) Printer Description attribute to keep time message
updated in time ticks.
10. Section 4.2: Deleted the 'process-next' "job-state-reasons" value, 16 Security Considerations
so that repeated Promote-Job operations promote each job "to the
front of the queue".
11. Sections 6.1.1.1 and 6.2.1.1: Replaced the table that listed all The IPP Model and Semantics document [ipp-mod] discusses high level
attributes with one that lists only the attributes that MUST be READ- security requirements (Client Authentication, Server Authentication and
ONLY. Operation Privacy). Client Authentication is the mechanism by which the
client proves its identity to the server in a secure manner. Server
Authentication is the mechanism by which the server proves its identity
to the client in a secure manner. Operation Privacy is defined as a
mechanism for protecting operations from eavesdropping.
12. Section 6.1.1.1: Indicated that attributes that are not specified 17 Author's Addresses
as READ-ONLY in this document MAY be settable. If they control
behavior, that changing their values MUST change the behavior.
13. Section 6.1.1.2 and 6.2.1.2: Deleted the "ipp-attribute-fidelity" Carl Kugler
operation attribute from the Set-Printer-Attributes and Set-Job- IBM
Attributes operations. All set operations are atomic. Boulder CO
14. Section 6.1.1.2: Add the concept of the Interpreter object to Phone: (303) 924-5060
handle attributes whose values vary in the Set-Printer-Attributes and FAX:
Get-Printer-Attributes, depending on the value of the "document- e-mail: kugler@us.ibm.com
format" operation attribute.
Expires: March 19, 2000 Tom Hastings
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999 Expires: January 6, 2001
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
15. Sections 6.1.1.3 and 6.2.1.2: Changed the "out-of-band" 'not- Phone: 310-333-6413
settable' value back to the existing 'not-supported' value. Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com
16. Section 6.1.2 and 6.1.3: Added "job-type" operation attribute to Harry Lewis
Disable-Printer and Enable-Printer operations with values: 'network- IBM
jobs', 'walk-up-jobs', and 'all-jobs'. Boulder CO
17. Section 6.1.5: Clarified that Restart-Printer brings up the Phone: (303) 924-5337
Printer disabled and paused, since that is the eventual state that FAX:
Shutdown-Printer leaves the printer in. e-mail: harryl@us.ibm.com
18. Section 6.1.5: Indicated that if Restart-Printer is supported, 18 References
then Shutdown-Printer MUST be supported.
19. Section 6.1.6: Deleted Space-Printer operation. Keep Space- [ipp-device-ops]
Current-Job operation only which has a "job-id" operation attribute Kugler, C., Hastings, T., Lewis, H., "Internet Printing Protocol
that a client MAY supply. (IPP): Device Administrative Operations", <draft-ietf-ipp-ops-set3-
00.txt>, December 8, 1999.
20. Section 6.1.6: Clarified that Shutdown-Printer is for a long [ipp-iig]
period of time, not just to reset the device or change attribute Hastings, T., Manros, C., "Internet Printing Protocol/1.1: draft-
values. Also that Shutdown performs an immediate Disable-Printer and ietf-ipp-implementers-guide-v11-01.txt, work in progress, May 9,
an eventual Pause-Printer. 2000.
21. Sections 6.2.3, 6.2.4, and 6.2.7 : Added a "job-id" operation [ipp-mod]
attribute to Cancel-Current-Job, Pause-Current-Job, and Space- R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
Current-Job that a client MAY supply to check for race condition "Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
where current job changes ipp-model-v11-07.txt>, May 22, 2000.
22. Section 6.2.4: Combined Pause-Job into Pause-Current-Job [ipp-pro]
operation. Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
06.txt, May 30, 2000.
23. Sections 6.2.4 and 6.2.5: Pause-Current-Job puts job in [RFC2566]
'processing-stopped' state, not 'pending-held' state. R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April 1999.
24. Section 6.2.6: Simplified Promote-Job, so that it behaves as if Expires: January 6, 2001
the job were put at the front of the queue.
14. Appendix A: Full Copyright Statement 19 Appendix A: Full Copyright Statement
Copyright (C) The Internet Society (1998,1999). All Rights Reserved Copyright (C) The Internet Society (1998,1999). All Rights Reserved
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
Expires: March 19, 2000
PWG-DRAFT IPP/1.1: Set 2 Operations September 19, 1999
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
Expires: March 19, 2000 Expires: January 6, 2001
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/