INTERNET-DRAFT                                               Carl Kugler
<draft-ietf-ipp-ops-set2-00.txt>
<draft-ietf-ipp-ops-set2-01.txt>                         IBM Corporation
                                                             T. Hastings
                                                       Xerox Corporation
                                                                H. Lewis
                                                         IBM Corporation
                                                      September 19, 1999
                                                            July 6, 2000
                   Internet Printing Protocol/1.1: Set2 Protocol (IPP):
               Job and Printer Administrative Operations

    Copyright (C) The Internet Society (2000). All Rights Reserved.

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. [rfc2026].  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html.

                                Abstract

This document specifies 14 the following 16 additional OPTIONAL operations
for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566]
and IPP/1.1 [ipp-mod, ipp-pro].  These operations are 7 Printer object operations
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 operations:                Job object operations that end-users may perform on their jobs operations:
Enable-Printer and
operators/administrators may perform on any job, depending on
circumstances:

     Set-Job-Attributes Disable-Printer Reprocess-Job
Pause-Printer-After-Current-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)
Hold-New-Jobs and Release-Held-    Suspend-Current-Job and Resume-Job
New-Jobs
Deactivate-Printer and Activate-   Promote-Job
     Space-Current-Job  (though the target is the
Printer object)

In addition, two operation attributes are defined:  "printer-message-
from-operator"
Restart-Printer                    Redirect-Job
Shutdown-Printer and "job-message-from-operator" are included to set the
corresponding Startup-      Schedule-Job-After
Printer

New Printer and Job Description attributes with the same
names.  And the "when" operation attributes: "subordinate-printers-supported",
"parent-printers-supported", and "redirection-printers-supported".
New "printer-state-reasons" values: 'hold-new-jobs' and 'deactivated'.
New "job-state-reasons" attribute is added to the IPP/1.1
Pause-Printer operation.

Finally, new values:  'job-suspended'.
New 'forwarded-operation-failed' event code.
New status codes: 'client-error-attributes-not-settable' and
'server-error-printer-is-in-standby-mode' are added. code:  'server-error-printer-is-deactivated'.

                      Expires:  January 6, 2001

The scope of IPP, is characterized in RFC2526 "Design Goals for an
Internet Printing Protocol".  It is not the intent of this document to
revise or clarify this scope or conjecture as to the degree of industry
adoption or trends related to IPP within printing systems.  It is the
intent of this document to extend the original set of operations - in a
similar fashion to the Set1 extensions which referred to IPP/1.0 and
were later incorporated into IPP/1.1.

This document is intended for registration following the registration
procedures of IPP/1.0 [RFC2566] and IPP/1.1 [ipp-mod].  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:
  Design Goals for an Internet Printing Protocol [RFC2567]
  Rationale for the Structure and Model and Protocol for the Internet
     Printing Protocol [RFC2568]
  Internet Printing Protocol/1.1: Model and Semantics (this document) [IPP-MOD]
  Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
  Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
  Mapping between LPD and IPP Protocols [RFC2569]

The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet.  It identifies
requirements for three types of users: end users, operators, and
administrators.  It calls out a subset of end user requirements that are
satisfied in IPP/1.0.  A few OPTIONAL operator operations have been
added to IPP/1.1.

The "Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol" document describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of IPP
specification documents, and gives background and rationale for the IETF
working group's major decisions.

The "Internet Printing Protocol/1.1: Encoding and Transport" document is
a formal mapping of the abstract operations and attributes defined in
the model document onto HTTP/1.1 [RFC2616].  It defines the encoding
rules for a new Internet MIME media type called "application/ipp".  This
document also defines the rules for transporting over HTTP a message
body whose Content-Type is "application/ipp".  This document defines a
new scheme named 'ipp' for identifying IPP printers and jobs.

The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
insight and advice to implementers of IPP clients and IPP objects.  It
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
IPP object implementations.  For example, a typical order of processing
requests is given, including error checking.  Motivation for some of the
specification decisions is also included.

The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.

                      Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999  January 6, 2001
                           Table of Contents

1.

1  Introduction.....................................................6

2. New objects......................................................6

2  Terminology......................................................6
 2.1 Interpreter object............................................6

3. New Operation attributes.........................................6 Conformance Terminology.......................................6
 2.2 Other terminology.............................................6

3  Requirements and Use Cases.......................................7
 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 List of the operation attributes for the Printer operations13
 3.7 Summary and Device Operations....................11

4  Use of the operation attributes for the Job operations...13

4. New Printer Description Attributes..............................15 object to represent IPP Printer fan-out and IPP
Printer fan-in.....................................................11
 4.1 printer-settable-attributes (1setOf type2 keyword)...........15 IPP Printer Fan-Out..........................................12
 4.2 interpreter-settable-attributes (1setOf type2 keyword).......15 IPP Printer Fan-In...........................................12
 4.3 job-settable-attributes (1setOf type2 keyword)...............16 Printer object attributes used to represent Printer fan-out and
 Printer fan-in....................................................13
 4.4 printer-controls-other-protocols (boolean)...................16 Subordinate Printer URI......................................13
 4.5 printer-message-time (integer(MIN:MAX))......................18 Printer object attributes used to represent Output Device Fan-Out
     .............................................................14
 4.6 printer-message-date-time (dateTime).........................19 Figures to show all possible configurations..................15
 4.7 printer-message-operation (type2 keyword)....................19
 4.8 when-values-supported Forwarding requests..........................................17
  4.7.1  Forwarding requests that affect Printer objects..........17
  4.7.2  Forwarding requests that affect Jobs.....................18

5  New Operation attributes........................................20

6  New Printer Description Attributes..............................21
 6.1 subordinate-printers-supported (1setOf uri)..................22
 6.2 parent-printers-supported (1setOf type2 keyword).................20
 4.9 device-names-supported uri).......................22
 6.3 redirection-printers-supported (1setOf name(127))....................21

5. uri)..................22

7  Additional values Values for "printer-state-reasons" and "job-state-reasons"
attributes.........................................................21
 5.1 Value for "printer-state-reasons":  'standby'................21
 5.2 Value for "job-state-reasons":  'job-paused'.................22

6. New status codes................................................22
 6.1 New status code: 'client-error-attributes-not-settable'......22
 6.2 New "printer-state-reasons"...................22
 7.1 'hold-new-jobs'..............................................23
 7.2 'deactivated'................................................23

8  Additional Values for "job-state-reasons".......................23
 8.1 'job-suspended'..............................................23

9  Additional events...............................................23

10 Additional status code: 'server-error-printer-is-in-standby-mode'...23

7. Summary codes........................................23
 10.1'server-error-printer-is-deactivated' (0x????)...............24

11 Definition of Set 2 operations the Printer Operations...........................24
 11.1The Disable and Operation-Id Assignments........23
 7.1 Enable Printer Operations...........................................24
  7.1.1  Set-Printer-Attributes Operation.........................24
  7.1.2 Operations....................26
  11.1.1 Disable-Printer Operation................................29
  7.1.3 Operation................................26
  11.1.2 Enable-Printer Operation.................................30
  7.1.4  Reset-Printer operation..................................31
  7.1.5 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

                      Expires:  January 6, 2001
 11.4Deactivate and Activate Printer Operations...................31
  11.4.1 Deactivate-Printer operation.............................31
  11.4.2 Activate-Printer operation...............................32
 11.5Restart-Printer, Shutdown-Printer, and Startup-Printer operations
     .............................................................32
  11.5.1 Restart-Printer operation................................32
  7.1.6  Non-Process-Run-Out Operation............................33

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

  7.1.7 operation................................33
  11.5.2 Shutdown-Printer Operation...............................34
 7.2
  11.5.3 Startup-Printer operation................................34

12 Definition of the Job Operations...............................................36
  7.2.1  Set-Job-Attributes.......................................36
  7.2.2  Reprocess-Job Operation..................................40
  7.2.3  Cancel-Current-Job Operation.............................40
  7.2.4  Pause-Current-Job operation..............................41
  7.2.5 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.....................................43
  7.2.6  Promote-Job operation....................................43
  7.2.7  Space-Current-Job operation..............................44

8. operation.....................................40
 12.4Promote-Job operation........................................41
 12.5Redirect-Job operation.......................................41
 12.6Schedule-Job-After operation.................................43

13 Conformance Requirements.......................................45

14 IANA Considerations.............................................45

9. Considerations............................................46

15 Internationalization Considerations.............................45

10.Security Considerations............................46

16 Security Considerations........................................46

11.Author's

17 Author's Addresses.............................................46

12.References.....................................................46

13.Change History.................................................47
 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

18 References.....................................................47

19 Appendix A: Full Copyright Statement...........................49

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Statement...........................48

                             List of Tables
Table 1 - List of Printer Operations and corresponding Device Operations      September 19, 1999

1.
    .................................................................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

                            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
that can be used for distributed printing using Internet tools and
technologies.  IPP version 1.1 (IPP/1.1) ([ipp-mod, ipp-pro]) focuses only on end user
functionality with a few administrative operations included.  This
document defines additional OPTIONAL end user, operation, operator, and
administrator operations used to control Jobs and Printers.  This
document is a registration proposal for an extension to IPP/1.0 and
IPP/1.1 following the registration procedures in those documents.

2. New objects

2  Terminology

This section defines the new Interpreter object. terminology used throughout this document.

2.1 Interpreter object

The Interpreter object models the document format interpreters that Conformance Terminology

Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
MAY, NEED NOT, and OPTIONAL, have special meaning relating to
conformance.  These terms are
contained defined in the Printer object.  Depending on implementation, the
Printer object attributes whose values depend on the interpreter, i.e., [ipp-mod] section 12.1 on the "document-format"
conformance terminology, most 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 which is taken from RFC 2119 [RFC2119].

The following specialization of these terms apply to this document:

  REQUIRED: if an implementation supports the "document-format" attribute supplied by the client extensions described in the Get-
Printer-Attributes request (or the "document-format-default",
     this document, it MUST support a REQUIRED feature.
  OPTIONAL: if an implementation supports 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 extensions described in [ipp-mod] section 3.2.5.1 Get-Printer-Attributes
request).  The protocol
     this document, it MAY support an OPTIONAL feature.

2.2 Other terminology

This document uses terms such as "attributes", "keywords", and
"support".  These terms have special meaning and semantics are defined in the same whether or not the
Interpreter object is used to distinguish attributes that depend on the
"document-format".

3. New Operation attributes

This
model terminology [ipp-mod] section defines the new "printer-message-from-operation" and "job-
message-from-operator" operation attributes that set 12.2.  In addition, the corresponding following
capitalized terms are defined.

  IPP Printer and Job Description attributes.

3.1 New operation attribute:  "printer-message-from-operator"
(text(127))

Type of registration:  attribute

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

Proposed keyword name of this attribute:  "printer-message-from-
operator"
Types of attribute (Operation, Job Template, Job Description, object (or Printer for short) - a software abstraction
     defined by [ipp-mod].

  Printer
Description): Operation
Operations to be used with if the attribute is - an operation attribute:
See below
Object (Job, Printer, etc. if bound to whose target is an object): IPP Printer (already in
IPP/1.0 and IPP/1.1)
Attribute syntax(es) (include 1setOf
     object and range as in Section 4.2):
text(127)

Specification of this attribute (follow whose effect is on the style of Printer object.

  Output Device - the physical imaging mechanism that an IPP Model Section
4.2):

"printer-message-from-operator" (text(127))
     The client OPTIONALLY supplies this attribute.  The Printer object
     SHOULD supports
     controls.  Note: while this term is capitalized in this
     specification (but not in [ipp-mod]), there is no formal object
     called an Output Device.

  Device Operation - an operation attribute if it supports the
     corresponding whose target is an IPP Printer Description attribute.  The value of this
     attribute object
     and whose defined effect is on an Output Device.

  Output Device Fan-Out - a message from the operator about the configuration in which an IPP Printer
     controls more that one output-device.

  Printer fan-out - a configuration in which an IPP Printer object
     on
     controls more than one Subordinate IPP Printer object.

                      Expires:  January 6, 2001
  Printer fan-in - a configuration in which the operator an IPP Printer object is performing the operation.  If supported,
     controlled by more than one IPP Printer object.

  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.

  Leaf Printer - a Subordinate Printer that has no Subordinate
     Printers.

  Non-Leaf Printer - an IPP Printer object that has one or more
     Subordinate Printers.

  Chained Printer - a Non-Leaf Printer that has exactly one Subordinate
     Printer.

  Job Creation operations - IPP operations that create a Job object:
     Print-Job, Print-URI, and Create-Job.

3  Requirements and Use Cases

The following requirements and usage cover both the "Job and Printer copies
Administrative Operations" (this document)and the value "Device Administrative
Operations" (see [ipp-device-ops]).  The requirements are presented here
together to show the Printer's "printer-message-
     from-operator" Printer Description attribute (see [ipp-mod] section
     4.4.25), automatically sets parallelism.

1.Have separate operations for affecting the value of IPP Printer versus
  affecting the Printer's "printer-
     message-time" with Output Device, so its clear what the current value intent of each is
  and implementers can implement one or the Printer's "printer-up-
     time" attribute, the value other or both.

2.Support fan-out of the "printer-message-date-time" with
     the current value Printer objects.

3.Support fan-out of the Printer's printer-current-date-time"
     attribute, and the value Output Devices.

4.Support fan-in of Printer objects, as long as it doesn't make the Printer's "printer-message-
     operation" with
  semantics more complicated when not supporting fan-in.

5.Support fan-in of output objects, as long as it doesn't make the operation-id value
  semantics more complicated when not supporting fan-in.

6.Instead of this having operation (see [ipp-
     mod] section 4.4.15).

     If attributes that alter the behavior of the
  operation significantly, have separate operations, so that it is
  simple and clear to a client omits this attribute, which semantics the Printer does not change is
  supporting (by querying the
     value of its "printer-message-from-operator", "printer-message-
     time", "printer-message-date-time", "operations-supported" attribute) and "printer-message-operation" it
  is simple to describe the capabilities of a Printer Description attributes.

     If implementation in
  written documentation (just list the client supplies this attribute with OPTIONAL operations supported).

7.Need a zero-length text value
     or with Printer Operation to prevent a value consisting solely of white space, Printer object from accepting
  new IPP jobs, but currently accepted jobs continue unaffected to be
  scheduled and processed.  Need a companion one to restore the Printer
     copies that value as any other value
  object to accept new IPP jobs.

  Usage:  Operator is preparing to take the Printer's "printer-
     message-from-operator" and sets IPP Printer out of service
  or to change the configuration of the "printer-message-time",
     "printer-message-date-time", IPP  Printer.

  Suggested name and "printer-message-operation"
     attributes.  Supplying such operations:  Disable-Printer and Enable-Printer

                      Expires:  January 6, 2001

8.Need a value is the way that Device Operation to prevent an Output Device from accepting
  any new jobs from any job submission protocol and a companion one to
  restore the operator
     indicates that there Output Device to accepting any jobs.

  Usage:  Operator is no longer preparing to take the Output Device out of
  service.

  Suggested name and operations:  Disable-Device and Enable Device

9.Need a printer message from Printer Operation to stop the
     operator (rather than using processing after the "out-of-band" 'no-value' value).

This operation attribute is defined for use with current IPP
  job completes and not start processing any additional IPP jobs
  (either by scheduling the following operator
operations on jobs or sending them to the Printer object:

     Pause-Printer - see [ipp-mod] section 3.2.7
     Resume-Printer - see [ipp-mod] section 3.2.8
     Purge-Jobs - see [ipp-mod] section 3.2.9
     Disable-Printer - see section 7.1.2

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

     Enable-Printer - see section 7.1.3
     Reset-Printer - see section 7.1.4
     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
supported as an Output Device),
  but continue to accept new IPP jobs.  Need a companion operation attribute for the Set-Printer-Attributes
operation.  If the operator to
  start processing/sending IPP jobs again.

  Usage:  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 gracefully stop the IPP Printer Description
attributes in Group 2 in at the request. next
  job boundary. The Printer Pause-Printer-After-Current-Job operation is also updates
  invoked implicitly by the
Printer's "printer-message-date-time" Deactivate-Printer and "printer-message-operation"
Printer Description attributes.  If the client does not explicitly
supply Shutdown-Printer
  Operations.

  Suggested name and operations:  Pause-Printer-After-Current-Job,
  (IPP/1.1) Resume-Printer

10.  Need a Device Operation to stop the "printer-message-from-operator" with its new value, processing the
Printer leaves current job
  "immediately", no matter what protocol.  Its like the value of Pause button on
  the Printer's "printer-message-from-
operator" Printer Description attribute unchanged.

3.2 New Output Device.  This operation attribute:  "job-message-from-operator" (text(127))

Type of registration:  attribute
Proposed keyword name is for emergencies.  The stop
  point depends on implementation, but can be mid page, end of this attribute:  "job-message-from-operator"
Types page,
  end of attribute (Operation, Job Template, Job Description, Printer
Description):  Operation
Operations sheet, or after a few sheets for Output Devices that can't
  stop that quickly.  The paper path isn't run out.  Need a companion
  operation to be used with if start processing the attribute current any-protocol job without
  losing any thing.

  Usage:  Operator sees something bad about to happen, such as the
  paper is an operation attribute:
See below
Object (Job, Printer, etc. if bound about to an object):   Job (already in
IPP/1.0 and IPP/1.1)
Attribute syntax(es) (include 1setOf jam, or the toner is running out, or the device is
  overheating or wants to add more paper.

  Suggested name and range as in Section 4.2):
text(127)

Specification of this attribute (follow operations:  Pause-Device-Now, Resume-Device

11.  Need a Printer Operation to stop the style processing of IPP Model Section
4.2):

"job-message-from-operator" (text(127))
     The client OPTIONALLY supplies this attribute.  The Printer object
     SHOULD supports this operation attribute if it supports the
     corresponding Job Description attribute.  The value jobs after
  all of this
     attribute is a message from the currently accepted jobs have been processed, but any newly
  accepted jobs go into the 'processing-held' state.

  Usage:  This allows an operator about to reconfigure the Job object on
     which Output Device in
  order to let jobs that are held waiting for resources, such as
  special media, to get a chance.  Then the operator has just performed an operation.  If supported,
     the Printer copies uses another
  operation after reconfiguring.  He repeats the value two operations to
  restore the Job's "job-message-from-
     operator" Job Description attribute (see [ipp-mod] section 4.3.16).

     If Output Device to its normal media.

  Suggested name and operations:  Hold-New-Jobs, Release-Held-New-Jobs

12.  Need a Device Operation to stop the client omits this attribute, processing the Printer does not change current any-
  protocol job at a convenient point, such as after the
     value current copy
  (or end of its "printer-message-from-operator" Job Description
     attribute.

     If the client supplies this attribute with a zero-length text value job if last or with only copy).  Need a value consisting solely of white space, the Printer companion operation to

                      Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

     copies that value as  January 6, 2001
  start processing the current any-protocol job or next job without
  losing any other value thing.

  Usage:  The operator wants to empty the job's "job-message-
     from-operator".  Supplying such a value output bin that is the way near full.
  The paper path is run out.

  Suggested name and operations:  Pause-Device-After-Current-Copy,
  Resume-Device

13.  Need a Device Operation that always pauses on a device-defined
  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.

  Usage:  The operator indicates wants to empty the output bin that there is no longer near full,
  but he doesn't want to break up 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-
     date-time", in case it has multiple copies.
  The paper path is run out.

  Suggested name and "job-message-operation" Job Description attributes,
     since the usual lifetime of operations:  Pause-Device-After-Current-Job,
  Resume-Device

14.  Need a job is limited.

This operation attribute is defined for use with the following operator
operations on the Printer Operation that combines Disable-Printer, Pause-
  Printer-After-Current-Job, and rejects all other Job, Printer, and
  Device Operations, except Job object:

     Cancel-Job - see [ipp-mod] section 3.2.4
     Hold-Job - see [ipp-mod] section 3.3.5
     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" and Printer queries, System
  Administrator Set-Printer-Attributes, and the companion operation attribute MUST NOT be
supported as an to
  resume activity.  In other words, this operation attribute for makes the Set-Job-Attributes
operation.  If Printer a
  read-only object in a graceful manner for end-users and the operator operator.

  Usage:  The administrator wants to set the Job's "job-message-from-
operator" Job Description attribute when issuing the Set-Job-Attributes
operation, reconfigure the client supplies Printer object
  using the "job-message-from-operator" with its
new value as one of Set-Printer-Attributes operation without disturbing the Job Description attributes in Group 2
  current in process work, but wants to make sure that the
request.  Otherwise, operator
  isn't also trying to change the Printer leaves the value object as part of running 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-
settings" (boolean)

Type of registration:  attribute
Proposed keyword
  Printer.

  Suggested name of this attribute:  "factory-settings"
Types of attribute (Operation, Job Template, and operation:  Deactivate-Printer, Activate-Printer

15.  Need a Device Operation that combines Disable-Device, Pause-Device-
  After-Current-Job, and rejects all other Device Operations, except
  Job Description, and Printer
Description):  Operation
Operations to be used with if queries and the attribute is an companion 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 resume
  activity.  In other words, this attribute (follow operation makes the style of IPP Model Section
4.2):

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

  "factory-settings" (boolean)
     The client OPTIONALLY supplies this attribute.  The Printer Output Device a
  read-only object
     OPTIONALLY supports this attribute, if it supports in a graceful manner.

  Usage:  The field service person wants to open up the Set-Printer-
     Attributes operation.  If device without
  disturbing the client omits this attribute current in process work, perhaps to replace staples,
  or
     supplies the 'false' value, replace the toner cartridge.

  Suggested name and operation:  Deactivate-Device, Activate-Device

16.  Need a Printer returns Operation to recover from the current values IPP Printer software
  that has gotten confused (run out of the requested attributes heap memory or gotten into a
  state that are settable, i.e., the values it doesn't seem to be able to get out of).  This is a
  condition that have been set by previous Set-Printer-Attributes.  If the
     client supplies shouldn't happen, but does in real life.  Any volatile
  information is saved if possible before the 'true' value, software is re-

                      Expires:  January 6, 2001
  initialized.  No companion operation is needed to undo this.  We
  don't want to go back to the "confused" state :-).

  Usage:  The IPP Printer returns the factory
     settings, i.e., the inherent values supported by the implementation
     as shipped from the manufacturer software has gotten confused or established at install time.
     This operation attribute allows an operator isn't
  responding properly.

  Suggested name and operation:  Restart-Printer

17.  Need a Device Operation to determine which
     values are supported in an implementation after having modified recover from the Output Device hardware
  and software that has gotten confused (gotten into a
     settable attribute.  Attributes state that are not settable are not
     affected by this operation attribute, so it
  doesn't seem to be able to get out of, run out of heap memory, etc.).
  This is a condition that shouldn't happen, but does in real life.
  This is the Printer returns same and has the same values for non-settable attribute when either options as the 'true'
     or 'false' value has been supplied.  If this Printer MIB reset.
  No companion operation attribute is
     supported, both values MUST be supported.

3.4 New operation attribute for Pause-Printer:  "when" (type2 keyword)

Type of registration:  attribute
Proposed keyword name of this attribute:  "when"
Types of attribute (Operation, Job Template, Job Description, Printer
Description):  Operation
Operations needed to undo this.  We don't want to go
  back to be used with if the attribute is an operation attribute:
Pause-Printer, Reset-Printer, Non-Process-Run-Out, Shutdown-Printer, and
Pause-Current-Job
Object (Job, Printer, etc. if bound "confused" state :-).

  Usage:  The Output Device has gotten confused or need resetting to an object):   N/A
Attribute syntax(es) (include 1setOf
  some initial conditions.

  Suggested name and range as in Section 4.2):
type2 keyword

Specification of this attribute (follow operation:  Reset-Device

18.  Need a Printer Operation to put the style of IPP Model Section
4.2):
  "when" (type2 keyword)
     The client OPTIONALLY supplies this attribute.  The Printer object
     OPTIONALLY supports this attribute, if it supports this operation.
     The value out of this attribute indicates when to pause, reset, or
     shutdown the printer.  If
  business with no way in the client omits this attribute, 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.

  Usage:  The Printer assumes is being moved or the 'after-current-job' value.  The 'after-current-
     job' value building's power is REQUIRED being
  shut off.

  Suggested name and operation:  Shutdown-Printer

19.  Need a Printer Operation to be supported if bring an IPP Printer to life when there
  is an already running host.

  Usage:  After the "when" attribute host is
     supported; started (by means outside the remaining values are OPTIONAL.
ISSUE 1: Can a client determine IPP
  protocol), the values operator is able to ask the host to bring up any
  number of "when" that are supported
for operations (Pause-Printer, Reset-Printer, Shutdown-Printer, Printer objects (that the host has been configured in some
  way) each with distinct URLs.

  Suggested name and
Pause-Current-Job)?
  TH> Just add operation:  Startup-Printer

20.  Need a "when-values-supported" that applies Device Operation to all of power off the
  four Output Device after
  writing out any software state.  It is assumed that other operations supported, with the exception of Pause-Current-Job.
  For Pause-Current-Job, only the 'now' and 'after-current-copy'
  have
  any meaning, so more gracefully prepared the other two values ('after-current-job' Output Device for this drastic and
  'after-all') don't apply.

  HRL> Or, "just say NO". The client can't determine
  immediate.  There is no companion Device Operation to bring the values of

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

  "when" supported. power
  back on.

  Usage:  The client may specify a value of when and the
  implementation will do it's best to deliver as close Output Device is going to be moved, the desired
  behavior as possible within power in the constraints of
  building is going to be shutoff, the device or
  environment. The client may determine the actual result based on
  final status and/or notification feedback.

     Standard keyword values are:
          'now' - cancel repair man has arrived and needs
  to take the currently printing job(s) Output Device apart.

  Suggested name and shutdown operation:  Power-Off-Device

                      Expires:  January 6, 2001

21.  Need a Device Operation to startup a powered-off device.

  Usage:  After a Power-Off-Device, if the
              Printer.  Jobs in device can be powered back
  up (possibly by an intervening host that supports the 'held' Device
  Operation).

  Suggest name and 'pending' state remain
              in those states.
          'after-current-copy' - shutdown operation:  Power-On-Device

3.1 List of 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 Device Operations

The list of Printer after the current
              job finishes printing (all its copies).  Jobs in the
              'held' and 'pending' state remain the corresponding Device Operations is shown in those states.
          'after-all'
Table 1:

Table 1 - shutdown the List of 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 Operations and corresponding Device Operations

     Printer operation:
"device-name" (name(127))

Type of registration:  attribute
Proposed keyword name of this attribute:  "device-name"
Types of attribute (Operation, Job Template, Operation            Corresponding Device Operation
                                  equivalent
                                  (see [ipp-device-ops])

     Disable-Printer              Disable-Device

     Enable-Printer               Enable-Device

     Pause-Printer (IPP/1.1 -     Pause-Device-Now
     [ipp-mod] - one
     interpretation)

     no                           Pause-Device-After-Current-Copy

     Pause-Printer-After-Current- Pause-Device-After-Current-Job
     Job Description,

     Resume-Printer (IPP/1.1 -    Resume-Device
     [ipp-mod])

     Hold-New-Jobs                no

     Release-Held-New-Jobs        no

     Deactivate-Printer           Deactivate-Device

     Activate-Printer             Activate-Device

     Purge-Jobs (IPP/1.1 - [ipp-  Purge-Device
     mod])

     Restart-Printer              Reset-Device

     Shutdown-Printer             Power-Off-Device

     Startup-Printer              Power-On-Device

There are no conformance dependencies between Printer
Description):  Operation Operations to and
Device Operations.  Either MAY be used with if supported without supporting 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
corresponding operations.

4  Use of this attribute (follow the style of IPP Model Section
4.2):
  "device-name" (name(127))
     This OPTIONAL Printer operation attribute contains the name of a
     device which is associated with this object to represent IPP Printer object.  The named
     device is the actual target of the specified fan-out and IPP
   Printer operation,
     that is, fan-in

This section defines how the Printer object MUST pass the operation through MAY be used to the
     device rather than affecting the represent IPP
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 fan-out and IPP Printer object attribute "device-names-supported" in section 4.9 of
     this document.

     ISSUE 2 - Shouldn't the fan-in.  Fan-out is where an IPP Printer object also be affected?  In

                      Expires:  January 6, 2001

is used to represent other
     words, if the "device-name" IPP Printer objects.  Fan-in is supplied with the Pause-Printer

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

     operation where several
IPP Printer objects are used to pause the actual device, shouldn't represent another IPP Printer object.

4.1 IPP Printer Fan-Out

The IPP/1.1 Model and Semantics introduces the semantic concept of an
IPP Printer object
     also enter the 'stopped' state with the 'paused' "printer-state-
     reasons" value set?

     ISSUE 3 - An implementation that represents more than one Output Device (see
[ipp-mod] section 2.1).  This concept is free called "Output Device Fan-Out".
However, there was no way to support represent the "device-name"
     operation attribute on any operation, but NEED NOT support it on
     all operations, if it supports it on some, correct?

     ISSUE 4 - Could we specify a minimum set individual states of operations which, if
     supported, MUST also support the "device-name" operation attribute,
     if the implementation supports the "device-name" operation
     attribute
Output Devices or to perform operations on any operation?

3.5.1 Revised text for [ipp-mod] for a specific Output Device when
there was fan-out.  This document generalizes the "device-name" extension

The "device-name" extension recommends that semantics of the following text be added
Printer object to the IPP-MOD document in section 3.2, represent such Subordinate fan-out Output Devices as
IPP Printer objects.  This concept is called "Printer Operations":

     All object fan-out".
A Printer operations are directed at object that has a Subordinate Printer objects OR at named
     devices associated with object is called a Non-
Leaf Printer objects.  A client MUST always
     supply the "printer-uri" operation attribute object.  Thus a Non-Leaf Printer object supports one or
more Subordinate Printer objects in order to identify
     the correct target of the operation. represent Printer object
fan-out. A client MAY also supply the
     "device-name" operation attribute in order Printer object that does not have any Subordinate Printer
objects is called a Leaf Printer object.

Each Non-Leaf Printer object submits jobs to pass its immediate Subordinate
Printers and otherwise controls the operation to Subordinate Printers using IPP or
other protocols.  Whether pending jobs are kept in the named device (rather than affecting 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
     specified by "printer-uri")."

     ISSUE 5 (repeat of 2) - Shouldn't the MAY, in turn, have
Subordinate Printer objects.  Thus a Printer object also can be
     affected?  In other words, if the "device-name" is supplied with
     the Pause-Printer operation to pause the actual device, shouldn't
     the both a Non-
Leaf Printer and a Subordinate Printer.

A Subordinate Printer object also enter the 'stopped' state with the 'paused'
     "printer-state-reasons" value set?

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

3.6 Summary MUST be a conforming Printer object, so it
MUST support all of the operation attributes for the Printer REQUIRED operations

The following table shows the operation attributes for and attributes.  However,
with access control, the Subordinate Printer
operations that a client MAY supply in a request.  Operation parameters
and attributes be configured so that a client MUST supply
end-user clients are not shown.  Also
"requesting-user-name" is 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.2 IPP Printer Fan-In

The IPP/1.1 Model and Semantics did not shown, though it is RECOMMENDED preclude the semantic concept of
multiple IPP Printer objects that represent a
client supply it in every request.
Legend:
     R - REQUIRED single Output Device (see
[ipp-mod] section 2.1).  However, there was no way for the client to
determine that there was a fan-in configuration, nor was there a way to
perform operations on the Subordinate device.  This specification
generalizes the semantics of the Printer object to support
     O - OPTIONAL for a allow several Non-
Leaf IPP Printer objects to support; the represent a single Subordinate Printer ignores the
attribute if not supported

Operation    Pau  Resu Pur  Get-  Set-  Enab Disa Res  Rest Non  Shu
Attribute    se-  me-  ge-  Print Print le-  ble- et-  art- -    t
             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
format

factory-                       O
settings

printer-      O    O    O                  O    O    O    O         O
message-
from-
operator

job-type                                    O    O

when          O                                       O              O

reset-                                                 R
function

synchronize                                                           O

shutdown-                                                             R
function

device-name   O    O    O    O     O     O    O    O    O    O    O

3.7 Summary of the operation attributes for the Job operations

The following table shows the operation attributes for the Job
operations that
object.  Thus a client Non-Leaf Printer object MAY supply in share a request.  Operation attributes
that specify the Subordinate Printer
object with one or Job more other Non-Leaf Printer objects in order to
represent IPP Printer fan-in.

As with fan-out (see section 4.1), when a Printer object as 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 target Non-Leaf Printer objects submit jobs to their

                      Expires:  January 6, 2001

Subordinate Printer objects and otherwise control the Subordinate
Printer.  As with fan-out, whether pending jobs are shown kept in the
first two rows, respectively.  Other operation attributes and parameters

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

that a client MUST supply Non-Leaf
Printers until the Subordinate Printer can accept them or are not shown.  Also "requesting-user-name" is
not shown, though it is RECOMMENDED that a client supply it kept in every
request.
Legend:
     R - REQUIRED for a
the Subordinate Printer depends on implementation and/or configuration
policy.

4.3 Printer object attributes used to support
     O - OPTIONAL for a represent Printer fan-out and
    Printer fan-in

The following Printer Description attributes are defined to support; represent
the relationship between Printer ignores object(s) and their Subordinate Printer
object(s):

1."subordinate-printers-supported" (1setOf uri) - contains the
attribute if not supported

Operation    Can  Canc Ho  Re Spa  Pau  Re Get-  Set-  Rest Repr  Pro
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 URI of
  the immediate Subordinate Printer object(s).

2."parent-printers-supported (1setOf uri) -  ibut  ibut       Job   Job
                  Job  b   Jo t-   t-   Jo es    es
                            b  Job  Job  b

printer-uri        R            R    R

printer-      R         R   R            R    R     R    R    R    R
uri/job-id 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 job-uri

job-id             R            R    R

requested-                                     R
attributes

back-space                       O

forward-                         O
space

synchronize                      O    O

when                                  O                          O

job-          O    O    O   O        O   O                O    O    O
message-
from-
operator

message       O         O   O        O   O                O    O    O
[to-
operator]

job-hold-               O*  O*                                  O**
until

device-name   O    O    O   O   O    O   O    O     O    O    O    O

*    The
  "parents".

4.4  Subordinate Printer MUST support URI

Each Subordinate Printer object has a URI which is used as the "job-hold-until" target of
each operation attribute
if it supports on the "job-hold-until" Job Template attribute.
** Subordinate Printer.  The means for configuring
URIs for Subordinate Printer MUST support objects is implementation-dependent as are
all URIs.  However, there are two distinct approaches:

     a. When the "job-hold-until" implementation wants to make sure that no operation attribute if
it supports on
     a Subordinate Printer object as a target "sneaks by" the Set-Job-Attributes operation, so parent
     Printer object (or the Subordinate Printer is fronting for a device
     that is not networked), the client can
hold host part of the job with URI specifies the Reprocess-Job operation and host
     of the modify parent Printer.  Then the job
before releasing it to be processed.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

4. New parent Printer Description Attributes

The following new object can easily
     reflect the state of the Subordinate Printer Description attributes are needed to support objects in the new
     parent's Printer object state and state reasons as the operation
     passes "through" the parent Printer object.

     b. When the Subordinate Printer is networked and the implementation
     allows operations defined in this document.

4.1 printer-settable-attributes (1setOf type2 keyword)

Type to go directly to the Subordinate Printer (with
     proper access control) without knowledge of registration:  attribute
Proposed keyword name the parent Printer
     object, the host part of this attribute:  printer-settable-attributes
Types the URI is different than the host part of attribute (Operation, Job Template, Job Description,
     the parent Printer
Description): object.  In such a case, the parent Printer Description
Operations
     object MUST keep its "printer-state" and "printer-state-reasons" up
     to be used date, either by polling the Subordinate Printer object or by
     subscribing to events with if the attribute is an operation attribute:
N/A
Object (Job, Printer, etc. if bound Subordinate Printer object (see
     [ipp-not-spec] for means to an object): subscribe to event notification when
     the Subordinate 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 object supports IPP notification).

                      Expires:  January 6, 2001

4.5 Printer object attributes used to represent Output Device Fan-Out

Only Leaf IPP Printer objects are allowed to have one or type3:  type2
If this is a more associated
Output Devices.  Each Leaf Printer attribute, object MAY support 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 "output-
devices-supported" (1setOf name(127)) to indicate the "multiple-document-handling" attribute:  N/A
Specification user-friendly
name(s) of this attribute (follow the style of IPP Model Section
4.2):

4.4.? printer-settable-attributes (1setOf type2 keyword)

This READ-ONLY Printer attribute identifies Output Device(s) that the Leaf Printer object
attributes represents.
It is RECOMMENDED that are settable in this implementation, i.e., each Leaf Printer object have only one associated
Output Device, so that are
settable using the Set-Printer-Attributes operations.  This attribute
MUST individual Output Devices can be supported if represented
completely and controlled completely by clients.  In other words, the Set-Printer-Attributes operations is supported.
The
Leaf Printer's "output-devices-supported" attribute SHOULD have only one
value.

Non-Leaf Printer MUST reject attempts to set any NOT have associated Output Devices.  However, a
Non-Leaf Printer attributes SHOULD support an "output-devices-supported" (1setOf
name(127)) Printer Description attribute that are
not in this list, returning contains all the 'client-error-attributes-not-settable'
status code (see section 6.1).  The value of this attribute MAY depend
on the value values of
its immediate Subordinate Printers.  Since such Subordinate Printers MAY
be Leaf or Non-Leaf, the "document-format" operation same rules apply to them, etc.  Thus any Non-
Leaf Printer SHOULD have an "output-devices-supported" (1setOf
name(127)) attribute supplied in that contains all the Get-Printer-Attributes operation (see [ipp-mod] section 3.2.5.1).

4.2 interpreter-settable-attributes (1setOf type2 keyword)

Type values of registration:  attribute
Proposed keyword name the Output Devices
associated with Leaf Printers of this attribute:  interpreter-settable-
attributes
Types its complete sub-tree.

When adding, removing, or changing a configuration 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 Printers and range as
Output Devices, there can be moments 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 time when the value returned depend on
"document-format" (See Section 6.2):  Yes

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

If this tree structure is
not consistent.  In other words, times when a Job Template attribute, how Non-Leaf Printer's
"subordinate-printers-supported" does its specification depend
on the value of the "multiple-document-handling" attribute:  N/A
Specification of this attribute (follow not agree with the style of IPP Model Section
4.2):

4.4.? interpreter-settable-attributes (1setOf type2 keyword)

This READ-ONLY Printer attribute identifies Subordinate
Printer's "parent-printers-supported".   Therefore, the Interpreter object (see
section 2.1) attributes operator SHOULD
first Deactivate all Printers that are settable being configured in this implementation, i.e.,
that are settable using the Set-Printer-Attributes operations.  This
attribute MUST be supported if way,
update all pointer attributes, and then reactivate.  A useful client
tool would validate a tree structure before Activating the Set-Printer-Attributes operations is
supported.  The Printer MUST reject attempts Printers
involved.

                      Expires:  January 6, 2001

4.6 Figures to set any Printer or
Interpreter attributes that show all possible configurations

Figure 1, Figure 2, and Figure 3 are not in this list, returning taken from [ipp-mod] to show the 'client-
error-attributes-not-settable' status code (see section 6.1).
configurations possible with IPP/1.0 and IPP/1.1 where all Printer
objects are Leaf Printer objects.  The value
of remaining figures show additional
configurations that this attribute MAY depend on document defines using Non-Leaf and Leaf
Printer objects. Legend for all figures:

----> indicates a network protocol with the value direction of the "document-format"
operation attribute supplied in the Get-Printer-Attributes operation
(see [ipp-mod] section 3.2.5.1).

4.3 job-settable-attributes (1setOf type2 keyword)

Type of registration:  attribute
Proposed keyword name of this attribute:  job-settable-attributes
Types of attribute (Operation, Job Template, Job Description, Printer
Description): its requests

##### indicates a Printer Description
Operations to be used with if the attribute object which is an operation attribute:
N/A
Object (Job, Printer, etc. if bound to an object):  Printer
Attribute syntax(es) (include 1setOf and range as either:
        - embedded in Section 4.2):
1setOf type2 keyword
If attribute syntax is 'keyword' or 'enum', is it type2 an Output Device or type3:  type2
If this is
        - hosted in a server.  The 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 object
      might or might not be capable of queuing/spooling.

any   indicates any network protocol or direct
      connect, including IPP Model Section
4.2):

4.4.? job-settable-attributes (1setOf type2 keyword)

This READ-ONLY
                                               Output Device
                                             +---------------+
                                             |  ###########  |
 O   +--------+                              |  # (Leaf)  #  |
/|\  | client |------------IPP-----------------># Printer #  |
/ \  +--------+                              |  # Object  #  |
                                             |  ###########  |
                                             +---------------+

                   Figure 1 - Embedded Printer attribute identifies the Job object attributes
that are settable

                          ###########          Output Device
 O   +--------+           # (Leaf)  #        +---------------+
/|\  | client |---IPP----># Printer #---any->|               |
/ \  +--------+           # object  #        |               |
                          ###########        +---------------+

                    Figure 2 - Hosted Printer object

                                             +---------------+
                                             |               |
                                          +->| Output Device |
                          ########### any/   |               |
 O   +--------+           # (Leaf)  #   /    +---------------+
/|\  | client |---IPP----># Printer #--*
/ \  +--------+           # Object  #   \    +---------------+
                          ########### any\   |               |
                                          +->| Output Device |
                                             |               |
                                             +---------------+

                    Figure 3 - Output Device fan out

                      Expires:  January 6, 2001
                          ###########           ###########
 O   +--------+           # Non-Leaf#           # subord. #
/|\  | client |---IPP----># Printer #---IPP----># Printer #
/ \  +--------+           # object  #           # object  #
                          ###########           ###########

The Subordinate Printer can be a Non-Leaf Printer as in this implementation, i.e., that are settable using
the Set-Job-Attributes operations.  This attribute MUST Figure 4 to
Figure 6, or can be supported if
the Set-Job-Attributes operations is supported.  The a Leaf Printer MUST reject
attempts as in Figure 1 to set Figure 3.

                     Figure 4 - Chained IPP Printer

                +------IPP--------------------->###########
               /                           +---># subord. #
              /                           /     # Printer #
             /            ###########   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)

Type of registration:  attribute
Proposed keyword name of this attribute:  printer-controls-other-
protocols

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

Types of attribute (Operation, Job Template, Job Description,     # object  #
 O   +--------+           # Non-Leaf#   /       ###########
/|\  | client |---IPP----># Printer #--*
/ \  +--------+           # object  #   \
             \            ###########   any     ###########
              \                           \     # subord. #
               \                           +---># Printer
Description): #
                +------IPP---------------------># object  #
                                                ###########

The Subordinate Printer Description
Operations can be a Non-Leaf Printer as in Figure 4 to
Figure 6, or can be used with if the attribute is an operation attribute:
N/A
Object (Job, Printer, etc. if bound a Leaf Printer as in Figure 1 to an object): Figure 3.

                     Figure 5 - IPP Printer fan out

                          (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
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
boolean
If attribute syntax is 'keyword' Figure 4, Figure
5, or 'enum', is it type2 Figure 6, or type3:  N/A
If this is can be a Leaf 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 as in Figure 1, Figure 2, or
Figure 3.

                     Figure 6 - IPP Model Section
4.2):

4.4.? printer-controls-other-protocols (boolean) Printer fan in

                      Expires:  January 6, 2001

4.7 Forwarding requests

This section describes the forwarding of Job and Printer attribute indicates whether operations, such as Disable-
Printer, Pause-Printer, etc., affect non-IPP protocols that may be
supported.  It is RECOMMENDED that IPP control other non-IPP protocols.
However, this attribute permits an implementation requests to indicate explicitly
whether it does affect other protocols or not.

A 'false' value indicates
Subordinate Printer objects.

4.7.1 Forwarding requests that IPP operations only affect jobs submitted
by the IPP Protocol.  For example, a 'true' value indicates that a
Disable-Printer operation prevents all protocols from submitting jobs,
not just Printer objects

In Printer fan-out, Printer fan-in, and Chained Printers, the Non-Leaf
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
Description attribute is just a boolean, or do we need a list of object MUST NOT forward the operations that affect non-IPP protocols?

  TH> It would be more flexible Printer
objects to allow per-operation control, so
  change from "printer-controls-other-protocols" its Subordinate Printer Description
  attribute objects.  If a client wants to "operations-affecting-other-protocols (1setOf type2
  enum).
explicitly target a Subordinate Printer, the client MUST specify the URI
of the Subordinate Printer.   The values are defined client can determine the URI of any
Subordinate Printers by querying the "operations-supported Printer's "subordinate-printers-
supported (1setOf
  type2 enum)" operation.

  HRL> The situation is already complex in that SNMP or IPP (possibly
  others?) may "compete" or "conflict" is managing uri) attribute (see section 6.1).

Table 2 lists the printer. Per-
  operation control does nothing to alleviate this operations that affect Printer objects and may make the
  situation even more complex. Suggest leave as is.

As with any Printer Description attribute
forwarding behavior that this specification does
not list as READ-ONLY, an implementation MAY allow a client Non-Leaf Printer MUST exhibit to change
the value of this attribute using Set-Printer-Attributes, thereby
changing the way its
immediate Subordinate Printers.  Operations that the IPP affect jobs have a
different forwarding rule (see section 0 and Table 3):

      Table 2 - Forwarding operations that affect other non-IPP protocols.
An implementation MAY also support other means Printer objects

Printer Operation     Non-Leaf Printer action
Printer Operations:
  Enable-Printer     MUST NOT forward to change the value any of
this attribute, such as via the console or at installation time.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

ISSUE 7:  Is IPP intended for printer management. The issue is still
undetermined?
  TH> I think it is natural and so far there is not much overlap with its Subordinate
                      Printers
  Disable-Printer    MUST NOT forward to any MIB.  If and when we do get overlap, we need of its Subordinate
                      Printers
  Hold-New-Jobs      MUST NOT forward to make sure that the
  semantics are the same.

  HRL> I think it is clear that IPP is moving in this direction. I leave
  this issue open for further discussion, however, because I believe we
  need any of its Subordinate
                      Printers
  Release-Held-New-  MUST NOT forward to be as clear as possible about the possible conflicts any of two
  management protocols originating form one organization (SNMP and IPP)
  and provide some guidelines.

4.5 printer-message-time (integer(MIN:MAX))

Type its Subordinate
  Jobs               Printers
  Deactivate-Printer MUST NOT forward to any of registration:  attribute
Proposed keyword name its Subordinate
                      Printers
  Activate-Printer   MUST NOT forward to any of this attribute:  printer-message-time
Types its Subordinate
                      Printers
  Restart-Printer    MUST NOT forward to any of attribute (Operation, Job Template, Job Description, its Subordinate
                      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
Description):       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

                      Expires:  January 6, 2001

Forwarding requests that affect Jobs

Unlike Printer Description Operations that only affect Printer objects (see section
0), a Non-Leaf Printer object MUST forward operations that directly
affect jobs 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 appropriate Job object(s) in Section 4.2):
integer(MIN:MAX)
If attribute syntax is 'keyword' one or 'enum', is it type2 or type3:  N/A
If this is a more of its
immediate Subordinate Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2):  No
If this objects.  Forwarding 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 REQUIRED since the style
purpose of IPP Model Section
4.2):

4.4.? printer-message-time (integer(MIN:MAX))

This READ-ONLY Printer Description attribute contains the time that the
Printer's "printer-message-from-operator" was changed by the operator
using any such a Job operation where the client supplied is to affect the "printer-message-from-
operator" operation attribute (see section 3.1) indicated job which
itself may have been forwarded.  Such forwarding MAY be immediate or was explicitly set
using
queued, depending on the Set-Printer-Attributes operation (see section 7.1.1).  This
attribute allows and the users implementation.  For example,
a Non-Leaf Printer object MAY queue/spool jobs, feeding a job at a time
to know when its Subordinate Printer(s), or MAY forward jobs immediately to one of
its Subordinate Printers.  In either case, the "printer-message-from-
operator" attribute was last set.

The Non-Leaf Printer sets the value object
is forwarding Job Creation operations to one of this attribute by copying its Subordinate
Printers.  Only the value time of forwarding of the
Printer's "printer-up-time" attribute (see [ipp-mod] section 4.3.14).
If the Printer resets its "printer-up-time" attribute to 1 Job Creation operations
depends on power-up,
then it MUST change the value of whether the "printer-message-time" policy is to 0 or a
negative number as specified queue/spool jobs in [ipp-mod] section 4.3.14.

Note:  This attribute helps users better understand the context for Non-Leaf
Printer or the
"printer-message-from-operator" message.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

4.6 printer-message-date-time (dateTime)

Type of registration:  attribute
Proposed keyword name of this attribute:  printer-message-date-time
Types of attribute (Operation, Subordinate Printer.

When a Non-Leaf Printer object creates a Job Template, object in its Subordinate
Printer, whether that Non-Leaf Printer object keeps a fully formed Job Description,
object or just keeps a mapping from the "job-ids" that it assigned to
those assigned by its Subordinate Printer
Description): object is IMPLEMENTATION-
DEPENDENT.  In either case, the Non-Leaf Printer Description
Operations to MUST be used with if the attribute is an operation attribute:
N/A
Object (Job, Printer, etc. if bound able to an object):  Printer
Attribute syntax(es) (include 1setOf accept
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 carry out future Job operations that specify the value "job-id" that the
Non-Leaf Printer assigned and returned depend on
"document-format" (See Section 6.2):  No
If this is to the job submitting client.

Table 3 lists the operations that directly affect jobs and the
forwarding behavior that a Job Template attribute, how does Non-Leaf Printer MUST exhibit to its specification depend
on
Subordinate Printers:

        Table 3 - Forwarding operations that affect Jobs objects

  Job operation
                      Non-Leaf Printer action

  Job operations:
        Reprocess-Job MUST forward to the value appropriate Job in one of
                      its Subordinate Printers
        Cancel-       MUST NOT forward
  Current-Job
        Resume-Job    MUST forward to the "multiple-document-handling" attribute:  N/A
Specification appropriate Job in one of this attribute (follow
                      its Subordinate Printers
        Promote-Job   MUST forward to the style appropriate Job in one of IPP Model Section
4.2):

4.4.? printer-message-date-time (dateTime)

This READ-ONLY
                      its Subordinate Printers
  IPP/1.1 Printer Description attribute contains the date and time
that
  Operations:
        Print-Job     MUST forward immediately or queue to the Printer's "printer-message-from-operator" was changed by
                      appropriate Subordinate Printer
        Print-URI     MUST forward immediately or queue to the
operator using any operation where
                      appropriate Subordinate Printer
        Validate-Job  MUST forward to the client supplied appropriate Subordinate
                      Printer
        Create-Job    MUST forward immediately or queue to the "printer-
message-from-operator" operation attribute (see section 3.1)
                      appropriate Subordinate Printer

                      Expires:  January 6, 2001
        Get-Jobs      MUST forward to all its Subordinate Printers
        Purge-Jobs    MUST forward to all its Subordinate Printers
  IPP/1.1 Job
  operations:
        Send-Document MUST forward immediately or was
explicitly set using queue to the Set-Printer-Attributes operation (see section
7.1.1).  This attribute allows
                      appropriate Job in one of its Subordinate
                      Printers
        Send-URI      MUST forward immediately or queue to the users
                      appropriate Job in one of its Subordinate
                      Printers
        Cancel-Job    MUST forward to know when the "printer-
message-from-operator" attribute was last set.  This attribute appropriate Job in one of
                      its Subordinate Printers
        Get-Job-      MUST be
supported forward to the appropriate Job in one of
  Attributes          its Subordinate Printers, if the Non-Leaf
                      Printer supports both doesn't know the "printer-message-from-
operator" and complete status of the "printer-current-date-time" attributes.

Note:  This attribute helps users better understand
                      Job object
        Hold-Job      MUST forward to the context for the
"printer-message-from-operator" message.

4.7 printer-message-operation (type2 keyword)

Type of registration:  attribute
Proposed keyword name appropriate Job in one of this attribute:  printer-message-operation
Types
                      its Subordinate Printers
        Release-Job   MUST forward to the appropriate Job in one of attribute (Operation,
                      its Subordinate Printers
        Restart-Job   MUST forward to the appropriate Job Template, in one of
                      its Subordinate Printers
  IPP Set operations: See [ipp-set-ops]
        Set-Job-      MUST forward to the appropriate Job Description, Printer
Description): in one of
  Attributes          its Subordinate Printers

When a Printer Description
Operations receives a request that REQUIRES forwarding, it does so
on a "best efforts basis", and returns a response to be used with if the attribute 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 an operation attribute:
N/A
Object (Job, Printer, etc. if bound defined,
which a client can subscribe to an object):  Printer
Attribute syntax(es) (include 1setOf (see section  [ipp-ntfy]).

The following Job Description attributes are defined to help represent
Job relationships for fan-out and range as in Section 4.2):
type2 enum
If forwarding of jobs:

1."output-device-assigned" (name(127)) - from [ipp-mod]: This attribute syntax is 'keyword' or 'enum', is it type2 or type3:  type2
If
  identifies the Output Device to which the Printer object has assigned
  this is a job.  If an Output Device implements an embedded Printer attribute, MAY object,
  the value returned depend on
"document-format" (See Section 6.2):  No
If Printer object NEED NOT set this is attribute.  If a Job Template attribute, how does its specification depend
on print server
  implements a Printer object, the value of MAY be empty (zero-length
  string) or not returned until the "multiple-document-handling" attribute:  N/A

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

Specification of this attribute (follow Printer object assigns an Output
  Device to the style of IPP Model Section
4.2):

4.4.? printer-message-operation (type2 enum) job.  This READ-ONLY attribute is particularly useful when a
  single Printer Description object supports multiple devices (so called "fan-
  out").

2."original-requesting-user-name" (name(MAX)) - operation attribute contains
  containing the operation that
was used to changed user name of the Printer's "printer-message-from-operator" by original user, i.e., corresponds to
  the
operator using any "requesting-user-name" operation where attribute that the original
  client supplied to the "printer-
message-from-operator" first Printer object.  The IPP/1.1
  "requesting-user-name" operation attribute (see section 3.1) or
explicitly set using the Set-Printer-Attributes operation (see section
7.1.1).  This attribute allows the users to know which operation was
used [ipp-mod]) is updated
  by each client to change be itself on each hop, i.e., the "printer-message-from-operator" attribute when it was
last set.

Note:  This attribute helps users better understand "requesting-user-
  name" is the context for client forwarding the
"printer-message-from-operator" message.

4.8 when-values-supported (1setOf type2 keyword)

Type of registration:  attribute
Proposed keyword name of this attribute:  when-values-supported
Types of attribute (Operation, Job Template, request, not the original client.
  The "job-originating-user-name" 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 remains 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

                      Expires:  January 6, 2001
  the value returned depend on
"document-format" (See Section 6.2):  No
If this authenticated original user, not the parent Printer's
  authenticated host, and is a Job Template attribute, how does its specification depend
on forwarded by each client without changing
  the value of value.

5  New Operation attributes

This section summarizes the "multiple-document-handling" attribute:  N/A
Specification usage of this attribute (follow the style of IPP Model Section
4.2):

4.4.? when-values-supported (1setOf type2 keyword)

This READ-ONLY new "printer-message-from-
operation" and "job-message-from-operator" operation attributes that set
the corresponding Printer and Job Description attribute contains attributes.  These
operation attributes are defined for most of the supported
values 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 "when" definition of these operation attribute in any operation.  The
operations include:  Pause-Printer, Reset-Printer, Shutdown-Printer, and
Pause-Current-Job.  For Pause-Current-Job, only attributes.
Table 4 shows the 'now' and 'after-
current-copy' values operation attributes that are defined.  So defined for use with the other values: 'after-current-
job' and 'after-all', if present in this attribute, don't apply
Printer Operations.
Legend:
     R - REQUIRED for a Printer to
Pause-Current-Job).

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

4.9 device-names-supported (1setOf name(127))

ISSUE 8 support
     O - For consistency with [ipp-mod], shouldn't this be singular
even though it is multi-valued, i.e., device-name-supported (1setOf
name(127))?

This OPTIONAL for a Printer to support; the Printer ignores the
attribute contains at least one device name which
is associated with this Printer object.  It OPTIONALLY contains more
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 if not
have an associated named device MUST NOT support this attribute.

An Administrator determines device names and configures this attribute
to contain those device names via IPP Set-Printer-Attributes operation
(see section 7.1.1) or by some means outside the scope of this document.
The precise format of these device names is implementation dependent and
MAY depend on the protocol stack and supported
     <blank> - not defined for use with the directory namespace.

Note:  The new attribute "device-names-supported" will also enhance operation; the
usefulness of Printer
ignores the IPP/1.1 Job object attribute "output-device-assigned"
(see [ipp-mod] section 4.3.13).  The "output-device-assigned" Job

      Table 4 - Operation attribute identifies the output device to which the Printer object has
assigned a job, support for example, when a single Printer object is supporting
multiple devices.

See also Operations

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

attributes-      R         R       R      R      R     R    R
charset

attributes-      R         R       R      R      R     R    R
natural-
language

printer-uri      R         R       R      R      R     R    R

requesting-      R         R       R      R      R     R    R
user-name

printer-         O         O       O              O     O    O
message-
from-
operator

Table 5 shows the operation attribute "device-name" in section 3.5 of this
document.

5. Additional values for "printer-state-reasons" and "job-state-reasons" attributes

The following values that are added to the "printer-state-reasons" and "job-
state-reasons" defined for use with the operations defined in this document.

5.1 Value
Job operations.
Legend:
     R - REQUIRED for "printer-state-reasons":  'standby'

Type of registration:  type2 keyword attribute value
Name of attribute to which this keyword specification is a Printer to be added:
printer-state-reasons
Proposed keyword name of this keyword value:  standby
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

  'standby':  The Printer has been shutdown in standby mode.  Only
     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'

Type of registration:  type2 keyword attribute value
Name of attribute to which this keyword specification is to be added:
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

This section defines new status codes used by the operations defined in
this document.

6.1 New status code: 'client-error-attributes-not-settable'

Type of registration:  status code
Keyword symbolic name of this status code value:  'client-error-
attributes-not-settable'
Numeric value (to be assigned by the IPP Designated Expert in
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)

In a Set-Printer-Attributes or Set-Job-Attributes request, if the
Printer object does not support one or more attributes as settable, the
Printer object MUST return this status code.  The Printer object MUST
also return in the Unsupported Attributes Group all the attributes
and/or values supplied by the client that are not settable.  See [ipp-
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

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

6.2 New status code: 'server-error-printer-is-in-standby-mode'

Type of registration:  status code
Keyword symbolic name of this status code value:  'server-error-printer-
is-in-standby-mode'
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

The Printer has been shutdown and is only accepting the Restart-Printer
(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

The Set 2 operations are summarized in the following table:

  Operation Name  Operati Brief description
                  on-Id

  Set-Printer-    0x??    Sets attribute values of the target
  Attributes               Printer object

  Enable-Printer  0x??    Allows the target Printer to accept
                           create job operations

  Disable-Printer 0x??    Prevents the target Printer from
                           accepting create job operations

  Reset-Printer   0x??    Resets the target Printer to one of
                           several indicated ways

  Restart-Printer 0x??    Restarts the target Printer from a
                           standby shutdown mode

  Non-Process-    0x??    Moves the last printed sheet(s) to the
  Run-Out                  exit or stacker

  Shutdown-       0x??    Shuts down the target Printer in
  Printer                  several ways

  Set-Job-        0x??    Sets attribute values of the target Job
  Attributes               object

  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

  Pause-Current-  0x??    Pauses the current processing job on
  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

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

  Operation Name  Operati Brief description
                  on-Id

  Promote-Job     0x??    Promote the pending target job to be
                           next after the current job(s) complete

  Space-Current-  0x??    Skips or repeats the specified number
  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
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

All Printer operations are directed at Printer objects.  A client MUST
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

Type of registration:  operation
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
attributes of a Printer object.   In the request, the client supplies
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
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
the values of the Printer object's "printer-state" attribute.

7.1.1.1 Settable and READ-ONLY Printer Description attributes

If the Printer supports the "printer-message-from-operator" Printer
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

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

operator" Printer attribute to this new value and MUST also set the
"printer-message-time", "printer-message-date-time", and "printer-
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
SHOULD support setting of:

     all Job Template Default ("xxx-default") attributes
     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
extensions).

The following Printer Description attributes (see [ipp-mod] section 4.4)
MUST NOT be settable, i.e., they are READ-ONLY:

     printer-state
     printer-state-reasons
     printer-state-message
     printer-is-accepting-jobs - see Enable-Printer/Disable-Printer
     queued-job-count
     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
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
     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
     Description attribute (see [ipp-mod] section 4.4.14) is settable,
     then changing its value MUST affect the protocol versions that are
     accepted or rejected.  Such an implementation will need to be able
     to reject values for operations that it contains no code support
     for.

                      Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

See the "factory-settings" operation attribute (see section 3.3)  January 6, 2001
     O - OPTIONAL for a
way Printer to query the implementation supported values using support; the Get-Printer-
Attributes operation.  See Printer ignores the "reset-function" operation
          attribute of
the Reset-Printer operation (see section 7.1.4) if supplied, but not supported
     <blank> - not defined for a way to restore use with the
values to operation; the factory settings.

Access Rights: Authentication and access control (see [ipp-mod] sections
1, 8.3, and 8.5) apply to this operation.

Most Printer attributes will require administrator privileges to set,
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

The following sets of attributes are part of
     ignores the Set-Printer-Attributes
Request:

Group 1: attribute

        Table 5 - 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: attribute support for Job operations

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

attributes-   R    R    R    R   R    R     R    R    R    R    R
charset

attributes-   R    R    R    R   R    R     R    R    R    R    R
natural-
language

printer-uri   R    R    R    R   R    R     R    R    R    R    R

job-uri       R         R        R    R     R    R    R    R    R

job-id        R    R    R    R   R    R     R    R    R    R    R

requesting-   R    R    R    R   R    R     R    R    R    R    R
user-name

job-          O    O    O    O   O           O    O    O    O    O
message-
from-
operator

message       O         O    O   O           O    O    O    O    O
[to-
operator]

job-hold-               O*                        O**
until

*    The "printer-uri" (uri) operation attribute which is Printer MUST support the target for
     this "job-hold-until" operation as described in [ipp-mod] section 3.1.5.

  Requesting User Name:
     The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
     by
if it supports the client as described in [ipp-mod] section 8.3.

  "document-format" (mimeMediaType):
     The client SHOULD supply this "job-hold-until" Job Template attribute.
**  The Printer object MUST support this attribute.  This attribute is useful for a client to
     select the Interpreter object to which the "job-hold-until" operation 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 if
it supports the target of a Get-Printer-Attributes or Set-Printer-
     Attributes operation is either Set-Job-Attributes operation, so that the Printer object or client can
hold the
     Interpreter object identified by job with the "document-format" Reprocess-Job 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

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

     If a client wants to set an attribute of all of the Interpreter
     objects to modify the same value, job
before releasing it can query the Printer's "document-
     format-supported" to be processed.

6  New Printer Description attribute and perform
     separate Set-Printer-Attributes for each document format supported.

     ISSUE 9:  Do we need a way Attributes

The following new Printer Description attributes are needed to get and/or set support
the "xxx" attribute
     for all Interpreter objects new operations defined in one Get-Printer-Attributes or Set-
     Printer-Attributes operation?  Or is it sufficient for a client to
     provide the equivalent functionality by stepping through all this document.

                      Expires:  January 6, 2001

6.1 subordinate-printers-supported (1setOf uri)

This Printer attribute is REQUIRED if an implementation supports
Subordinate Printers (see section 4) and contains the
     values URIs of the "document-formats-supported"
immediate Subordinate Printer object(s) associated with repeating this Printer
object.  Each Non-Leaf Printer object MUST support this Printer
Description attribute.  A Leaf Printer object either does not support
the Get "subordinate-printers-supported" attribute or Set operation?

     ISSUE 10:  Ok to add does so with the Interpreter object, even though it doesn't
     solve all 'no-
value' out-of-band value (see [ipp-mod] section 4.1), depending on
implementation.

The precise format of the attribute constraint problems.  At least it gives
     us a more object-based description of Subordinate Printer URIs is implementation
dependent (see section 4.4).

If the semantics.  When we do
     add some sort of Printer Description attribute that enumerates
     combinations of Job attribute values that may object does not have an associated Output Device, the
Printer MAY automatically copy the value of the Subordinate Printer
object's "printer-name" MAY be used in
     combination (like PPD file constraints), it can include to populate the
     "document-format" Job object's
"output-device-assigned" attribute among them.  So introducing (see [ipp-mod] section 4.3.13).  The
"output-device-assigned" Job attribute identifies the Output Device to
which the
     Interpreter Printer object in no way precludes has assigned a complete constraint
     description mechanism in job, for example, when a single
Printer object is supporting Device fan-out or Printer fan-out.

6.2 parent-printers-supported (1setOf uri)

This Printer attribute is REQUIRED if an implementation supports
Subordinate Printers (see section 4) and contains the future.

     If 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 distinguish between different sets
     of supported values for each different document format when
     validating jobs in support the create and Validate-Job operations, it MUST
     NOT distinguish between different document formats in
"parent-printers-supported" attribute or does so with the Set-
     Printer-Attributes operation.  If 'no-value'
out-of-band value (see [ipp-mod] section 4.1), depending on
implementation.

6.3 redirection-printers-supported (1setOf uri)

This Printer attribute is REQUIRED if an implementation supports the
Redirect-Job operation (see section 12.5).  It specifies the URIs that
the Printer object does
     distinguish between different sets of supported values supports for each
     different document format specified by the client, this
     specialization applies only redirection jobs to other Printers (on the same
server).

7  Additional Values for "printer-state-reasons"

This section defines additional values for the "printer-state-reasons"
Printer attributes as Description attribute.

                      Expires:  January 6, 2001

7.1 'hold-new-jobs'

  'hold-new-jobs': The operator has issued the
     Get-Printer-Attributes Hold-New-Jobs operation
     (see [ipp-mod] section 3.2.5.1).

     If 0) or other means, but the client omits this "document-format" operation attribute, output-device(s) are taking
     an appreciable time to stop.  Later, when all output has stopped,
     the
     Printer object MUST respond as if "printer-state" becomes 'stopped', and the attribute had been supplied
     with 'paused' value
     replaces the 'moving-to-paused' value of in the Printer object's "document-format-default" "printer-state-
     reasons" attribute.  It  This value MUST be supported, if the Hold-New-
     Jobs operation is recommended that supported and the implementation takes
     significant time to pause a device in certain circumstances.

7.2 'deactivated'

  'deactivated':  A client always supply has issued a value Deactivate-Printer operation
     for "document-format", since the Printer object's "document-format-
     default" may be 'application/octet-stream', object (see section 0) and the Printer is in which case the set
     attributes
     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.

8  Additional Values for "job-state-reasons"

This section defines additional values are for the union of the document formats
     that "job-state-reasons" Job
Description attribute.

8.1 'job-suspended'

  'job-suspended':  The job has been suspended while processing using
     the Printer Suspend-Current-Job operation and other jobs can automatically sense.  For more details, see be processed
     on the description of Printer.  The Job can be resumed using the 'mimeMediaType' attribute syntax in [ipp-
     mod] Resume-Job
     operation which removes this value.

9  Additional events

The following Printer events are defined for use with [ipp-ntfy]:

  'forwarded-operation-failed' - an operation that a Printer forwarded
     to a Subordinate Printer (see section 4.1.9.

     If 4.7) failed.

10 Additional status codes

This section defines new status codes used by the client supplies a value for operations defined in
this document.

                      Expires:  January 6, 2001

10.1 'server-error-printer-is-deactivated' (0x????)

The Printer has been deactivated using the "document-format" Operation
     attribute that Deactivate-Printer operation
and is not supported by only accepting the Printer, i.e., is not among Activate-Printer (see section 0), Get-Job-
Attributes, Get-Jobs, Get-Printer-Attributes, and any other Get-Xxxx
operations.  An operator can perform the values of Activate-Printer operation to
allow the Printer object's "document-format-supported"
     attribute, to accept other operations.

11 Definition of the Printer object MUST reject the operation and return
     the 'client-error-document-format-not-supported' status code.

Group 2: Operations

All Printer Attributes

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

     The are directed at Printer objects.  A client MUST
always supply a set of Printer attributes as defined the "printer-uri" operation attribute in
     [ipp-mod] section 4.2 Job Template Attributes ("xxx-default", "xxx-
     supported", and "xxx-ready" attributes) 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 4.4 Printer
     Description Attributes.  Each 3.1.

The Set 2 Printer attribute supplied Operations are summarized in Group 2
     replaces the value(s) of Table 6:

          Table 6 - Printer Operation Operation-Id assignments

  Operation Name  Operati Brief description
                  on-Id
  Enable-Printer  0x??    Allows the corresponding target Printer attribute on to accept Job
                           Creation operations
  Disable-Printer 0x??    Prevents the target Printer object.  If a from
                           accepting Job Creation operations
  Pause-Printer-  0x??    Pause the Printer object attribute had not after the current job
  After-Current-           has been
     configured yet and so had sent to the 'no-value' out-of-band value (see
     [ipp-mod] 4.1), Output Device.
  Job
  Hold-New-Jobs   0x??    Finishes processing all currently
                           pending jobs.  Any new jobs are placed
                           in the supplied value(s) replace 'pending-held' state.
  Release-Held-   0x??    Release all jobs to the 'no-value' value.
     For attributes 'pending' state
  New-Jobs                 that can have multiple values (1setOf), all values
     supplied had been held by the client replace all values 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 corresponding target Printer object attribute.

7.1.1.3 Set-Printer-Attributes Response

The so that
  Printer object returns                  it cannot be restarted or queried
  Startup-Printer 0x??    Starts up the following sets of attributes as part instance of the Get-Printer-Attributes Response:

Group 1: Operation Attributes

  Status Message:
     In addition to Printer
                           object

All of the REQUIRED status code returned operations in every response, this document are OPTIONAL for an IPP object to
support.  Unless the response OPTIONALLY includes a "status-message" (text(255))
     and/or a "detailed-status-message" (text(MAX)) specification of an OPTIONAL operation attribute
     as described requires
support of another OPTIONAL operation, conforming implementations may

                      Expires:  January 6, 2001

support any combination of these operations.  Many of the operations
come in [ipp-mod] sections 13 and 3.1.6.

  Natural Language pairs and Character Set: so both are REQUIRED if either one is implemented.

                      Expires:  January 6, 2001

11.1 The "attributes-charset" Disable and "attributes-natural-language"
     attributes as described in [ipp-mod] section 3.1.4.2.

Group 2: Unsupported Attributes

     See [ipp-mod] Enable Printer Operations

This section 3.1.7 for details on returning Unsupported
     Attributes.

     In defines the case of attributes OPTIONAL Disable-Printer and Enable-Printer
operations that are supported, but are not settable
     by the implementation, i.e., are not among the values of the
     Printer's "settable-attributes" Printer Description attribute (see
     section 4.1), stop and start the IPP Printer object returns the client-supplied
     attribute(s) with a substituted value from accepting new
IPP jobs.  If either of 'not-supported' (same out-
     of-band value as for attributes that these operations 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 supported, both MUST be
supported.

These operations allow the
     attribute is either not settable operator to control whether or is not supported at all.

     ISSUE 11:  Why not the
Printer will accept new Job Creation (Print-Job, Print-URI, and Create-
Job) operations.  These operations have a separate out-of-band 'not-settable'
     value, no other effect on the Printer,
so that the client can distinguish between Printer continues to accept all other operations and
continues to schedule and process jobs normally.  In other words, these
operation control the cases "input of new jobs" to the
     attribute isn't supported versus IPP Printer while the attribute is supported, but is
     not settable?  True,
Pause and Resume operations (see section 11.2) independently control the client can query
"output of new jobs" from the "settable-attributes"

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999 IPP Printer to see which attributes can be set, before or after issuing the
     Set-Printer-Attributes operation.
  TH> I think that providing a separate out-of-band code is useful,
  since a reply could contain both unsupported attributes Output Device.

The Disable-Printer and ones that
  were supported, but are not settable in this implementation.

  HRL> What's wrong with what's already described? How is Enable-Printer operations MUST NOT affect the new
  proposal better?

7.1.2 Disable-Printer Operation

Type
submission of registration:  operation
Proposed name 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 this operation: all jobs by the
associated Output Device(s).

Disable-Printer
Object Target:  Printer
Specification of this operation: Operation

This OPTIONAL operation allows a client to stop the Printer object from
accepting new jobs, i.e., cause the Printer to reject subsequent create job Job
Creation operations (Print-Job, Print-URI, and Create-Job operation) 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.

The IPP Printer MUST accept the request in any state.  The Printer sets
the value of its "printer-is-accepting-jobs" READ-ONLY Printer
Description attribute to 'false' (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 Enable-Printer operation (section 7.1.3) to enable a
Printer to accept Jobs again.

If the Disable-Printer operation is supported, then the Enable-Printer
operation MUST be supported, and vice-versa.

Note:  Use the Enable-Printer and Disable-Printer operations to allow or
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 Disable-Printer operation stops jobs that are
submitted using job submission protocols other than IPP, depends on
implementation, i.e.,
direct effect 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). Printer's "printer-state" and "printer-state-
reasons" attributes.

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Disable-Printer Request and Disable-Printer Response have the same
attribute groups and attributes as the Resume-Printer 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 with 5).

                      Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

the addition of the following Group 1 operation attribute in the
request:

  "job-type" (type2 keyword):
     The client OPTIONALLY supplies this attribute.  The Printer object
     OPTIONALLY supports this attribute.  The value of this attribute
     indicates the type of job to be disabled.  If the client omits this
     attribute, the Printer assumes the 'network-jobs' value.

     Standard keyword values are:
          'network-jobs' - disable jobs submitted using the create job
              operations.
          'walk-up-jobs' - disable jobs submitted locally, such as
              walkup copy jobs
          'all-jobs' - disable all type of jobs

7.1.3  January 6, 2001

Enable-Printer Operation

Type of registration:  operation
Proposed name of this operation:  Enable-Printer
Object Target:  Printer
Specification of this operation:

This OPTIONAL operation allows a client to start the Printer object
accepting jobs, i.e., cause the Printer to accept subsequent create job
operations (Print-Job, Print-URI, and Create-Job operation). Job
Creation operations.  The Printer still accepts all other operations.
All previously submitted Jobs and currently processing Jobs continue
unaffected.

The IPP Printer MUST accept the request in any state.  The Printer sets
the value of its "printer-is-accepting-jobs" READ-ONLY Printer
Description attribute to 'true'
Description attribute to 'true' (see [ipp-mod] section 4.4.20), no
matter what the previous value was.  This operation has no immediate or
direction effect on the Printer's "printer-state" and "printer-state-
reasons" attributes.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Enable-Printer Request and Enable-Printer Response have the same
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-
message-from-operator" operation attribute (see section 5).

11.2 The Pause and Resume Printer Operations

This section leaves the OPTIONAL IPP/1.1 Pause-Printer (see [ipp-mod] section 4.4.20), no
matter what
sections 3.2.7) to be ambiguous as to whether or not it stops the previous value was.  This operation has no immediate
effect on
Printer immediately or after the Printer's "printer-state" current job and "printer-state-reasons"
attributes.

Note:  Use defines the Disable-Printer OPTIONAL
Pause-Printer-After-All-Current-Jobs operation (section 7.1.2) to stop a
Printer from accepting Jobs.

If be after the Enable-Printer operation is current
job.  These operations affect the scheduling of IPP jobs.  If either of
these Pause Printer operations are supported, then the Disable-Printer Resume-Printer
operation MUST be supported, and vice-versa.

Note:  Use the Enable-Printer and Disable-Printer supported.

These operations to allow the operator to control whether or
prevent input not the
Printer will send new IPP jobs to a Printer.  Use the Pause-Printer and Resume-Printer associated Output Device(s) that
the IPP Printer object represents.  These operations to prevent or allow output from have no other
effect on the Printer.

Whether or not Printer, so that the Enable-Printer Printer continues to accept all
operations.  In other words, these operation allows acceptance 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.

The Pause and Resume Printer Operations MUST NOT affect jobs that are were
submitted using other job submission protocols other than IPP,
depends on implementation, i.e., on whether to the IPP protocol is being
used 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).

                      Expires:  January 6, 2001

This document and [ipp-device-ops] define distinct operations in order
to disambiguate the Pause-Printer operation as a universal management 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 or just
was used to manage IPP jobs,
respectively.  See "printer-controls-other-protocols" (section 4.4).

Access Rights: Authentication submit them to the Output Device.

        Table 7 - Pause and access control (see [ipp-mod] sections
1, 8.3, Resume Printer and 8.5) apply to this operation.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Device Operations      September 19, 1999

The Enable-Printer Request and Enable-Printer Response have the same
attribute groups

     Pause and attributes as the Resume-Printer operation (see
[ipp-mod] sections 3.2.8.1 Resume Printer   Description
     and 3.2.8.2), including Device Operations

     IPP/1.1 Pause Printer      Stops the IPP Printer from sending
                                new "printer-
message-from-operator" operation attribute (see section 3.1), and with IPP Jobs to the addition of Output Device(s)
                                either immediately or after the following Group 1 operation attribute
                                current job completes, depending on
                                implementation, as defined in [ipp-
                                mod].
     Pause-Printer-After-       Stops the
request:

  "job-type" (type2 keyword):
     The client OPTIONALLY supplies this attribute.  The IPP Printer object
     OPTIONALLY supports this attribute.  The value of this attribute
     indicates the type of job from sending
     Current-Job                new IPP Jobs to be enabled.  If the client omits this
     attribute, Output Device(s)
                                after the current jobs finish
     Resume-Printer             Starts the IPP Printer assumes sending IPP
                                Jobs to the 'network-jobs' value.

     Standard keyword values are:
          'network-jobs' - enable jobs submitted using Output Device again.
     Pause-Device-Now           Stops the create job
              operations.
          'walk-up-jobs' - enable jobs submitted locally, such as walkup 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 jobs
          'all-jobs' - enable all types 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

7.1.4 Reset-Printer operation

Type of registration: again.

Pause-Printer-After-Current-Job operation
Proposed name of this operation:  Reset-Printer
Object Target:  Printer
Specification of this operation:

This OPTIONAL operation allows a client to reset 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 a number the middle of ways, depending on sending an IPP job to
an Output Device or Subordinate Printer, the "reset-function" operation attribute.  The
keyword values 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 attribute map one-to-one to the enum values that operation, the NMS writes into IPP Printer MUST NOT start processing any
more jobs, so additional jobs MUST NOT enter the prtGeneralReset object in 'processing' state.

If the IPP Printer MIB
[RFC1759] is not sending an IPP Job to affect a reset operation.  As in the Output Device or
Subordinate Printer MIB, (whether or not the
'reset-to-nvram' (soft reset) value MUST be supported, if this operation
is supported.  The other values are OPTIONAL.

As Output Device or Subordinate
Printer is says in busy processing any jobs), the IPP Printer MIB specification, if a device does not have
NVRAM (non-volatile RAM), object transitions
immediately to the device MUST none-the-less respond 'stopped' state by setting its "printer-state"
attribute to this
operation for 'stopped', removing the 'moving-to-paused' value, if

                      Expires:  January 6, 2001

present, from its "printer-state-reasons" attribute, and adding the 'reset-to-nvram'
'paused' value with some sort of warm reset
that resets to its "printer-state-reasons" attribute.

If the device implementation will take appreciable time to some implementation-defined state complete sending an
IPP job that is
preferably under control of it has started sending to an Output Device or Subordinate
Printer, the system administrator by some means
outside IPP Printer adds the scope of 'moving-to-paused' value to the
Printer MIB and this document.

The effect 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 this operation on sending, the currently processing job(s), if any,
is not specified Printer object transitions to the
'stopped' state by this document.  Note:  If this 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.

This operation does MUST NOT affect the current job(s), it is expected acceptance of Job Creation requests
(see Disable-Printer section 0).

For any jobs that are 'pending' or 'pending-held', the operator would issue this
operation on a Printer in 'printer-stopped'
value of the 'idle' state after disabling jobs' "job-state-reasons" attribute also applies.  However,
the IPP Printer
with NEED NOT update those jobs' "job-state-reasons"
attributes and only need return the Disable operation in order to prevent a job from inadvertently
being affected by this operation. 'printer-stopped' value when those
jobs are queried using the Get-Job-Attributes or Get-Jobs operations
(so-called "lazy evaluation").

The IPP Printer object MUST accept this operation the request in any state and transition the
Printer object to the indicated new "printer-state" and MUST add the indicated
value to "printer-state-reasons" attribute before returning as follows:

     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

  'idle' state.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999       'stopped'    'paused'  REQUIRED:  'successful-ok'

  'processing' 'processing' 'moving-  OPTIONAL:  'successful-ok';
                              to-       Later, when the IPP Printer has
                              paused'   finished sending IPP jobs to an
                                        Output Device, the "printer-
                                        state" becomes 'stopped', and
                                        the 'paused' value replaces the
                                        'moving-to-paused' value in the
                                        "printer-state-reasons"
                                        attribute

  'processing' 'stopped'    'paused'  REQUIRED:  'successful-ok'; the
                                        IPP Printer wasn't in the middle
                                        of sending an IPP job to an
                                        Output Device

  'stopped'    'stopped'    'paused'  REQUIRED:  'successful-ok'

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).

                      Expires:  January 6, 2001

The Reset-Printer Pause-Printer-After-Current-Job Request and Reset-Printer Pause-Printer-After-
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 3.1), the new
"when" "printer-message-from-operator" operation
attribute (see section 3.4), 5).

11.3 Hold 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 Release New Jobs operations

This section defines operations to be
     performed.  If the client omits this attribute, condition 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. hold any new
jobs and to factory settings and/or values established at
              install time.

7.1.5 Restart-Printer operation

Type of registration: release them.

Hold-New-Jobs 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
previously been shutdown in standby mode (see section 7.1.7).  Standby
mode is indicated by condition the Printer's "printer-state" being 'stopped' and
its "printer-state-reasons" including Printer to
complete the 'standby' current 'pending' and 'paused' values.  'processing' IPP Jobs but not start
processing any subsequently created IPP Jobs.  If the IPP Printer is not in standby mode,
the middle of sending an IPP job to an Output Device or Subordinate
Printer, the IPP Printer MUST reject this
operation and return the 'client-error-not-possible' status code.

ISSUE 12:   What state does complete sending that Job.  Furthermore,
the IPP Printer comes back up on Restart-Printer
and how can MUST send all of the client control?
Possible alternatives:

     a. Restart-Printer always brings current 'pending' IPP Jobs to the
Output Device(s) or Subordinate IPP Printer up Disabled ("printer-
     is-accepting-jobs" = 'false') and Paused ("printer-state" =
     'stopped', and "printer-state-reasons" = 'paused') which is the
     state that Shutdown-Printer leaves object(s).  Any subsequently
received Job Creation operations will cause the IPP 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 put the simplest to implement, allows new states to be added

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

     without changing
Job into the Restart-Printer operation, and can have 'pending-held' state with the
     same GUI interface as b:

     b. Add a REQUIRED operation attribute 'job-held-on-create' value
being added to Restart-Printer, something
     like "printer-condition" with values: 'disabled-and-paused',
     'enabled-and-paused', and 'enabled-and-idle'.

  TH 7/26: Remove the Shutdown-Printer 'standby' mode concept.
  Shutdown-Printer always powers off eventually.  Also remove
  Restart-Printer operation job's "job-state-reasons" attribute.  Thus all together.  Instead change newly
accepted jobs will be automatically held by the
  Disable-Printer and Enable-Printer operations to Disable-Operations
  and Enable-Operations, so that individual operations are enabled
  and disabled independent Printer.

When the Printer completes all of the 'pending' and 'processing' jobs,
it enters the 'idle' state of as usual.  An operator that is monitoring
Printer state changes will know when the Printer has completed all
current jobs because the Printer and don't
  otherwise enters the 'idle' state.

This operation MUST NOT affect the state acceptance of Job Creation requests
(see Disable-Printer section 0), except to put the Printer.

  HRL 9/18: How can Jobs into the state
'pending-held' state, instead of the printer not be effected when you
  disable 'pending' or enable it? Don't understand 2nd half of this issue
  resolution.

If 'processing' state.

The IPP Printer MUST accept the Restart-Printer operation is supported, then request in any state, MUST NOT
transition the Shutdown-Printer
operation Printer to any other "printer-state", and MUST be supported, since add the Restart-Printer operation is
meaningful only after a Shutdown-Printer operation has been performed.
However, if
'hold-new-jobs' value to the Shutdown-Printer operation is supported, Printer's "printer-state-reasons" attribute
(whether the Restart-
Printer NEED NOT be supported.

  Issue 13: Why? This is backward, if you ask me (HRL). value was present or not).

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Restart-Printer Hold-New-Jobs Request and Restart-Printer Hold-New-Jobs Response have the same
attribute groups and attributes as the Resume-Printer Pause-Printer operation (see
[ipp-mod] sections 3.2.8.1 3.2.7.1 and 3.2.8.2), 3.2.7.2), including the new "printer-
message-from-operator" operation attribute (see section 3.1) and the
following Group 1 5).

Release-Held-New-Jobs operation attribute:

7.1.6 Non-Process-Run-Out Operation

ISSUE 14 - Can we think of

This OPTIONAL operation allows a name for Non-Process-Run-Out that follows client to undo 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 effect of this operation:  Non-Process-Run-Out
Object Target: a previous
Hold-New-Jobs operation.  In particular, the Printer releases all of the

                      Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

Specification  January 6, 2001

jobs that it had held as a consequence of this operation:

This OPTIONAL operation effectively moves a Hold-New-Jobs operations,
i.e., while the last printed sheet to 'hold-new-jobs' value was present in the
exit or stacker. The terminology is common Printer's
"printer-state-reasons" attribute.  In addition, the Printer MUST accept
this request in any state, MUST NOT transition the Printer to long path continuous forms
devices but may have applicability on shorter devices any other
"printer-state", and MUST remove the 'hold-new-jobs' value from its
"printer-state-reasons" attribute (whether the value was present or in cut-sheet
applications. not)
so that the Printer no longer holds newly created jobs.

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. operation must be an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Non-Process-Run-Out Release-Held-New-Jobs Request and Non-Process-Run-Out 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 3.1) 5).

11.4 Deactivate and the new "when" operation attribute (see section 3.4).

7.1.7 Shutdown-Printer Operation

Type of registration:  operation
Proposed name of this operation:  Shutdown-Printer
Object Target: Activate Printer
Specification of this operation: Operations

This section defines the OPTIONAL operation allows a client to shutdown a Printer, i.e.,
stop processing jobs Deactivate-Printer and power off in some implementation-dependent
manner.  The purpose of Shutdown-Printer is to shutdown the Printer for
an extended period, not to reset the device(s) or modify a Activate-
Printer
attribute.  See Reset-Printer (section 7.1.4) for the way to reset the
device(s).  See the Disable-Printer operation (section 7.1.2) for a way
for the client to operations that stop and start the IPP Printer object from
accepting Job Creation all requests
without stopping processing or shutting down.

The Printer is disabled immediately (see the Disable-Printer operation
in section 7.1.2).  The Printer adds the 'shutdown' value (see [ipp-mod]
section 4.4.11) to its "printer-state-reasons" Printer Description
attribute.  The "when" operation attribute specifies how much processing
occurs before the Printer is paused (see [ipp-mod] section 3.2.7) except queries and
the shutdown is complete.  All other requests continue to performing work.  If either of
these operations are supported, both MUST be accepted
until supported.

These operations allow the printer is powered down.

ISSUE 15 - Need operator to look at life cycle of put the Printer versus
standby/power-down into a dormant
read-only condition and the other to take it out of such a condition.  These
operations that can be accepted.  There
can be appreciable time between acceptance are a combination of this operation the Deactivate and when Pause operations,
plus preventing the final state acceptance of any other requests, except queries.

The Deactivate and Activate Printer Operations MUST NOT affect 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
submission of jobs using other job submission protocols to 'moving-to-paused').  Then the 'shutdown'
  values means that
associated Output Device; the shutdown has completed (and is only meaningful 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.

Deactivate-Printer operation

This OPTIONAL operation allows a server implementation that hosts client to stop the Printer object).  Thus the

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

  server can still respond object from
starting to a Get-Printer-Attributes operation after send IPP jobs to any of its Output Devices or Subordinate
Printers (Pause-Printer-After-Current-Job) and stop the Printer is shutdown as stated in IPP/1.1.

  HRL> Is this granularity really achievable enough of object
from accepting any, but query requests.  The Printer performs a Disable-
Printer and a wide enough
  variety Pause-Printer-After-Current-Job operation immediately,
including use of environments to be reliable or, in reality, will this all of the "printer-state-reasons" if these two
operations cannot be
  implementation dependent?

Whether or not completed immediately.  In addition, the Shutdown-Printer operation affects jobs 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 were
submitted to the device using partial job submission protocols other than IPP,
depends on implementation, i.e., on whether can be completed
- see section 0) and return 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). 'server-error-service-unavailable'
status code.

                      Expires:  January 6, 2001

The IPP Printer object MUST accept this operation the request in any state and
transition 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: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator of the
Printer object to the 'idle' state.

Access Rights: Authentication and access control (see [ipp-mod] sections
1, 8.3, Sections 1 and 8.5) apply to this operation. 8.5).

The Shutdown-Printer Deactivate-Printer Request and Shutdown-Printer Deactivate-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 3.1), the new
"when" operation attribute (see section 3.4), and with the addition of
the following Group 1 5).

Activate-Printer 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:
          '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)
     The OPTIONAL operation allows a 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 ("when" = 'now') with the pages that have
     actually printed.  If undo the value effects of the "when" attribute is not
     'now' or the "when" attribute is not supplied, then the
     "synchronize" attribute has no meaning and the Printer MUST ignore
     it.  If this attribute is supported, then a value of 'true' implies
     that
Deactivate-Printer, i.e., allow the Printer will be able object to resume the job at the point start sending IPP
jobs to any 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

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

     attribute.  In this case, check-pointing implies that the job may
     be resumed in the future, exactly from the point and in the state
     and resource context from which it left off.

     If the Printer supports this attribute but the client does not
     supply it, its Output Devices or Subordinate Printers (Pause-
Printer-After-Current-Job) and start the Printer is assumed to  perform synchronization
     ('true' behavior).  If object from accepting
any requests.  The Printer performs an Enable-Printer and a Resume-
Printer operation immediately.  In addition, the Printer does not support this attribute, MUST
immediately start accepting all requests.

The IPP Printer MUST accept the request in any state.  Immediately, the
Printer is assumed to not synchronize ('false' behavior).

     ISSUE 16:  Is MUST immediately remove the current job automatically restarted when 'deactivated' value from its
"printer-state-reasons" attribute (whether present or not).

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator of the
Printer is restarted?  Or does some client have to issue a Restart-
     Job operation? object (see [ipp-mod] Sections 1 and 8.5).

The question is moot, if we remove Activate-Printer Request and Activate-Printer Response have the Restart-Job operation, same
attribute groups and attributes as
  suggested:

  TH 7/26: Remove the Shutdown-Printer 'standby' mode concept.
  Shutdown-Printer always powers off eventually.  Also remove
  Restart-Printer Pause-Printer operation all together.  Instead change (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the
  Disable-Printer new "printer-
message-from-operator" operation attribute (see section 5).

11.5Restart-Printer, Shutdown-Printer, and Enable-Printer Startup-Printer operations to Disable-Operations

This section defines the OPTIONAL Restart-Printer, Shutdown-Printer, and Enable-Operations, so that individual
Startup-Printer operations are enabled that initialize, shutdown, and
  disabled independent of the state of startup the
Printer and don't otherwise
  affect the state object, respectively.  Each of the Printer.
  HRL> Then, how do we restart the printer?

7.2 Job Operations

All Job these operations are directed at Job objects.  A client MUST always
supply some means of identifying the Job object in order to identify the
correct target of the operation.  That job identification is OPTIONAL and
any combination MAY either be
a single Job URI or a combination of a Printer URI with a Job ID. supported.

The
IPP object implementation Restart-Printer, Shutdown-Printer, and Startup-Printer operations
MUST support both forms of identification for
every job.

7.2.1 Set-Job-Attributes

Type NOT affect the submission of registration: jobs using other job submission
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).

                      Expires:  January 6, 2001

Restart-Printer 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 restart a Printer object
whose operation is in need of initialization because of incorrect or
erratic behavior, i.e., perform the
attributes effect of a Job object.   In software re-boot.  The
implementation MUST attempt to save any information about Jobs and the request,
Printer object before re-initializing.  However, this operation MAY have
drastic consequences on the client supplies running system, so the
set operator should first
try the Deactivate-Printer to minimize the effect on the current state
of Job attribute names the system.  The effects of previous Disable-Printer, Pause Printer,
and values that Deactivate-Printer operations are lost.

The IPP Printer MUST accept the request in any state.  The Printer
object MUST initialize its Printer's "printer-state" to be set.  In 'idle', remove
the
response, state reasons from its "printer-state-reasons" attribute, and its
"printer-is-accepting-jobs" attribute to 'true'.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator of the IPP
Printer object returns success or rejects (see [ipp-mod] Sections 1 and 8.5).

The Restart-Printer Request and Restart-Printer Response have the request with
indications of which same
attribute or groups and attributes could not be set.

This as the Pause-Printer operation is almost identical to (see
[ipp-mod] sections 3.2.8.1 and 3.2.8.2), including the Set-Printer-Attributes new "printer-
message-from-operator" operation attribute (see section 7.1.1).  The only differences are that the Set- 5).

                      Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

Job-Attributes  January 6, 2001

Shutdown-Printer Operation

This OPTIONAL operation is directed at allows a Job object rather than client to shutdown a Printer, i.e.,
stop processing jobs and make the Printer object, there is object no "document-format" operation attribute used
when setting a Job object, and longer available for
any operations using the validation IPP protocol without losing any jobs.  There is
no way to bring the same as instance of the Printer object back to being used,
except for the create
job operations, i.e., depends on Startup-Printer (see section 0) which starts up a new
instance of the "xxx-supported" Printer Description
attributes. object for hosted implementations.  The validation purpose
of the Set-Job-Attributes request Shutdown-Printer is performed as if to shutdown the
job had been submitted originally with Printer for an extended period,
not to reset the new values device(s) or modify a Printer attribute.  See Restart-
Printer (section 0), Startup-Printer (section ), and with "ipp-
attribute-fidelity" set Reset-Device [ipp-
device-ops] for the way to 'true', i.e., all modified attributes 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
without stopping processing or shutting down.

The Printer MUST be
supported along with add the attributes not modified.  If such 'shutdown' value (see [ipp-mod] section 4.4.11)
immediately to its "printer-state-reasons" Printer Description attribute
and performs a create job Deactivate-Printer operation would (see section 0) which
performs a Disable-Printer and Pause-Printer-After-Current-Job
operation).

Note:  In order to shutdown the Printer after all the currently
submitted jobs have been accepted, then completed, the Set-Job-Attributes MUST be
accepted.  If such operator issues a create job Disable-Printer
operation would have been rejected, (see section 0) and then waits until all the Set-Job-Attributes MUST be rejected jobs have
completed and the Job MUST be unchanged. Printer goes into the 'idle' state before issuing the
Shutdown-Printer operation.

The IPP Printer object MUST accept or reject the request based on the job's
current this operation in any state and
transition the job to Printer object through the indicated new state as
follows:

   Current "job-    New "job-     IPP object's response status
       state"         state"             code "printer-states" 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 "printer-
state-reasons" defined for the Pause-Printer-After-Current-Job operation
until the attributes being set,
                                 whether activity is completed and the job has started
                                 marking media, and/or
                                 implementation
  'processing-    'processing-   'successful-ok' Printer object disappears.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or 'client-
  stopped'        stopped'       error-not-possible' depending on administrator of the attributes being set,
                                 whether
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Shutdown-Printer Request and Shutdown-Printer Response have 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 same
attribute groups and READ-ONLY Job Description attributes

If the Printer supports as the "job-message-from-operator" Job Description
attribute Pause-Printer operation (see
[ipp-mod] section 4.3.16) sections 3.2.7.1 and 3.2.7.2), including the new "printer-
message-from-operator" operation attribute (see section 5).

Startup-Printer operation

This OPTIONAL operation allows a client explicitly
supplies to startup an instance of a new value
Printer object, provided that there isn't one already instantiated.  The
purpose of Startup-Printer is to allow a hosted implementation of the
IPP Printer object (i.e., a Server that implements an IPP Printer on
behalf of a networked or local Output Device) to be started after the
host is available (by means outside this document).  See Restart-Printer
(section 0) and Reset-Device [ipp-device-ops] for the "job-message-from-operator" in way to initialize
the request,
then software or reset the Output Device(s) when the IPP Printer object
has already been instantiated.

                      Expires:  January 6, 2001

The host MUST set the "job-message-from-operator" Job attribute
to accept this new value.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999 operation only when the Printer object has not
been instantiated.  If the Printer supports object already exists, 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 host must
return 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 'client-error-not-possible' status code.

The remaining Job Description attributes MAY result of this operation MUST be settable using with the Set-
Job-Attributes operation, depending on implementation.

Whether or not Printer object's "printer-
state" set to 'idle', the Set-Job-Attributes operation affects jobs that are
submitted using job submission protocols other than IPP, depends on
implementation, i.e., on whether state reasons removed from its "printer-state-
reasons" attribute, and its "printer-is-accepting-jobs" attribute set to
'false'.  Then the IPP protocol is being used as operator can reconfigure the Printer before
performing an Enable-Printer operation.  However, when a
universal management protocol or just Printer is
first powered up, it is RECOMMENDED that its "printer-is-accepting-jobs"
attribute be set to manage IPP jobs, respectively.
See "printer-controls-other-protocols" (section 4.4). 'true' in order to achieve easy "out of the box"
operation.

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation.

7.2.1.2 Set-Job-Attributes Request

The following sets of attributes are part operation must be an operator or administrator 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
Printer object (see [ipp-mod] Sections 1 and Character Set: 8.5).

The "attributes-charset" Shutdown-Printer Request and Shutdown-Printer Response have the same
attribute groups 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) Pause-Printer operation attribute(s) which define (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the
     target for this new "printer-
message-from-operator" operation as described in [ipp-mod] section 3.1.5.

  Requesting User Name:
     The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
     by (see section 5).

                      Expires:  January 6, 2001

12 Definition of the Job Operations

All Job operations are directed at Job objects.  A client as described MUST always
supply some means of identifying the Job object in [ipp-mod] section 8.3.

Group 2: order to identify the
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 Attributes ID.  The client
IPP object implementation MUST supply a set support both forms of identification for
every job.

The Job attributes as defined Operations are summarized in [ipp-
     mod] section 4.2 Job Template Attributes ("xxx" attributes) and
     section 4.3 Job Description Attributes.  Each Table 8:

            Table 8 - Job attribute
     supplied in Group 2 replaces the value(s) operation Operation-Id assignments

  Operation Name  Operati Brief description
                  on-Id
  Reprocess-Job   0x??    Creates a copy of the corresponding Job
     attribute on the a completed target
                           job with a new Job object.  For attributes that can have
     multiple values (1setOf), all values supplied by ID and processes it
  Cancel-Current- 0x??    Cancels the client replace
     all values of current job on the corresponding target
  Job object attribute.

7.2.1.3 Set-Job-Attributes Response

The                      Printer object returns the following sets of attributes as part of or the Set-Job-Attributes Response:

Group 1: Operation Attributes

  Status Message:
     In addition to specified job if it is
                           the REQUIRED status code returned in every response, current job
  Suspend-        0x??    Suspends 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 current processing job on returning Unsupported
     Attributes.

     The attributes returned are the same as for
  Current-Job              the create operation
     with target Printer or the same new attribute values.  In specified job
                           if it is the case of attributes that
     are supported, but are not settable by current job, allowing
                           other jobs to be processed instead
  Resume-Job      0x??    Resume the implementation, i.e.,

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

     are not among suspended target job
  Promote-Job     0x??    Promote the values of pending target job to be
                           next after the Printer's "settable-attributes"
     Printer Description attribute (see section 4.1), current job(s) complete
  Redirect-Job    0x??    Redirect the target job to the
                           specified Printer object
     returns on 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 same server.
  Schedule-Job-   0x??    Schedule the "Encoding and Transport" document [IPP-PRO].  Its value
     indicates that target job immediately
  After                    after the attribute is either not settable or is not
     supported at all.

7.2.2 specified job, all other
                           scheduling factors being equal.

                      Expires:  January 6, 2001

12.1 Reprocess-Job Operation

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
processing completed, was canceled, or was aborted (see [ipp-mod]
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
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
"job-id" attributes and the new job's Job Description attributes that
accumulate job progress, such as "job-impressions-completed", "job-
media-sheets-completed", and "job-k-octets-processed", are initialized
to 0 as with any create job operation.  The target job moves to the Job
History after a suitable period, independent of whether one or more
Reprocess-Job operations have been performed on it.

If the Set-Job-Attributes operation is supported, then the "job-hold-
until" operation attribute MUST be supported with at least the
'indefinite' value, so that a client can modify the new job before it is
scheduled for processing using the Set-Job-Attributes operation.  After
modifying the job, the client can release the job for processing, by
using the Release-Job operation specifying the newly assigned "job-uri"
or "job-id" for the new job.

7.2.3

                      Expires:  January 6, 2001

12.2 Cancel-Current-Job Operation

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
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 is received, some media sheet pages might be printed before the job
is actually terminated.

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
current job in the 'processing' or 'processing-stopped' state;
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

                       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
others are unaffected.

Warning:  On a shared printer, there is a race condition.  Between the
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
authenticated to cancel the new job, the wrong job is canceled.  To
prevent this race from canceling the wrong job, the client MAY supply
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
the current job on the Printer, i.e., is not in the 'processing' or
'processing-stopped' states, the Printer MUST reject this operation and
return the 'client-error-not-possible' status code.  Otherwise, the
Printer cancels the specified job.

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. 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
same attribute groups and attributes as the Resume-Printer operation
(see [ipp-mod] section 3.2.8), including the new "job-message-from-
operator" operation attribute (see section 3.2), 5), with the addition of the
following Group 1 Operation attributes in the request:

  "job-id" (integer(1:MAX)):

     The client OPTIONALLY supplies this Operation attribute in order to
     verify that the identified job is still the current job on the
     target Printer object.  The IPP object MUST supports this operation
     attribute, if it supports this operation.

7.2.4 Pause-Current-Job

                      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
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
moves the current job or the target job to the 'processing-stopped'
state and sets the 'job-paused' 'job-suspended' value (see section 8.1) in the job's
"job-state-reasons" attribute and processes other jobs.

If the client does not supply a "job-id" operation attribute, the
Printer MUST accept the request and pause suspend the current job if there is
a current job in the 'processing' or 'processing-stopped' state;
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
'processing-stopped' states, all of them are paused. suspended.

Warning:  On a shared printer, there is a race condition.  Between the
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
authenticated to pause suspend the new job, the wrong job is paused. suspended.  To
prevent this race from pausing the wrong job, the client MAY supply 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 the
current job on the Printer, i.e., is not in the 'processing' or
'processing-stopped' states, the Printer MUST reject this operation and
return the 'client-
error-not-possible' 'client-error-not-possible' status code.  Otherwise, the
Printer pauses suspends the specified job and processed other jobs.

A paused job is resumed using the Resume-Job operation (see section
7.2.5).  If the Pause-Current-Job operation is supported, then the
Resume-Job operation MUST be supported, and vice-versa.

The Printer MUST reject a Release-Job Resume-Job request (and return the 'client-
error-not-possible') for a job that has been paused suspended , i.e., for a job
in
the 'processing-stopped' state, with the 'job-paused' value in its "job-
state-reasons" attribute.  The Hold-Job and Release-Job operations are
for holding and releasing held jobs, not pausing and resuming paused
jobs. the 'processing-stopped' state, with the 'job-suspended' value in its
"job-state-reasons" attribute.

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. 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).

                      Expires:  January 6, 2001

The Pause-Current-Job Suspend-Current-Job Request and Pause-Current-Job Suspend-Current-Job Response have
the same attribute groups and attributes as the Resume-Printer Pause-Printer operation
(see [ipp-mod] section 3.2.8 ), including the new "job-message-from-
operator" operation attribute (see section 3.2), the new "when"
operation attribute (see section 3.4), 5), with the addition of the
following Group 1 Operation attributes in the request:

  "job-id" (integer(1:MAX)):

     The client OPTIONALLY supplies this Operation attribute in order to
     verify that the identified job is still the current job on the
     target Printer object.  The IPP object MUST supports this operation
     attribute, if it supports this operation.

  "synchronize" (boolean)
     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 resume the target job and allow
other jobs to be processed instead. at the
point where it was suspended.  The Printer moves the target job to the
'pending' state and removes the 'job-paused' 'job-suspended' value from the job's
"job-state-reasons" attribute.

If the target job is not in the 'processing-stopped' state with the
'job-paused'
'job-suspended' value in the job's "job-state-reasons" attribute, the
Printer rejects MUST reject the request and returns return the 'client-error-not-possible' 'client-error-not-
possible' status code, since the job was not paused.

If the Resume-Job operation is supported, then the Pause-Current-Job
operation MUST be supported, and vice-versa. suspended.

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. 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
groups and attributes as the Release-Job operation (see [ipp-mod]
section 3.3.6), including the new "job-message-from-operator" operation
attribute (see section 3.2).

7.2.6 5).

                      Expires:  January 6, 2001

12.4 Promote-Job operation

This OPTIONAL operation allows a client to make the pending target job
be processed next after the current job completes.  This operation is
specially useful in a production printing environment where the operator
is involved in job scheduling.

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
current job(s) complete.  If the target job is not in the 'pending'
state, the Printer rejects the request and returns the 'client-error-
not-possible' status code.  The Printer returns the target job
immediately after the current job(s) in a Get-Jobs response (see [ipp-
mod] section 3.2.6) for the 'not-completed' jobs.

When the current job completes, is canceled, paused, suspended, or aborted, the
target of this operation is processed next.

If a client issues this request (again) before the target of the
operation of the original request started processing, the target of this
new request is scheduled before the previous job that was to be
processed next.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

Note:

IPP is specified not to require queues for job scheduling, since there
are other implementations implementation techniques for scheduling multiple jobs, such
as re-evaluating a criteria function for each job on a scheduling multiple jobs. cycle.
However, if an implementation does implement queues for jobs, then the Promote-
Job
Promote-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.

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. 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
groups and attributes as the Cancel-Job operation (see [ipp-mod] section
3.3.3), including the new "job-message-from-operator" operation
attribute (see section 3.2).

7.2.7 Space-Current-Job 5).

12.5 Redirect-Job operation

This OPTIONAL operation allows a client to repeat or skip redirect a specified
number of impressions for the current not-completed job on the target
to another Printer or on the
specified job if it same server.  Redirect-Job is defined to be a
Job Creation operation, along with the current job on Print-Job, Print-URI, and Create-
Job operations.  Thus all semantics that apply to Job Creation
operations also apply to this operation.  For example, the Printer.  The new Printer
repeats or skips
validates the indicated number job using all of impressions specified by the
"back-space" its "xxx-supported" attributes and either
accepts or "forward-space" operation attribute, respectively.  This
operation is typically supported in a continuous forms implementation
for synchronizing rejects the web after forms run out or media change. job.  If the client does not supply a "job-id" job is rejected, it remains in its

                      Expires:  January 6, 2001

original state before the Redirect-Job operation attribute, was attempted.  As an
other example, the Job inherits the defaults for the new Printer MUST accept this request in any state, whether or not there (since
the defaults aren't copied onto the Job object when it is created, but
are applied when the job is processed - see [ipp-mod]).  Finally, this
operation generates a
current job, and advance or backspace 'job-created' event as does any Job Creation
Operation.

In order to preserver the media "ipp-attribute-fidelity" semantics that the indicated number of
impressions specified by
original client supplied when the "back-space" or "forward-space" operation
attribute, respectively.  If more than one job is in was first created, each Job
Creation Operation copies the 'processing' or
'processing-stopped' states, "ipp-attributes-fidelity" (boolean)
operation attribute o the one that is marking is spaced and job as a Job Description attribute, if the
others are unaffected.

It
Redirect-Job operation is reasonable, although not MANDATORY), to perform Space-Current-Job
while supported.  Then the Printer "ipp-attribute-fidelity"
attribute is 'stopped', paused, or 'processing'.  Between re-used by the
time that a user issues this operation and new Printer during its acceptance, the current job might change to a different job.  To prevent this race from spacing
the wrong job, validation,
unless the client MAY supply performing the "job-id" Redirect-Job operation attribute
which is checked against the current job's job-id.  If supplies the
"ipp-attribute-fidelity" operation attribute.

This operation is limited to redirecting a job
identified by to another Printer on the "job-id" attribute is not
same server.  Thus the same copy of the current job MAY be used, depending on
implementation.  Also, depending on implementation, the
Printer, i.e., is not in the 'processing' or 'processing-stopped'
states, new Printer MAY
generate a new job-id and job-uri, or is not 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 has impressions in are associated with the media path even if job.

The Printer MUST accept this operation whenever the job has completed, is in the
'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.  Otherwise,  Whether the Printer
advances or backspaces the media accepts this operation when the indicated number of impressions
specified by job is in the "back-space"
'processing' or "forward-space" operation attribute,
respectively.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999 'processing-stopped' states depends on implementation.

Access Rights: Authentication and access control The authenticated user (see [ipp-mod] sections
1, 8.3, and 8.5) apply to section 8.3)
performing this operation. 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 Space-Current-Job Redirect-Job Request and Space-Current-Job Response have the same attribute groups and attributes
as the Resume-Printer Create-Job operation (see [ipp-mod] section 3.2.8), including 3.2.4), plus the new "job-message-from-
operator"
"job-message-from-operator" operation attribute (see section 3.2), with the addition of 5).  In
addition, the following Group 1 Operation operation attributes in are defined:

  Target:
     Either (1) the request: "printer-uri" (uri) plus "job-id" (integer(1:MAX)):

     The client OPTIONALLY supplies this Operation attribute in order to
     verify that the identified job is still (integer(1:MAX))
     or (2) the current job on "job-uri" (uri) operation attribute(s) which define the
     target Printer object.  The IPP object MUST supports for this operation
     attribute, if it supports this operation.

  "back-space" (integer(1:MAX)): as described in [ipp-mod] section 3.1.5.
     The client OPTIONALLY supplies this Operation attribute.  The IPP
     object OPTIONALLY supports MUST supply this operation attribute, if it is able
     to repeat impressions.

     If the client supplies a value that specifies more impressions than
     the job has performed, attribute and the job is positioned at Printer MUST support
     it.

  new-printer-uri (uri):
     The URI of another Printer on the beginning
     without any indication.

  "forward-space" (integer(1:MAX)): same server.  The client OPTIONALLY supplies MUST
     supply this Operation attribute. attribute and the Printer MUST support it.

                      Expires:  January 6, 2001
  ipp-attribute-fidelity (boolean):
     The IPP
     object OPTIONALLY supports client MAY supply this operation attribute, if it is able
     to skip impressions.

     If the client supplies a value that specifies more impressions than
     remain in the job, but the job is positioned at Printer MUST support
     it.  It indicates whether or not the end without any
     indication.

8. IANA Considerations

The operations and Job Template attributes in this registration proposal will be
published by IANA according to the procedures in RFC 2566 [rfc2566]
section 6.4 for operations with the following URL:

     ftp.isi.edu/iana/assignments/ipp/operations/set2.txt

9. Internationalization Considerations

This document has the same localization considerations as the [ipp-mod].

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

10. Security Considerations

The IPP Model and Semantics document [ipp-mod] discusses high level
security requirements (Client Authentication, Server Authentication and
Operation Privacy). Client Authentication is on the mechanism
     Job object MUST be supported by which the new Printer.  If the client proves its identity
     omits this attribute, the new Printer uses the value copied to the server in
     job as a secure manner. Server
Authentication is Job Description attribute when the mechanism job was originally
     created.  The Job Description attribute is not affected by which the server proves its identity
to the client
     value supplied in a secure manner. Operation Privacy this request, so that the original user's intent
     is defined preserved across multiple Redirect-Job operations.

The Redirect-Job Response has the same attribute groups, attributes, and
status codes as a
mechanism for protecting operations from eavesdropping.

11. Author's Addresses

   Carl Kugler
   IBM
   Boulder CA

   Phone: (303) 924-5060
   FAX:
   e-mail:  kugler@us.ibm.com

   Tom Hastings
   Xerox Corporation
   737 Hawaii St.  ESAE 231
   El Segundo, CA  90245

   Phone: 310-333-6413
   Fax: 310-333-5514
   e-mail: hastings@cp10.es.xerox.com

   Harry Lewis
   IBM
   Boulder CA

   Phone: (303) 924-5337
   FAX:
   e-mail:  harryl@us.ibm.com

12. References the Create-Job operation (see [ipp-mod]
     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]
     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

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

13. Change History

This section summarizes 3.2.4).
The following status codes have particular meaning for this operation:

  'client-error-not-possible' - the changes.  Each sub-section 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 reverse
chronological order.

13.1 Changes to the July 19, 1999 version to make
     'processing' or 'processing-stopped' states.
  'client-error-not-found' - the September 19, 1999
version

The following changes 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).

12.6 Schedule-Job-After operation

This OPTIONAL operation allows a client to request the July 19, 1999 version Printer to make
schedule the September
19, 1999 version as a result of target job so that it will be processed immediately after
the specified job, all other scheduling factors being equal.

IPP WG meeting in Alaska, 8/99:

1.Refer is specified not to proposal require queues for job scheduling, since there
are other implementation techniques for scheduling multiple jobs, such
as "Set2" rather than "Administrative" operations.

2.Revise the emphasis re-evaluating a criteria function for each job on administrator throughout a scheduling cycle.
However, if an implementation does implement queues for jobs, then the document,
  although
Schedule-Job-After operation puts the word administrator remains wherever appropriate.

3.Convert non-process-run-out from an operations attribute to an
  operation.

4.Added  Issue 21: For all these "access" caveats, why not just say...
  'authentication and access control (see ipp-mod sections 1, 8.3 and
  8.5) applies 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 this operation".?

5.Added Issue 22: Why? This be placed
after that job, even though it is backward, if you ask me (HRL).

6.Per resolution of Issue 2, between the "settable-attributes" Printer
  Description attribute, was replaced with three Printer Description
  attributes:  "printer-settable-attributes", "job-settable-
  attributes", first target job and "interpreter-settable-attributes".  The latter for
  those implementations that have different values for Printer
  attributes 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 Get-Printer-Attributes
target and Set-Printer-Attributes
  operations, depending on B as the value of specified job would result in the "document-format" operation
  attribute supplied by following queue:
A, B, E, C, D.  A subsequent Schedule-Job-After with Job D as the client.  If target
and when we get a Document
  object, then we can add a "document-settable-attributes" Printer
  Description attribute.

7.Added the Interpreter object.

13.2 Changes to B as the June 30, 1999 version to make specified job would result in the July 19, 1999
version

The following changes to queue:  A, B,
D, E, C.  In other words, the June 30, 1999 version to make link between the July 19,
1999 version as two jobs in a result Schedule-
Job-After is ephemeral, rather than setting an attribute of either of
the IPP WG meeting jobs.

If the target job is not in Copenhagen, 7/7/99-
7/8/99, and the IPP telecon, 7/14/1999:

1.Sections 2.1 'pending' state, the Printer MUST reject
the request and 2.2:  Clarified that returns the way to remove a message
  from 'client-error-not-possible' status code,
since the operator was for job cannot have its position changed.  The predecessor job can
be in the client to supply a zero-length 'pending', 'processing', or all 'processing-stopped' states.

                      Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 Operations      September 19, 1999

  white space text string which is copied as usual to the "xxx-message-
  from-operator" attribute.

2.Section 2.3:  Added "factory-settings" (boolean)  January 6, 2001

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation attribute
  to must be operator or administrator of the Get-Printer-Attributes operation.

3.Section 2.4:  Added
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Schedule-Job-After Request have the "when" operation same attribute to groups and
attributes as the Pause-
  Current-Job operation.

4.Section 2.4:  Made Cancel-Job operation (see [ipp-mod] section 3.3.3),
plus the "when" new "job-message-from-operator" operation attribute OPTIONAL for  use
  in operations (Pause-Printer, Reset-Printer, Shutdown-Printer, and
  Pause-Current-Job operations).

5.Sections 2.5:  Added table of operation attributes for (see
section 5).  In addition, the Printer
  operations to make it easy to compare.

6.Sections 2.6:  Added table of following operation attributes for the Job
  operations to make it easy to compare.

7.Section 3.1:  Added "settable-attributes" (1setOf type2 keyword)
  READ-ONLY Printer Description are
defined:

  "predecessor-job-id":
     The client OPTIONALLY supplies this attribute.

8.Section 3.2:  Added "printer-controls-other-protocols" (boolean)  The Printer Description MUST
     support it, if it supports this operation.  This attribute

9.Section 3.3:  Added
     specifies the READ-ONLY "printer-message-time"
  (integer(MIN:MAX)) Printer Description attribute job after which the target job is to keep time message
  updated in time ticks.

10.  Section 4.2:  Deleted be scheduled.
     If the 'process-next' "job-state-reasons" value,
  so that repeated Promote-Job operations promote each client omits this attribute, the Printer MUST schedule the
     target job "to next, i.e., after the
  front of current job, if any.

The Schedule-Job-After Response has the queue".

11.  Sections 6.1.1.1 same attribute groups,
attributes, and 6.2.1.1:  Replaced status codes as the table that listed all
  attributes with one that lists only Cancel-Job operation (see [ipp-mod]
section 3.3.3).  The following status codes have particular meaning for
this operation:

  'client-error-not-possible' - the attributes that MUST be READ-
  ONLY.

12.  Section 6.1.1.1:  Indicated that attributes that are target job was not specified
  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 'pending'
     state or the "ipp-attribute-fidelity"
  operation attribute from predecessor job was no in the Set-Printer-Attributes 'pending', 'processing',
     or 'processing-stopped' states.
  'client-error-not-found' - either the target job or the predecessor
     job was not found.

                      Expires:  January 6, 2001

13 Conformance Requirements

The Job and Set-Job-
  Attributes Printer Administrative operations defined in this document
are OPTIONAL operations.  All set  However, some operations MUST be implemented
if others are atomic.

14.  Section 6.1.1.2:  Add the concept of the Interpreter object to
  handle attributes whose values vary implemented as shown in Table 9.

     Table 9 - Conformance Requirement Dependencies for Operations

Operations REQUIRED    If any of these operations are supported:

Enable-Printer         Disable-Printer

Disable-Printer        Enable-Printer

Pause-Printer          Resume-Printer

Resume-Printer         Pause-Printer, Pause-Printer-After-Current-Job

Hold-New-Jobs          Release-Held-New-Jobs

Release-Held-New-Jobs  Hold-New-Jobs

Activate-Printer,      Deactivate-Printer
Disable-Printer,
Pause-Printer-After-
Current-Job

Deactivate-Printer,    Activate-Printer
Enable-Printer,
Resume-Printer

Restart-Printer        none

Shutdown-Printer       none

Startup-Printer        none

Reprocess-Job          none

Cancel-Current-Job     none

Resume-Job             Suspend-Current-Job

Suspend-Current-Job    Resume-Job

Promote-Job            none

Table 10 and Table 11list the Set-Printer-Attributes "printer-state-reasons" and
  Get-Printer-Attributes, depending on "job-state-
reasons" values that are REQUIRED if the value indicated operations are
supported.

   Table 10- Conformance Requirement Dependencies for "printer-state-
                            reasons" Values

"printer-state-       Conforman  If any of the "document-
  format" operation attribute.

                       Expires:  March 19, 2000

PWG-DRAFT             IPP/1.1: Set 2 following Printer
reasons" values:      ce         Operations      September 19, 1999

15.  Sections 6.1.1.3 and 6.2.1.2:  Changed the "out-of-band" 'not-
  settable' value back to are supported:
                      Requireme
                      nt

'paused'              REQUIRED   Pause-Printer, Pause-Printer-After-
                                 Current-Job, or Deactivate-Printer

'hold-new-jobs'       REQUIRED   Hold-New-Jobs

'moving-to-paused'    OPTIONAL   Pause-Printer, Pause-Printer-After-

                      Expires:  January 6, 2001
                                 Current-Job, Deactivate-Printer

'deactivated'         REQUIED    Deactivate-Printer

 Table 11- Conformance Requirement Dependencies for "job-state-reasons"
                                 Values

"job-state-reasons"   Conforman  If any of the existing 'not-supported' value.

16.  Section 6.1.2 following Job operations
values:               ce         are supported:
                      Requireme
                      nt

'job-suspended'       REQUIRED   Suspend-Current-Job

'printer-stopped'     REQUIRED   always REQUIRED

14 IANA Considerations

The operations and 6.1.3:  Added "job-type" operation attribute attributes in this registration proposal will be
published by IANA according to
  Disable-Printer and Enable-Printer the procedures in RFC 2566 [rfc2566]
section 6.4 for operations with values: 'network-
  jobs', 'walk-up-jobs', and 'all-jobs'.

17.  Section 6.1.5:  Clarified that Restart-Printer brings up the
  Printer disabled following URL:

     ftp.isi.edu/iana/assignments/ipp/operations/ipp-admin-ops.txt

15 Internationalization Considerations

This document has the same localization considerations as the [ipp-mod].

16 Security Considerations

The IPP Model and paused, since that Semantics document [ipp-mod] discusses high level
security requirements (Client Authentication, Server Authentication and
Operation Privacy). Client Authentication is the eventual state that
  Shutdown-Printer leaves the printer in.

18.  Section 6.1.5:  Indicated that if Restart-Printer is supported,
  then Shutdown-Printer MUST be supported.

19.  Section 6.1.6:  Deleted Space-Printer operation.  Keep Space-
  Current-Job operation only mechanism by which has a "job-id" operation attribute
  that a the
client MAY supply.

20.  Section 6.1.6:  Clarified that Shutdown-Printer is for a long
  period of time, not just proves its identity to reset the device or change attribute
  values.  Also that Shutdown performs an immediate Disable-Printer and
  an eventual Pause-Printer.

21.  Sections 6.2.3, 6.2.4, and 6.2.7 :  Added server in a "job-id" operation
  attribute secure manner. Server
Authentication is the mechanism by which the server proves its identity
to Cancel-Current-Job, Pause-Current-Job, and Space-
  Current-Job that a the client MAY supply to check for race condition
  where current job changes

22.  Section 6.2.4:  Combined Pause-Job into Pause-Current-Job
  operation.

23.  Sections 6.2.4 and 6.2.5:  Pause-Current-Job puts job in
  'processing-stopped' state, not 'pending-held' state.

24.  Section 6.2.6:  Simplified Promote-Job, so that it behaves a secure manner. Operation Privacy is defined as if
  the job were put at the front of the queue.

14. a
mechanism for protecting operations from eavesdropping.

17 Author's Addresses

   Carl Kugler
   IBM
   Boulder CO

   Phone: (303) 924-5060
   FAX:
   e-mail:  kugler@us.ibm.com

   Tom Hastings

                      Expires:  January 6, 2001
   Xerox Corporation
   737 Hawaii St.  ESAE 231
   El Segundo, CA  90245

   Phone: 310-333-6413
   Fax: 310-333-5514
   e-mail: hastings@cp10.es.xerox.com

   Harry Lewis
   IBM
   Boulder CO

   Phone: (303) 924-5337
   FAX:
   e-mail:  harryl@us.ibm.com

18 References

[ipp-device-ops]
     Kugler, C., Hastings, T., Lewis, H., "Internet Printing Protocol
     (IPP): Device Administrative Operations", <draft-ietf-ipp-ops-set3-
     00.txt>, December 8, 1999.

[ipp-iig]
     Hastings, T., Manros, C., "Internet Printing Protocol/1.1:  draft-
     ietf-ipp-implementers-guide-v11-01.txt, work in progress, May 9,
     2000.

[ipp-mod]
     R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
     "Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
     ipp-model-v11-07.txt>, May 22, 2000.

[ipp-pro]
     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.

[RFC2566]
     R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
     "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
     April 1999.

                      Expires:  January 6, 2001

19 Appendix A: Full Copyright Statement

Copyright (C) The Internet Society (1998,1999). All Rights Reserved

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
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
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
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

                      Expires:  March 19, 2000  January 6, 2001