INTERNET-DRAFT
Internet Printing Protocol WG                               Carl Kugler
<draft-ietf-ipp-ops-set2-01.txt>
INTERNET-DRAFT                                                 H. Lewis
<draft-ietf-ipp-ops-set2-02.txt>                        IBM Corporation
                                                   T. Hastings (editor)
Classification: Proposed Standard                     Xerox Corporation
                                                                H. Lewis
                                                         IBM Corporation
                                                            July 6,
                                                        August 15, 2000
                   Internet Printing 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].  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 is a submission to the Internet Printing Protocol Working
Group of the Internet Engineering Task Force (IETF).  After approval, it
is intended to be on the IETF standards track.  Comments should be
submitted to the ipp@pwg.org mailing list.

This document specifies 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].  : ipp-pro]:

Printer operations:                       Job operations:
Enable-Printer and Disable-Printer        Reprocess-Job
Pause-Printer-After-Current-Job           Cancel-Current-Job
Hold-New-Jobs and Release-Held- Release-Held-New-Jobs   Suspend-Current-Job and
                                          Resume-Job
New-Jobs
Deactivate-Printer and Activate- Activate-Printer   Promote-Job
Printer
Restart-Printer                    Redirect-Job                           Schedule-Job-After
Shutdown-Printer and Startup-      Schedule-Job-After
Printer Startup-Printer

New Job Description attributes:  "original-requesting-user-name"
New Printer Description attributes: "subordinate-printers-supported",
"parent-printers-supported", "subordinate-printers-supported" and "redirection-printers-supported".
"parent-printers-supported".
New "printer-state-reasons" values: 'hold-new-jobs' and 'deactivated'.
New "job-state-reasons" attribute values:  'job-suspended'.
New 'forwarded-operation-failed' event code. keyword:  'forwarded-operation-failed'.
New status code:  'server-error-printer-is-deactivated'.

                     Expires:  January 6,  February 15, 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.

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 [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]
  Internet Printing Protocol (IPP):  IPP Event Notification
     Specification [ipp-ntfy]

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: Model and Semantics", describes a
simplified model with abstract objects, their attributes, and their
operations that are independent of encoding and transport. It introduces
a Printer object and a Job object. The Job object optionally supports
multiple documents per Job. It also addresses security,
internationalization, and directory issues.

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

                     Expires:  February 15, 2001

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.

The "Internet Printing Protocol (IPP):  IPP Event Notification
Specification" document defines the semantics for Subscription Creation
Operations and the requirements for other Delivery Method documents to
define a Delivery Method to carry an Event Notifications to a
Notification Recipient.

                     Expires:  January 6,  February 15, 2001
                           Table of Contents

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

2  Terminology......................................................6  Terminology.........................................................6
 2.1 Conformance Terminology.......................................6 Terminology.........................................6
 2.2 Other terminology.............................................6 terminology...............................................6

3  Requirements and Use Cases.......................................7
 3.1 List of the Printer and Device Operations....................11

4  Use of the Printer object to represent IPP Printer fan-out and IPP
Printer fan-in.....................................................11
 4.1 IPP Printer Fan-Out..........................................12
 4.2 IPP Printer Fan-In...........................................12
 4.3 Printer object attributes used to represent Printer fan-out and
 Printer fan-in....................................................13
 4.4 Subordinate Printer URI......................................13
 4.5 Printer object attributes used to represent Output Device Fan-Out
     .............................................................14
 4.6 Figures to show all possible configurations..................15
 4.7 Forwarding requests..........................................17
  4.7.1  Forwarding requests that affect Printer objects..........17
  4.7.2  Forwarding requests that affect Jobs.....................18

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 uri).......................22
 6.3 redirection-printers-supported (1setOf uri)..................22

7  Additional Values for "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 codes........................................23
 10.1'server-error-printer-is-deactivated' (0x????)...............24

11  Definition of the Printer Operations...........................24
 11.1The Operations................................7
 3.1 The Disable and Enable Printer Operations....................26
  11.1.1 Operations.......................8
  3.1.1  Disable-Printer Operation................................26
  11.1.2 Operation                                    9
  3.1.2  Enable-Printer Operation.................................27
 11.2The Operation                                     9
 3.2 The Pause and Resume Printer Operations......................27
  11.2.1 Operations........................10
  3.2.1  Pause-Printer-After-Current-Job operation................28
 11.3Hold operation                   11
 3.3 Hold and Release New Jobs operations.........................30
  11.3.1 operations...........................12
  3.3.1  Hold-New-Jobs operation..................................30
  11.3.2 operation                                     12
  3.3.2  Release-Held-New-Jobs operation..........................30

                      Expires:  January 6, 2001
 11.4Deactivate operation                             13
 3.4 Deactivate and Activate Printer Operations...................31
  11.4.1 Operations.....................13
  3.4.1  Deactivate-Printer operation.............................31
  11.4.2 operation                                14
  3.4.2  Activate-Printer operation...............................32
 11.5Restart-Printer, operation                                  14
 3.5 Restart-Printer, Shutdown-Printer, and Startup-Printer operations
     .............................................................32
  11.5.1
     15
  3.5.1  Restart-Printer operation................................33
  11.5.2 operation                                   15
  3.5.2  Shutdown-Printer Operation...............................34
  11.5.3 Operation                                  16
  3.5.3  Startup-Printer operation................................34

12 operation                                   16

4  Definition of the Job Operations...............................36
 12.1Reprocess-Job Operation......................................37
 12.2Cancel-Current-Job Operation.................................38
 12.3Suspend Operations...................................17
 4.1 Reprocess-Job Operation........................................18
 4.2 Cancel-Current-Job Operation...................................18
 4.3 Suspend and Resume Job operations............................39
  12.3.1 operations..............................19
  4.3.1  Suspend-Current-Job operation............................39
  12.3.2 operation                               19
  4.3.2  Resume-Job operation.....................................40
 12.4Promote-Job operation........................................41
 12.5Redirect-Job operation.......................................41
 12.6Schedule-Job-After operation.................................43

13 operation                                        20
 4.4 Job Scheduling Operations......................................21
  4.4.1  Promote-Job operation                                       21
  4.4.2  Schedule-Job-After operation                                22

5  Additional status codes............................................23
 5.1 'server-error-printer-is-deactivated' (0x050A).................23

6  Use of Operation Attributes that are Messages from the Operator....23

7  New Printer Description Attributes.................................25
 7.1 subordinate-printers-supported (1setOf uri)....................25
 7.2 parent-printers-supported (1setOf uri).........................26

8  Additional Values for "printer-state-reasons"......................26
 8.1 'hold-new-jobs'................................................26
 8.2 'deactivated'..................................................26

9  Additional Values for "job-state-reasons"..........................26
 9.1 'job-suspended'................................................27

10 Additional events.................................................27

                     Expires:  February 15, 2001

11 Use of the Printer object to represent IPP Printer Fan-Out and IPP
Printer Fan-In........................................................27
 11.1IPP Printer Fan-Out............................................27
 11.2IPP Printer Fan-In.............................................28
 11.3Printer object attributes used to represent Printer Fan-Out and
 Printer Fan-In......................................................28
 11.4Subordinate Printer URI........................................28
 11.5Printer object attributes used to represent Output Device Fan-Out
     29
 11.6Figures to show all possible configurations....................30
 11.7Forwarding requests............................................32
  11.7.1 Forwarding requests that affect Printer objects             32
  11.7.2 Forwarding requests that affect Jobs                        33

12 Conformance Requirements.......................................45

14 Requirements..........................................35

13 IANA Considerations............................................46

15 Considerations...............................................36

14 Internationalization Considerations............................46

16 Considerations...............................36

15 Security Considerations........................................46

17 Considerations...........................................36

16 Author's Addresses.............................................46 Addresses................................................37

17 References........................................................37

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

19 Appendix A: Full Copyright Statement...........................48 Statement..............................38

                             List of Tables
Table 1 - List of Printer Operations and corresponding Device Operations
    .................................................................11 Operation Operation-Id assignments..................8
Table 2 - Forwarding operations that affect Pause and Resume Printer objects..........17 and Device Operations.............10
Table 3 - Forwarding operations that affect Jobs objects.............18 Job operation Operation-Id assignments.....................17
Table 4 - Operation attribute support for Printer Operations..........20 Operations.........24
Table 5 - Operation attribute support for Job operations.............21 operations.............24
Table 6 - Forwarding operations that affect Printer Operation Operation-Id assignments.................24 objects..........32
Table 7 - Pause and Resume Printer and Device Operations.............28 Forwarding operations that affect Jobs objects.............33
Table 8 - Job operation Operation-Id assignments.....................36
Table 9 - Conformance Requirement Dependencies for Operations........45 Operations........35
Table 10- 9 - Conformance Requirement Dependencies for "printer-state-
   reasons" Values..................................................45 Values..................................................36
Table 11- 10 - Conformance Requirement Dependencies for "job-state-reasons"
   Values...........................................................46
   Values...........................................................36

                            List of Figures
Figure 1 - Embedded Printer object...................................15 object...................................30
Figure 2 - Hosted Printer object.....................................15 object.....................................30
Figure 3 - Output Device fan out.....................................15

                      Expires:  January 6, 2001 Fan-Out.....................................30
Figure 4 - Chained IPP Printer.......................................16 Printer Objects...............................31
Figure 5 - IPP Printer fan out.......................................16 Object Fan-Out................................31
Figure 6 - IPP Printer fan in........................................16 Object Fan-In.................................31

                     Expires:  January 6,  February 15, 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-mod, ipp-pro]) focuses on end user
functionality with a few administrative operations included.  This
document defines additional OPTIONAL end user, operator, and
administrator operations used to control Jobs and Printers.  In
addition, this document extends the semantic model of the Printer object
by allowing them to be configured into trees and/or inverted trees that
represent Printer object Fan-Out and Printer object Fan-In,
respectively.  The special case of a tree with only a single Subordinate
node represents Chained 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  Terminology

This section defines terminology used throughout

The requirements and use cases for this document.

2.1 Conformance Terminology

Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, document are defined in [ipp-
ops-admin-req].  That document also includes requirements and use cases
for operations on the Device object which is the subject of a third
document [ipp-device-ops].  That [ipp-device-ops] document is not needed
in order to implement the operations defined in this document.

2  Terminology

This section defines terminology used throughout this document.

2.1 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 defined
conformance as specified in RFC 2119 [RFC2119] and [ipp-mod] section 12.1 on
12.1.  These terms refer to conformance terminology, most of which to this document or a particular
operation, if this document or operation is taken from RFC 2119 [RFC2119]. implemented.

The following specialization of these terms apply to this document:

  REQUIRED: if an implementation supports the extensions an operation described in
     this document, it MUST support a REQUIRED feature. feature described with
     that operation.
  OPTIONAL: if an implementation supports the extensions an operation described in
     this document, it MAY support an OPTIONAL feature. feature described with
     that operation.

2.2 Other terminology

This document uses terms such as "attributes", "keywords", and
"support".  These terms have special meaning and are defined in the
model terminology [ipp-mod] section 12.2.

                     Expires:  February 15, 2001

In addition, the following capitalized terms are defined. defined:

  IPP Printer object (or Printer for short) - a software abstraction
     defined by [ipp-mod].

  Printer Operation - an operation whose target is an IPP Printer
     object and whose effect is on the Printer object.

  Output Device - the physical imaging mechanism that an IPP Printer
     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 whose target is an IPP Printer object
     and whose defined effect is on an Output Device. in this document (or [ipp-mod]).

  Output Device Fan-Out - a configuration in which an IPP Printer
     controls more that one output-device.

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

                      Expires:  January 6, 2001

  Printer fan-in Fan-In - a configuration in which an IPP Printer object is
     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  Definition of the "Job and Printer
Administrative Operations" (this document)and the "Device Administrative
Operations" (see [ipp-device-ops]).  The requirements Operations

All Printer Operations are presented here
together to show the parallelism.

1.Have separate operations for affecting the IPP directed at Printer versus
  affecting the Output Device, so its clear what objects.  A client MUST
always supply the intent of each is
  and implementers can implement one or "printer-uri" operation attribute in order to identify
the other or both.

2.Support fan-out of Printer objects.

3.Support fan-out of Output Devices.

4.Support fan-in correct target of Printer objects, as long as it doesn't make the
  semantics more complicated when not supporting fan-in.

5.Support fan-in operation.  These descriptions assume all of output objects, as long as it doesn't make
the common semantics more complicated when not supporting fan-in.

6.Instead of having operation attributes that alter the behavior of the
  operation significantly, have separate operations, so that it is
  simple and clear to a client which semantics the Printer is
  supporting (by querying the "operations-supported" attribute) IPP/1.1 Model and it
  is simple to describe the capabilities of a Semantics document [ipp-mod]
section 3.1.

                     Expires:  February 15, 2001

The Printer implementation Operations defined in
  written documentation (just list the OPTIONAL operations supported).

7.Need a this document are summarized in Table
1:

          Table 1 - Printer Operation to prevent a Printer object from accepting
  new IPP jobs, but currently accepted jobs continue unaffected to be
  scheduled and processed.  Need a companion one to restore Operation-Id assignments

  Operation Name  Operati Brief description
                  on-Id
  Enable-Printer  0x22    Allows the target Printer
  object to accept new IPP jobs.

  Usage:  Operator is preparing to take Job
                           Creation operations
  Disable-Printer 0x23    Prevents the IPP target Printer out of service
  or to change the configuration of the IPP  Printer.

  Suggested name and operations:  Disable-Printer and Enable-Printer

                      Expires:  January 6, 2001

8.Need a Device Operation to prevent an Output Device from
                           accepting
  any new jobs from any job submission protocol and a companion one to
  restore the Output Device to accepting any jobs.

  Usage:  Operator is preparing to take Job Creation operations
  Pause-Printer-  0x24    Pause the Output Device out of
  service.

  Suggested name and operations:  Disable-Device and Enable Device

9.Need a Printer Operation to stop the processing after the current IPP job completes and not start processing any additional IPP jobs
  (either by scheduling the jobs or sending them
  After-Current-           has been sent to the Output Device),
  but continue to accept new IPP Device.
  Job
  Hold-New-Jobs   0x25    Finishes processing all currently
                           pending jobs.  Need a companion operation to
  start processing/sending IPP  Any new jobs again.

  Usage:  Operator wants to gracefully stop are placed
                           in the IPP Printer at 'pending-held' state.
  Release-Held-   0x26    Release all jobs to the next
  job boundary. The Pause-Printer-After-Current-Job operation is also
  invoked implicitly 'pending' state
  New-Jobs                 that had been held by the Deactivate-Printer effect of a
                           previous Hold-New-Jobs operation and
                           condition the Shutdown-Printer
  Operations.

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

10.  Need a Device Operation Printer to stop the processing the current job
  "immediately", no matter what protocol.  Its like the Pause button on longer hold
                           new jobs.
  Deactivate-     0x27    Puts the Output Device.  This operation is for emergencies.  The stop
  point depends on implementation, but can be mid page, end of page,
  end of sheet, or after a few sheets for Output Devices that can't
  stop that quickly.  The paper path isn't run out.  Need Printer into a companion
  operation to start processing read-only
  Printer                  deactivated state.
  Activate-       0x28    Restores the current any-protocol job without
  losing any thing.

  Usage:  Operator sees something bad about Printer to happen, such as normal activity
  Printer
  Restart-Printer 0x29    Restarts the
  paper is about to jam, or target Printer and re-
                           initializes the toner is running out, or software
  Shutdown-       0x2A    Shuts down the device is
  overheating or wants to add more paper.

  Suggested name and operations:  Pause-Device-Now, Resume-Device

11.  Need a target Printer Operation to stop so that
  Printer                  it cannot be restarted or queried
  Startup-Printer 0x2B    Starts up the processing of IPP jobs after
  all instance of the currently accepted jobs have been processed, but any newly
  accepted jobs go into the 'processing-held' state.

  Usage:  This allows an operator to reconfigure Printer
                           object

All of the Output Device operations in
  order to let jobs that this document are held waiting OPTIONAL for resources, such as
  special media, an IPP object to get a chance.  Then
support.  Unless the operator uses another specification of an OPTIONAL operation after reconfiguring.  He repeats requires
support of another OPTIONAL operation, conforming implementations may
support any combination of these operations.  Many of the two operations to
  restore
come in pairs and so both are REQUIRED if either one is implemented.

3.1 The Disable and Enable Printer Operations

This section defines the Output Device to its normal media.

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

12.  Need a Device Operation to Enable-Printer
operations that stop and start the processing the current any-
  protocol job at a convenient point, such as after the current copy
  (or end IPP Printer object from accepting new
IPP jobs.  If either of job if last or only copy).  Need a companion operation to

                      Expires:  January 6, 2001
  start processing these operations are supported, both MUST be
supported.

These operations allow the current any-protocol job or next job without
  losing any thing.

  Usage:  The operator wants to empty control whether or not the output bin that is near full.
  The paper path is run out.

  Suggested name
Printer will accept new Job Creation (Print-Job, Print-URI, and operations:  Pause-Device-After-Current-Copy,
  Resume-Device

13.  Need a Device Operation that always pauses on a device-defined
  boundary, Create-
Job) operations.  These operations have 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 wants to empty other effect on the output bin Printer,
so that is near full,
  but he doesn't want to break up a job in case it has multiple copies.
  The paper path is run out.

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

14.  Need a the Printer Operation that combines Disable-Printer, Pause-
  Printer-After-Current-Job, and rejects continues to accept all other Job, Printer, and
  Device Operations, except Job and Printer queries, System
  Administrator Set-Printer-Attributes, operations and the companion operation
continues to
  resume activity. schedule and process jobs normally.  In other words, this these
operation makes the Printer a
  read-only object in a graceful manner for end-users and control the operator.

  Usage:  The administrator wants "input of new jobs" to reconfigure the IPP Printer object
  using while the Set-Printer-Attributes operation without disturbing

                     Expires:  February 15, 2001

Pause and Resume operations (see section 3.2) independently control the
  current in process work, but wants to make sure that
"output of new jobs" from the operator
  isn't also trying IPP Printer to change the Printer object as part Output Device.

The Disable-Printer and Enable-Printer operations MUST NOT affect the
submission of running jobs using other job submission protocols to the
  Printer.

  Suggested name
associated Output Device; the Disable and operation:  Deactivate-Printer, Activate-Printer

15.  Need a Enable Device Operation that combines Disable-Device, Pause-Device-
  After-Current-Job, and rejects all other Device Operations, except
  Job and Printer queries and the companion operation Operations (see
[ipp-device-ops]) are intended to resume
  activity.  In other words, this operation makes stop the acceptance of all jobs by the
associated Output Device a
  read-only object in Device(s).

3.1.1 Disable-Printer Operation

This OPTIONAL operation allows a graceful manner.

  Usage:  The field service person wants to open up the device without
  disturbing the current in process work, perhaps client to replace staples,
  or replace stop the toner cartridge.

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

16.  Need a Printer Operation to recover object from
accepting new jobs, i.e., cause the IPP Printer software
  that has gotten confused (run out of heap memory or gotten into a
  state that it doesn't seem to be able to get out of).  This is a
  condition that shouldn't happen, but does in real life.  Any volatile
  information is saved if possible before the software is re-

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

  Usage: 'server-error-not-accepting-jobs'
status code.  The IPP Printer software has gotten confused or isn't
  responding properly.

  Suggested name still accepts all other operations, including
Validate-Job, Send-Document and operation:  Restart-Printer

17.  Need Send-URI operations.  Thus a Device Operation to recover from the Output Device hardware
  and software that has gotten confused (gotten into Disable-
Printer operation allows a state that it
  doesn't seem to be able client to get out of, run out continue submitting multiple
documents of heap memory, etc.).
  This is a condition that shouldn't happen, but does in real life.
  This is the same and has the same options as multiple document job if the Printer MIB reset.
  No companion Create-Job operation is needed to undo this.  We don't want to go
  back to the "confused" state :-).

  Usage:  The Output Device has gotten confused had
already been accepted.  All previously created or need resetting to
  some initial conditions.

  Suggested name submitted Jobs and operation:  Reset-Device

18.  Need a Printer Operation to put the
currently processing Jobs continue unaffected.

The IPP Printer object out of
  business with no way MUST accept the request in any state.  The Printer sets
the protocol to bring that instantiation back
  to life (but see Startup-Printer which brings up exactly one new
  instantiation value of its "printer-is-accepting-jobs" READ-ONLY Printer
Description attribute to life with 'false' (see [ipp-mod] section 4.4.20), no
matter what the same URL).  Any volatile information
  is saved if possible.

  Usage:  The Printer is being moved previous value was.  This operation has no immediate or
direct effect on the building's power is being
  shut off.

  Suggested name Printer's "printer-state" and operation:  Shutdown-Printer

19.  Need a Printer Operation to bring "printer-state-
reasons" attributes.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an IPP operator or administrator of the
Printer to life when there
  is an already running host.

  Usage:  After object (see [ipp-mod] Sections 1 and 8.5).

The Disable-Printer Request and Disable-Printer Response have the host is started (by means outside same
attribute groups and attributes as the IPP
  protocol), Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the operator is able new "printer-
message-from-operator" operation attribute (see section 6).

3.1.2 Enable-Printer Operation

This OPTIONAL operation allows a client to ask start the host to bring up any
  number of Printer objects (that object
accepting jobs, i.e., cause the host has been configured in some
  way) each with distinct URLs.

  Suggested name and operation:  Startup-Printer

20.  Need a Device Operation Printer to power off the Output Device after
  writing out any software state.  It is assumed that accept subsequent Job
Creation operations.  The Printer still accepts all other operations
  have more gracefully prepared the Output Device for this drastic operations.
All previously submitted Jobs and
  immediate.  There is no companion Device Operation to bring the power
  back on.

  Usage: currently processing Jobs continue
unaffected.

The Output Device is going to be moved, IPP Printer MUST accept the power request in any state.  The Printer sets
the
  building is going value of its "printer-is-accepting-jobs" READ-ONLY Printer
Description attribute to be shutoff, 'true' (see [ipp-mod] section 4.4.20), no
matter what the repair man previous value was.  This operation has arrived and needs
  to take no immediate or
direction effect on the Output Device apart.

  Suggested name Printer's "printer-state" and operation:  Power-Off-Device "printer-state-
reasons" attributes.

                     Expires:  January 6,  February 15, 2001

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

  Usage:  After a Power-Off-Device, if the device can

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be powered back
  up (possibly by an intervening host that supports the Device
  Operation).

  Suggest name and operation:  Power-On-Device

3.1 List operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and Device Operations 8.5).

The list of Printer Enable-Printer Request and Enable-Printer Response have the corresponding Device Operations is shown in
Table 1:

Table 1 - List of Printer Operations same
attribute groups and corresponding Device Operations

     Printer Operation            Corresponding Device Operation
                                  equivalent
                                  (see [ipp-device-ops])

     Disable-Printer              Disable-Device

     Enable-Printer               Enable-Device attributes as the Pause-Printer (IPP/1.1 -     Pause-Device-Now operation (see
[ipp-mod] - one
     interpretation)

     no                           Pause-Device-After-Current-Copy

     Pause-Printer-After-Current- Pause-Device-After-Current-Job
     Job

     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 Operations sections 3.2.8.1 and
Device Operations.  Either MAY be supported without supporting the
corresponding operations.

4  Use of 3.2.8.2), including the Printer object to represent IPP Printer fan-out new "printer-
message-from-operator" operation attribute (see section 6).

3.2 The Pause and IPP Resume Printer fan-in Operations

This section defines how leaves the Printer object MAY OPTIONAL IPP/1.1 Pause-Printer (see [ipp-mod]
sections 3.2.7) to be used ambiguous as to represent IPP whether or not it stops the
Printer fan-out immediately or after the current job and IPP Printer fan-in.  Fan-out is where an IPP Printer

                      Expires:  January 6, 2001

is used defines the OPTIONAL
Pause-Printer-After-All-Current-Jobs operation to represent other be after the current
job.  These operations affect the scheduling of IPP jobs.  If either of
these Pause Printer objects.  Fan-in is where several
IPP Printer objects operations are used supported, then the Resume-Printer
operation MUST be supported.

These operations allow the operator to represent another IPP control whether or not the
Printer object.

4.1 will send new IPP Printer Fan-Out

The IPP/1.1 Model and Semantics introduces jobs to the associated Output Device(s) that
the semantic concept of an IPP Printer object represents.  These operations have no other
effect on the Printer, so that represents more than one the Printer continues to accept all
operations.  In other words, these operation control the "output of new
jobs" to the Output Device Device(s) while the Disable and Enable Printer
Operations (see
[ipp-mod] section 2.1).  This concept is called "Output Device Fan-Out".
However, there was no way to represent 3.1) independently control the individual states "input of new
jobs" to the
Output Devices or IPP Printer.

The Pause and Resume Printer Operations MUST NOT affect jobs that were
submitted using other job submission protocols to perform operations on a specific the associated Output
Device; the Pause and Resume Device when
there was fan-out.  This document generalizes Operations (see [ipp-device-ops])
are intended to stop the semantics acceptance of all jobs by the
Printer object to represent such Subordinate fan-out associated Output Devices as
IPP Printer objects.
Device(s).

This concept is called "Printer object fan-out".
A Printer object that has a Subordinate Printer object is called a Non-
Leaf Printer object.  Thus a Non-Leaf Printer object supports one or
more Subordinate Printer objects document and [ipp-device-ops] define distinct operations in order
to represent Printer object
fan-out. A Printer object that does not have any Subordinate Printer
objects is called a Leaf disambiguate the Pause-Printer operation as shown in Table 2.  The
Printer object.

Each Non-Leaf Printer object submits Operations affect only Jobs submitted using IPP, while the
Device Operations affect all jobs no matter what job submission protocol
was used to its immediate Subordinate
Printers submit them to the Output Device.

        Table 2 - Pause and otherwise controls Resume Printer and Device Operations

     Pause and Resume Printer   Description
     and Device Operations

     IPP/1.1 Pause Printer      Stops the Subordinate Printers using IPP or
other protocols.  Whether pending jobs are kept in the Non-Leaf Printer
until a Subordinate Printer can accept them from sending
                                new IPP Jobs to the Output Device(s)
                                either immediately or are kept in after the
Subordinate Printers depends
                                current job completes, depending on implementation and/or configuration
policy.  Furthermore, a Subordinate Printer object MAY,
                                implementation, as defined in turn, have
Subordinate Printer objects.  Thus a Printer object can be both a Non-
Leaf [ipp-
                                mod].
     Pause-Printer-After-       Stops the IPP Printer from sending
     Current-Job                new IPP Jobs to the Output Device(s)

                     Expires:  February 15, 2001
     Pause and a Subordinate Printer.

A Subordinate Printer object MUST be a conforming Resume Printer object, so it
MUST support all of the REQUIRED operations   Description
     and attributes.  However,
with access control, Device Operations

                                after the Subordinate current jobs finish
     Resume-Printer             Starts the IPP Printer MAY be configured so that
end-user clients are not permitted sending IPP
                                Jobs to perform any operations (or just
Get-Printer-Attributes) while one or more Non-Leaf the Output Device again.

3.2.1 Pause-Printer-After-Current-Job operation

This OPTIONAL operation allows a client to stop the Printer object(s) are
permitted object from
starting to send IPP jobs to perform any operation.

4.2 of its Output Devices or Subordinate
Printers.  If the IPP Printer Fan-In

The IPP/1.1 Model and Semantics did not preclude is in the semantic concept middle of
multiple sending an IPP Printer objects that represent a single job to
an 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 or Subordinate device.  This specification
generalizes Printer, the semantics of IPP Printer MUST complete
sending that Job.  However, after receiving this operation, the IPP
Printer object MUST NOT start to allow several Non-
Leaf send any additional IPP Printer objects jobs to represent a single Subordinate Printer
object.  Thus a Non-Leaf Printer object MAY share a Subordinate Printer
object with one any of its
Output Devices or more other Non-Leaf Printer objects in order to
represent Subordinate Printers.  In addition, after having
received this operation, the IPP Printer fan-in.

As with fan-out (see section 4.1), when a Printer object is a Non-Leaf
Printer, it MUST NOT have an associated Output Device.  As with fan-out,
a Leaf Printer object has one or start processing any
more associated Output Devices.  As
with fan-out, the Non-Leaf Printer objects submit jobs, so additional jobs to their

                      Expires:  January 6, 2001

Subordinate Printer objects and otherwise control MUST NOT enter the Subordinate
Printer.  As with fan-out, whether pending jobs are kept in 'processing' state.

If the Non-Leaf
Printers until IPP Printer is not sending an IPP Job to the Output Device or
Subordinate Printer can accept them (whether or are kept in not the Output Device or Subordinate
Printer depends on implementation and/or configuration
policy.

4.3 is busy processing any jobs), the IPP Printer object attributes used to represent Printer fan-out and
    Printer fan-in

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

1."subordinate-printers-supported" (1setOf uri) - contains the URI of
  the immediate Subordinate Printer object(s).

2."parent-printers-supported (1setOf uri) - contains 'stopped' state by setting its "printer-state"
attribute to 'stopped', removing the URI of 'moving-to-paused' value, if
present, from its "printer-state-reasons" attribute, and adding the
  Non-Leaf printer object(s) for which this Printer object is
'paused' value to its "printer-state-reasons" attribute.

If the
  immediate Subordinate, i.e., this Printer's immediate "parent" implementation will take appreciable time to complete sending an
IPP job that it has started sending to an Output Device or
  "parents".

4.4  Subordinate Printer URI

Each Subordinate Printer object has a URI which is used as the target of
each operation on
Printer, the Subordinate Printer.  The means for configuring
URIs for Subordinate IPP Printer objects is implementation-dependent as are
all URIs.  However, there are two distinct approaches:

     a. When adds the implementation wants 'moving-to-paused' value to make sure that no operation on
     a Subordinate Printer object as a target "sneaks by" the parent
Printer object (or object's "printer-state-reasons" attribute (see section [ipp-
mod] 4.4.12).  When the Subordinate IPP Printer is fronting for a device has completed sending IPP jobs that is not networked), the host part of the URI specifies
it was in the host process of sending, the parent Printer.  Then the parent Printer object can easily
     reflect transitions to the
'stopped' state of the Subordinate Printer objects in by setting its "printer-state" attribute to 'stopped',
removing the
     parent's Printer object state 'moving-to-paused' value, if present, from its "printer-
state-reasons" attribute, and state reasons as adding the 'paused' value to its "printer-
state-reasons" attribute.

This operation
     passes "through" MUST NOT affect the parent Printer object.

     b. When the Subordinate Printer is networked and the implementation
     allows operations to go directly to the Subordinate Printer (with
     proper access control) without knowledge acceptance of Job Creation requests
(see Disable-Printer section 3.1.1).

For any jobs that are 'pending' or 'pending-held', the parent Printer
     object, the host part 'printer-stopped'
value of the URI is different than the host part of jobs' "job-state-reasons" attribute also applies.  However,
the parent IPP Printer object.  In such a case, NEED NOT update those jobs' "job-state-reasons"
attributes and only need return the parent '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 keep its "printer-state" accept the request in any state and "printer-state-reasons" up
     to date, either by polling transition the Subordinate
Printer object or by
     subscribing to events with the Subordinate Printer object (see
     [ipp-not-spec] for means to subscribe to event notification when indicated new "printer-state" and MUST add the Subordinate Printer object supports IPP notification). indicated
value to "printer-state-reasons" attribute before returning as follows:

                     Expires:  January 6,  February 15, 2001

4.5
     Current        New      "printer IPP Printer's response status
    "printer-    "printer-   -state-  code and action:
     state"       state"    reasons"
                                        REQUIRED/OPTIONAL state
                                        transition for a Printer object attributes used to represent Output Device Fan-Out

Only Leaf
                                        support

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

  'processing' 'processing' 'moving-  OPTIONAL:  'successful-ok';
                              to-       Later, when the IPP Printer objects are allowed has
                              paused'   finished sending IPP jobs to have one or more associated an
                                        Output Devices.  Each Leaf Printer object MAY support Device, the "output-
devices-supported" (1setOf name(127)) to indicate "printer-
                                        state" becomes 'stopped', and
                                        the user-friendly
name(s) of 'paused' value replaces the Output Device(s) that
                                        'moving-to-paused' value in the Leaf Printer object represents.
It is RECOMMENDED that each Leaf
                                        "printer-state-reasons"
                                        attribute

  'processing' 'stopped'    'paused'  REQUIRED:  'successful-ok'; the
                                        IPP Printer object have only one associated
Output Device, so that wasn't in the individual middle
                                        of sending an IPP job to an
                                        Output Devices can Device

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

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be represented
completely an operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and controlled completely by clients.  In other words, 8.5).

The Pause-Printer-After-Current-Job Request and Pause-Printer-After-
Current-Job Response have the
Leaf Printer's "output-devices-supported" same attribute SHOULD have only one
value.

Non-Leaf 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 6).

3.3 Hold and Release New Jobs operations

This section defines operations to condition the Printer MUST NOT have associated Output Devices.  However, to hold any new
jobs and to release them.

3.3.1 Hold-New-Jobs operation

This OPTIONAL operation allows a
Non-Leaf client to condition the Printer SHOULD support an "output-devices-supported" (1setOf
name(127)) to
complete the current 'pending' and  'processing' IPP Jobs but not start
processing any subsequently created IPP Jobs.  If the IPP Printer Description attribute that contains all is in
the values middle of
its immediate Subordinate Printers.  Since such Subordinate Printers MAY
be Leaf sending an IPP job to an Output Device or Non-Leaf, Subordinate
Printer, the same rules apply to them, etc.  Thus any Non-
Leaf IPP Printer SHOULD have an "output-devices-supported" (1setOf
name(127)) attribute MUST complete sending that contains all Job.  Furthermore,
the values IPP Printer MUST send all of the current 'pending' IPP Jobs to the
Output Devices
associated with Leaf Printers of its complete sub-tree.

When adding, removing, Device(s) or changing a configuration of Printers and
Output Devices, there can be moments in time when Subordinate IPP Printer object(s).  Any subsequently
received Job Creation operations will cause the tree structure is
not consistent.  In other words, times when a Non-Leaf Printer's
"subordinate-printers-supported" does not agree with IPP Printer to put the Subordinate
Printer's "parent-printers-supported".   Therefore,
Job into the operator SHOULD
first Deactivate all Printers that are 'pending-held' state with the 'job-held-on-create' value
being configured in this way,
update added to the job's "job-state-reasons" attribute.  Thus all pointer attributes, and then reactivate.  A useful client
tool would validate a tree structure before Activating newly
accepted jobs will be automatically held by the Printers
involved. Printer.

                     Expires:  January 6,  February 15, 2001

4.6 Figures to show

When the Printer completes all possible configurations

Figure 1, Figure 2, and Figure 3 are taken from [ipp-mod] to show of the
configurations possible with IPP/1.0 'pending' and IPP/1.1 where all Printer
objects are Leaf Printer objects.  The remaining figures show additional
configurations 'processing' jobs,
it enters the 'idle' state as usual.  An operator that this document defines using Non-Leaf and Leaf is monitoring
Printer objects. Legend for state changes will know when the Printer has completed all figures:

----> indicates a network protocol with
current jobs because the direction Printer enters the 'idle' state.

This operation MUST NOT affect the acceptance of its Job Creation requests

##### indicates a Printer object which is either:
        - embedded in an Output Device
(see Disable-Printer section 3.1.1), except to put the Jobs into the
'pending-held' state, instead of the 'pending' or
        - hosted in a server. 'processing' state.

The IPP Printer object
      might or might not be capable of queuing/spooling. MUST accept the request in any   indicates state, MUST NOT
transition the Printer to any network protocol other "printer-state", and MUST add the
'hold-new-jobs' value to the Printer's "printer-state-reasons" attribute
(whether the value was present or direct
      connect, including IPP
                                               Output Device
                                             +---------------+
                                             |  ###########  |
 O   +--------+                              |  # (Leaf)  #  |
/|\  | client |------------IPP-----------------># Printer #  |
/ \  +--------+                              |  # Object  #  |
                                             |  ###########  |
                                             +---------------+

                   Figure 1 - Embedded not).

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

                          ###########          Output Device
 O   +--------+           # (Leaf)  #        +---------------+
/|\  | (see [ipp-mod] Sections 1 and 8.5).

The Hold-New-Jobs Request and Hold-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 6).

3.3.2 Release-Held-New-Jobs operation

This OPTIONAL operation allows a client |---IPP----># to undo the effect of a previous
Hold-New-Jobs operation.  In particular, the Printer #---any->|               |
/ \  +--------+           # object  #        |               |
                          ###########        +---------------+

                    Figure 2 - Hosted releases all of the
jobs that it had held as a consequence of a Hold-New-Jobs operations,
i.e., while the 'hold-new-jobs' value was present in the Printer's
"printer-state-reasons" attribute.  In addition, the Printer object

                                             +---------------+
                                             |               |
                                          +->| Output Device |
                          ########### any/   |               |
 O   +--------+           # (Leaf)  #   /    +---------------+
/|\  | client |---IPP----># MUST accept
this request in any state, MUST NOT transition the Printer #--*
/ \  +--------+           # Object  #   \    +---------------+
                          ########### any\   |               |
                                          +->| Output Device |
                                             |               |
                                             +---------------+

                    Figure 3 - Output Device fan out

                      Expires:  January 6, 2001
                          ###########           ###########
 O   +--------+           # Non-Leaf#           # subord. #
/|\  | client |---IPP----># Printer #---IPP----># to any other
"printer-state", and MUST remove the 'hold-new-jobs' value from its
"printer-state-reasons" attribute (whether the value was present or not)
so that the Printer #
/ \  +--------+           # object  #           # object  #
                          ###########           ########### no longer holds newly created jobs.

Access Rights: The Subordinate Printer can authenticated user (see [ipp-mod] section 8.3)
performing this operation must be a Non-Leaf Printer as in Figure 4 to
Figure 6, an operator or can be a Leaf administrator of the
Printer as in Figure object (see [ipp-mod] Sections 1 to Figure 3.

                     Figure 4 - Chained IPP Printer

                +------IPP--------------------->###########
               /                           +---># subord. #
              /                           /     # and 8.5).

The Release-Held-New-Jobs Request and Release-Held-New-Jobs Response
have the same attribute groups and attributes as the Pause-Printer
operation (see [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the
new "printer-message-from-operator" operation attribute (see section 6).

3.4 Deactivate and Activate Printer #
             /            ###########   any     # object  #
 O   +--------+           # Non-Leaf#   /       ###########
/|\  | client |---IPP----># Operations

This section defines the OPTIONAL Deactivate-Printer and Activate-
Printer #--*
/ \  +--------+           # object  #   \
             \            ###########   any     ###########
              \                           \     # subord. #
               \                           +---># operations that stop and start the IPP Printer #
                +------IPP---------------------># object  #
                                                ###########

The Subordinate Printer can from
accepting all requests except queries and performing work.  If either of
these operations are supported, both MUST be a Non-Leaf Printer as in Figure 4 to
Figure 6, or can be a Leaf Printer as in Figure 1 to Figure 3.

                     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 as in Figure 4, Figure
5, or Figure 6, or can be a Leaf Printer as in Figure 1, Figure 2, or
Figure 3.

                     Figure 6 - IPP Printer fan in supported.

                     Expires:  January 6,  February 15, 2001

4.7 Forwarding requests

This section describes

These operations allow the forwarding of Job and Printer requests operator to
Subordinate Printer objects.

4.7.1 Forwarding requests that affect Printer objects

In Printer fan-out, Printer fan-in, and Chained Printers, the Non-Leaf
IPP Printer object MUST NOT forward put the operations that affect Printer
objects to its Subordinate Printer objects.  If into a client wants dormant
read-only condition and to
explicitly target take it out of such a Subordinate Printer, the client MUST specify the URI condition.  These
operations are a combination of the Subordinate Printer.   The client can determine Deactivate and Pause operations,
plus preventing the URI acceptance of any
Subordinate Printers by querying the Printer's "subordinate-printers-
supported (1setOf uri) attribute (see section 6.1).

Table 2 lists the operations that affect Printer objects other requests, except queries.

The Deactivate and the
forwarding behavior that a Non-Leaf Activate Printer MUST exhibit to its
immediate Subordinate Printers. Operations that MUST NOT affect the
submission of jobs have a
different forwarding rule (see section 0 and Table 3):

      Table 2 - Forwarding operations that affect Printer objects

Printer Operation     Non-Leaf Printer action
Printer Operations:
  Enable-Printer     MUST NOT forward using other job submission protocols to any of its Subordinate
                      Printers
  Disable-Printer    MUST NOT forward the
associated Output Device; the Deactivate and Activate Device Operations
(see [ipp-device-ops]) are intended to any of its Subordinate
                      Printers
  Hold-New-Jobs      MUST NOT forward stop the associated Output
Device(s) from performing work and accepting operations, except query
operations.

3.4.1 Deactivate-Printer operation

This OPTIONAL operation allows a client to any of its Subordinate
                      Printers
  Release-Held-New-  MUST NOT forward stop the Printer object from
starting to any of its Subordinate
  Jobs               Printers
  Deactivate-Printer MUST NOT forward send IPP jobs to any of its Output Devices or Subordinate
Printers
  Activate-Printer   MUST NOT forward to any (Pause-Printer-After-Current-Job) and stop the Printer object
from accepting any, but query requests.  The Printer performs a Disable-
Printer and a Pause-Printer-After-Current-Job operation immediately,
including use of its Subordinate
                      Printers
  Restart-Printer    MUST NOT forward to any all of its Subordinate
                      Printers
  Shutdown-Printer the "printer-state-reasons" if these two
operations cannot be completed immediately.  In addition, the Printer
MUST NOT forward to any of its Subordinate
                      Printers
  Startup-Printer immediately reject all requests, except Activate-Printer, queries
(Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs, etc.), Send-
Document, and Send-URI (so that partial job submission can be completed
- see section 3.1.1) and return the 'server-error-service-unavailable'
status code.

The IPP Printer MUST NOT forward to accept the request in any of its Subordinate
                      Printers
IPP/1.1 state.  Immediately, the
Printer       See [ipp-mod]
Operations:
  Get-Printer- MUST NOT forward to any of set the 'deactivated' value in 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 Operations that only affect Printer objects "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
0), a Non-Leaf Printer object MUST forward operations that directly
affect jobs to the appropriate Job object(s) in one 8.3)
performing this operation must be an operator or more of its
immediate Subordinate Printer objects.  Forwarding is REQUIRED since the
purpose administrator of such a Job operation is to affect the indicated job which
itself may
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Deactivate-Printer Request and Deactivate-Printer Response have been forwarded.  Such forwarding MAY be immediate or
queued, depending on 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 implementation.  For example, new "printer-
message-from-operator" operation attribute (see section 6).

3.4.2 Activate-Printer operation

This OPTIONAL operation allows a Non-Leaf client to undo the effects of the
Deactivate-Printer, i.e., allow the Printer object MAY queue/spool jobs, feeding a job at a time to its Subordinate Printer(s), or MAY forward start sending IPP
jobs immediately to one any of its Output Devices or Subordinate Printers.  In either case, Printers (Pause-
Printer-After-Current-Job) and start the Non-Leaf Printer object
is forwarding Job Creation operations to one of its Subordinate
Printers.  Only the time of forwarding of from accepting
any requests.  The Printer performs an Enable-Printer and a Resume-
Printer operation immediately.  In addition, the Job Creation operations
depends on whether Printer MUST
immediately start accepting all requests.

                     Expires:  February 15, 2001

The IPP Printer MUST accept the policy is to queue/spool jobs request in any state.  Immediately, the Non-Leaf
Printer or MUST immediately remove the Subordinate Printer.

When a Non-Leaf Printer object creates a Job object in 'deactivated' value from its Subordinate
Printer, whether that Non-Leaf Printer object keeps a fully formed Job
object
"printer-state-reasons" attribute (whether present or just keeps a mapping from not).

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator of the "job-ids" that it assigned to
those assigned by its Subordinate
Printer object is IMPLEMENTATION-
DEPENDENT.  In either case, the Non-Leaf Printer MUST be able to accept (see [ipp-mod] Sections 1 and carry out future Job operations that specify 8.5).

The Activate-Printer Request and Activate-Printer Response have the "job-id" that same
attribute groups and attributes as the
Non-Leaf Printer assigned Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and returned to 3.2.7.2), including the job submitting client.

Table 3 lists new "printer-
message-from-operator" operation attribute (see section 6).

3.5 Restart-Printer, Shutdown-Printer, and Startup-Printer operations

This section defines the OPTIONAL Restart-Printer, Shutdown-Printer, and
Startup-Printer operations that directly affect jobs initialize, shutdown, and startup the
forwarding behavior that a Non-Leaf
Printer MUST exhibit to its
Subordinate Printers:

        Table 3 - Forwarding operations that affect Jobs objects

  Job operation
                      Non-Leaf Printer action

  Job operations:
        Reprocess-Job MUST forward to the appropriate Job in one object, respectively.  Each of
                      its Subordinate Printers
        Cancel- these operations is OPTIONAL and
any combination MAY be supported.

The Restart-Printer, Shutdown-Printer, and Startup-Printer operations
MUST NOT forward
  Current-Job
        Resume-Job    MUST forward to affect the appropriate Job in one submission of
                      its Subordinate Printers
        Promote-Job   MUST forward jobs using other job submission
protocols to the appropriate Job in one of
                      its Subordinate Printers
  IPP/1.1 Printer
  Operations:
        Print-Job     MUST forward immediately or queue associated Output Device; the Reset-Device and Power-
Off-Device Operations (see [ipp-device-ops]) are intended to initialize
or power off the
                      appropriate Subordinate associated Output Device(s).

3.5.1 Restart-Printer operation

This OPTIONAL operation allows a client to restart a Printer
        Print-URI     MUST forward immediately object
whose operation is in need of initialization because of incorrect or queue to
erratic behavior, i.e., perform the
                      appropriate Subordinate Printer
        Validate-Job effect of a software re-boot.  The
implementation MUST forward attempt to save any information about Jobs and the appropriate Subordinate
Printer
        Create-Job    MUST forward immediately or queue to object before re-initializing.  However, this operation MAY have
drastic consequences on the
                      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 queue to running system, so the
                      appropriate Job in one of its Subordinate
                      Printers
        Send-URI      MUST forward immediately or queue operator should first
try the Deactivate-Printer to minimize the
                      appropriate Job in one effect on the current state
of its Subordinate
                      Printers
        Cancel-Job    MUST forward to the appropriate Job in one system.  The effects of
                      its Subordinate Printers
        Get-Job- previous Disable-Printer, Pause Printer,
and Deactivate-Printer operations are lost.

The IPP Printer MUST forward to accept the appropriate Job request in one of
  Attributes          its Subordinate Printers, if the Non-Leaf any state.  The Printer doesn't know the complete status of the
                      Job
object
        Hold-Job MUST forward initialize its Printer's "printer-state" to 'idle', remove
the appropriate Job in one of state reasons from its Subordinate Printers
        Release-Job   MUST forward to the appropriate Job in one of "printer-state-reasons" attribute, and its Subordinate Printers
        Restart-Job   MUST forward
"printer-is-accepting-jobs" attribute to the appropriate Job in one 'true'.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator of
                      its Subordinate Printers
  IPP Set operations: See [ipp-set-ops]
        Set-Job-      MUST forward to the appropriate Job in one of
  Attributes          its Subordinate Printers

When a
Printer receives a request that REQUIRES forwarding, it does so
on a "best efforts basis", object (see [ipp-mod] Sections 1 and returns a response to its client without
waiting for responses from any of its Subordinate Printers.  Such
forwarded requests could fail.  In order for 8.5).

The Restart-Printer Request and Restart-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 6).

                     Expires:  February 15, 2001

3.5.2 Shutdown-Printer Operation

This OPTIONAL operation allows a client to become aware of
such a condition, shutdown a new 'forwarded-operation-failed' event Printer, i.e.,
stop processing jobs and make the Printer object no longer available for
any operations using the IPP protocol without losing any jobs.  There is defined,
which a client can subscribe to (see section  [ipp-ntfy]).

The following Job Description attributes are defined
no way to help represent
Job relationships for fan-out and forwarding bring the instance of jobs:

1."output-device-assigned" (name(127)) - from [ipp-mod]: This attribute
  identifies the Output Device Printer object back to being used,
except for the Startup-Printer (see section 3.5.3) which starts up a new
instance of the Printer object has assigned
  this job.  If an Output Device implements an embedded Printer object,
  the Printer object NEED NOT set this attribute.  If a print server
  implements a Printer object, the value MAY be empty (zero-length
  string) or not returned until for hosted implementations.  The purpose
of Shutdown-Printer is to shutdown the Printer object assigns for an Output
  Device extended period,
not to reset the job.  This attribute is particularly useful when device(s) or modify a
  single Printer object supports multiple devices (so called "fan-
  out").

2."original-requesting-user-name" (name(MAX)) - operation attribute
  containing the user name of attribute.  See Restart-
Printer (section 3.5.1), Startup-Printer (section ), and Reset-Device
[ipp-device-ops] for the original user, i.e., corresponds way to initialize the "requesting-user-name" software or reset the
Output Device(s).  See the Disable-Printer operation attribute that (section 3.1) for a
way for the original client supplied to stop the first Printer object. from accepting Job Creation
requests without stopping processing or shutting down.

The IPP/1.1
  "requesting-user-name" operation attribute Printer MUST add the 'shutdown' value (see [ipp-mod]) is updated
  by each client [ipp-mod] section 4.4.11)
immediately to be itself on each hop, i.e., the "requesting-user-
  name" is the client forwarding the request, not the original client.
  The "job-originating-user-name" Job its "printer-state-reasons" Printer Description attribute remains as

                      Expires:  January 6, 2001
and performs a Deactivate-Printer operation (see section 3.4.1) which
performs a Disable-Printer and Pause-Printer-After-Current-Job
operation).

Note:  In order to shutdown the authenticated original user, not Printer after all the parent Printer's
  authenticated host, and is forwarded by each client without changing currently
submitted jobs have completed, the value.

5  New Operation attributes

This operator issues a Disable-Printer
operation (see section summarizes the usage of 3.1.1) and then waits until all the new "printer-message-from-
operation" jobs have
completed and "job-message-from-operator" operation attributes that set the corresponding Printer and Job Description attributes.  These goes into the 'idle' state before issuing the
Shutdown-Printer operation.

The Printer object MUST accept this operation attributes are in any state and
transition the Printer object through the "printer-states" and "printer-
state-reasons" defined for most the Pause-Printer-After-Current-Job operation
until the activity is completed and the Printer object disappears.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator of the Device
Printer object (see [ipp-mod] Sections 1 and Job
operations that operators are likely to perform, respectively, so that
operators can indicate 8.5).

The Shutdown-Printer Request and Shutdown-Printer Response have the reasons for their actions.  See [ipp-set-ops]
for same
attribute groups and attributes as the definition of these Pause-Printer operation attributes.
Table 4 shows (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
message-from-operator" operation attributes that are defined for use with the
Printer Operations.
Legend:
     R - REQUIRED for attribute (see section 6).

3.5.3 Startup-Printer operation

This OPTIONAL operation allows a Printer client to support
     O - OPTIONAL for startup an instance of a
Printer object, provided that there isn't one already instantiated.  The
purpose of Startup-Printer is to support; allow a hosted implementation of the
IPP Printer ignores object (i.e., a Server that implements an IPP Printer on
behalf of a networked or local Output Device) to be started after the
attribute if not supported
     <blank> - not defined
host is available (by means outside this document).  See Restart-Printer
(section 3.5.1) and Reset-Device [ipp-device-ops] for use with the operation; way to
initialize the Printer
ignores software or reset the attribute

      Table 4 - Operation attribute support for Output Device(s) when the IPP
Printer 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 object has already been instantiated.

                     Expires:  February 15, 2001

The host MUST accept this operation only when the 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 object has not
been instantiated.  If the Printer object already exists, the host must
return the 'client-error-not-possible' status code.

The result of this operation attributes that are defined for use MUST be with the
Job operations.
Legend:
     R - REQUIRED for a Printer object's "printer-
state" set to support

                      Expires:  January 6, 2001
     O - OPTIONAL for a Printer 'idle', the state reasons removed from its "printer-state-
reasons" attribute, and its "printer-is-accepting-jobs" attribute set to support;
'false'.  Then the Printer ignores operator can reconfigure the Printer before
performing an Enable-Printer operation.  However, when a Printer is
first powered up, it is RECOMMENDED that its "printer-is-accepting-jobs"
attribute if supplied, but not supported
     <blank> - not defined for use with be set to 'true' in order to achieve easy "out of the operation; box"
operation.

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

The Shutdown-Printer Request and Shutdown-Printer Response have the same
attribute

        Table 5 - Operation 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 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 (see section 6).

4  Definition of the Job Operations

All Job operations are directed at Job objects.  A client MUST always
supply some means of identifying the Job  Rel  ren  Jo Set-                         -
                       eas  t-   b  Job-                         Aft
                       e- object in order to identify the
correct target of the operation.  That job identification MAY either be
a single Job     Attrib                       er URI or a combination of a Printer URI with a 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

* ID.  The Printer
IPP object implementation MUST support the "job-hold-until" both forms of identification for
every job.

The Job Operations defined in this document are summarized in Table 3:

            Table 3 - Job operation attribute
if Operation-Id assignments

  Operation Name  Operati Brief description
                  on-Id
  Reprocess-Job   0x2C    Creates a copy of a completed target
                           job with a new Job ID and processes it supports
  Cancel-Current- 0x2D    Cancels the "job-hold-until" current job on the target
  Job Template attribute.
**  The                      Printer MUST support or the "job-hold-until" operation attribute specified job if it supports the Set-Job-Attributes operation, so that the client can
hold is
                           the current job with
  Suspend-        0x2E    Suspends the Reprocess-Job operation and current processing job on
  Current-Job              the modify target Printer or the specified job
before releasing
                           if it is the current job, allowing
                           other jobs to be processed.

6  New Printer Description Attributes

The following new Printer Description attributes are needed processed instead
  Resume-Job      0x2F    Resume the suspended target job
  Promote-Job     0x30    Promote the pending target job to support be
                           next after the new operations defined in this document. current job(s) complete
  Schedule-Job-   0x31    Schedule the target job immediately
  After                    after the specified job, all other
                           scheduling factors being equal.

                     Expires:  January 6,  February 15, 2001

6.1 subordinate-printers-supported (1setOf uri)

4.1 Reprocess-Job Operation

This Printer attribute OPTIONAL operation is REQUIRED if an implementation supports
Subordinate Printers (see section 4) and contains the URIs a create job operation that allows a client
to re-process a copy of a job that had been retained in the
immediate Subordinate Printer object(s) associated with this Printer
object.  Each Non-Leaf Printer object MUST support this Printer
Description attribute.  A Leaf Printer object either does not support
the "subordinate-printers-supported" attribute queue after
processing completed, was canceled, or does so with the 'no-
value' out-of-band value was aborted (see [ipp-mod]
section 4.1), depending on
implementation.

The precise format of the Subordinate Printer URIs 4.3.7.2).  This operation is implementation
dependent (see section 4.4).

If the Printer 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 to populate same as the Job object's
"output-device-assigned" attribute Restart-Job
operation (see [ipp-mod] section 4.3.13).  The
"output-device-assigned" Job attribute identifies the Output Device to
which 3.3.7), except that the Printer object has assigned creates
a job, for example, when new job that is a single
Printer object copy of the target job and the target job is supporting Device fan-out or Printer fan-out.

6.2 parent-printers-supported (1setOf uri)

This Printer attribute
unchanged.  The new job is REQUIRED if an implementation supports
Subordinate Printers (see section 4) and contains the URI of assigned new values to the Non-
Leaf printer object(s) for which this Printer object is "job-uri" and
"job-id" attributes and the immediate
Subordinate, i.e., this Printer's immediate "parent" or "parents".  Each
Subordinate Printer object MUST support this Printer new job's Job Description
attribute.  A Printer attributes that has no parents, either does not support the
"parent-printers-supported" attribute or does so
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 'no-value'
out-of-band value (see [ipp-mod] section 4.1), depending Job
History after a suitable period, independent of whether one or more
Reprocess-Job operations have been performed on
implementation.

6.3 redirection-printers-supported (1setOf uri)

This Printer attribute it.

If the Set-Job-Attributes operation is REQUIRED if an implementation supports supported, then the
Redirect-Job "job-hold-
until" operation (see section 12.5).  It specifies attribute MUST be supported with at least the URIs
'indefinite' value, so that a client can modify the Printer supports new job before it is
scheduled for redirection jobs to other Printers (on processing using the same
server).

7  Additional Values for "printer-state-reasons"

This section defines additional values for Set-Job-Attributes operation.  After
modifying the "printer-state-reasons"
Printer Description attribute.

                      Expires:  January 6, 2001

7.1 'hold-new-jobs'

  'hold-new-jobs': The operator has issued job, the Hold-New-Jobs client can release the job for processing, by
using the Release-Job operation
     (see section 0) specifying the newly assigned "job-uri"
or other means, but "job-id" for the output-device(s) are taking
     an appreciable time new job.

4.2 Cancel-Current-Job Operation

This OPTIONAL operation allows a client to stop.  Later, when all output has stopped,
     the "printer-state" becomes 'stopped', and cancel the 'paused' value
     replaces current job on the 'moving-to-paused' value in
target Printer or the "printer-state-
     reasons" attribute.  This value MUST be supported, specified job if the Hold-New-
     Jobs operation it is supported and the implementation takes
     significant 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 to pause a device in certain circumstances.

7.2 'deactivated'

  'deactivated':  A Cancel-Current-
Job is received, some media sheet pages might be printed before the job
is actually terminated.

If the client has issued does not supply a Deactivate-Printer "job-id" operation
     for attribute, the
Printer object (see section 0) MUST accept the request and cancel the Printer current job if there is a
current job in the
     process of becoming deactivated 'processing' or has become deactivated. The
     Printer 'processing-stopped' state;
otherwise, it 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) the request and return the 'server-error-service-
     unavailable' 'client-error-not-
possible' status code.

8  Additional Values for "job-state-reasons"

This section defines additional values for the "job-state-reasons" Job
Description attribute.

8.1 'job-suspended'

  'job-suspended':  The  If more than one job has been suspended while processing using is in the Suspend-Current-Job operation and other jobs can be processed
     on 'processing' or
'processing-stopped' states, the Printer.  The Job can be resumed using one that is marking is canceled and the Resume-Job
     operation which removes this value.

9  Additional events

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

  'forwarded-operation-failed' - an operation that unaffected.

Warning:  On a Printer forwarded
     to shared printer, there is a Subordinate Printer (see section 4.7) failed.

10 Additional status codes

This section defines new status codes used by race condition.  Between the operations defined in
time that a user issues this document.

                      Expires:  January 6, 2001

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

The Printer has been deactivated using the Deactivate-Printer operation and is only accepting the Activate-Printer (see section 0), Get-Job-
Attributes, Get-Jobs, Get-Printer-Attributes, and any other Get-Xxxx
operations.  An operator can perform its acceptance, the Activate-Printer operation current
job might change to
allow a different job.  If the Printer user or operator is
authenticated to accept other operations.

11 Definition of cancel the new job, the wrong job is canceled.  To
prevent this race from canceling the wrong job, the Printer Operations

All Printer Operations are directed at Printer objects.  A client MUST
always MAY supply
the "printer-uri" "job-id" 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.

The Set 2 Printer Operations are summarized in Table 6:

          Table 6 - Printer Operation Operation-Id assignments

  Operation Name  Operati Brief description
                  on-Id
  Enable-Printer  0x??    Allows which is checked against the target Printer to accept Job
                           Creation operations
  Disable-Printer 0x??    Prevents current
job's job-id.  If the target Printer from
                           accepting Job Creation operations
  Pause-Printer-  0x??    Pause job identified by the Printer after "job-id" attribute is not
the current job
  After-Current-           has been sent to on the Output Device.
  Job
  Hold-New-Jobs   0x??    Finishes processing all currently
                           pending jobs.  Any new jobs are placed Printer, i.e., is not in the 'pending-held' state.
  Release-Held-   0x??    Release all jobs to the 'pending' state
  New-Jobs                 that had been held by 'processing' or
'processing-stopped' states, the effect of a
                           previous Hold-New-Jobs Printer MUST reject this operation and
                           condition

                     Expires:  February 15, 2001

return the Printer to no longer hold
                           new jobs.
  Deactivate-     0x??    Puts the Printer into a read-only
  Printer                  deactivated state.
  Activate-       0x??    Restores 'client-error-not-possible' status code.  Otherwise, the
Printer to normal activity
  Printer
  Restart-Printer 0x??    Restarts cancels the target Printer and re-
                           initializes specified job.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must either be the software
  Shutdown-       0x??    Shuts down job owner (as determined in
the target Printer so that
  Printer                  it cannot be restarted Job Creation operation) or queried
  Startup-Printer 0x??    Starts up the instance an operator or administrator of the
Printer object

All of (see [ipp-mod] Sections 1 and 8.5).

The Cancel-Current-Job Request and Cancel-Current-Job Response have the operations in this document are OPTIONAL for an IPP object to
support.  Unless
same attribute groups and attributes as the specification of an OPTIONAL Resume-Printer operation requires
support of another OPTIONAL operation, conforming implementations may

                      Expires:  January 6, 2001

support any combination of these operations.  Many
(see [ipp-mod] section 3.2.8), including the new "job-message-from-
operator" operation attribute (see section 6), with the addition of the operations
come
following Group 1 Operation attributes in pairs and so both are REQUIRED if either one the request:

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

     The client OPTIONALLY supplies this Operation attribute in order to
     verify that the identified job is implemented.

                      Expires:  January 6, 2001

11.1 still the current job on the
     target Printer object.  The Disable IPP object MUST supports this operation
     attribute, if it supports this operation.

4.3 Suspend and Enable Printer Operations Resume Job operations

This section defines the OPTIONAL Disable-Printer and Enable-Printer
operations that stop Suspend-Current-Job and start the IPP Printer object from accepting new
IPP jobs.  If either of these operations are supported, both MUST be
supported. Resume-Job operations.
These operations allow the an operator to control whether or not the
Printer will accept new Job Creation (Print-Job, Print-URI, user to suspend a job while it is
processing and Create-
Job) operations.  These operations have no allow other effect on jobs to be processed and the Printer,
so that resume the Printer continues to accept all other
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
continues to schedule Release-Job operations ([ipp-mod] section 3.3.5) are
for holding and process jobs normally.  In other words, these releasing held jobs, not suspending and resuming
suspended jobs.

4.3.1 Suspend-Current-Job operation control the "input of new jobs"

This OPTIONAL operation allows a client to stop the IPP current job on the
target Printer while or the
Pause and Resume operations (see section 11.2) independently control specified job if it is the
"output of new jobs" from current job on the IPP Printer
Printer, and allow other jobs to the Output Device. be processed instead.  The Disable-Printer and Enable-Printer operations MUST NOT affect Printer
moves the
submission of jobs using other current job submission protocols to or the
associated Output Device; target job to the Disable 'processing-stopped'
state and Enable Device Operations sets the 'job-suspended' value (see
[ipp-device-ops]) are intended to stop section 9.1) in the acceptance of all jobs by job's
"job-state-reasons" attribute and processes other jobs.

If the
associated Output Device(s).

Disable-Printer Operation

This OPTIONAL operation allows a client to stop does not supply a "job-id" operation attribute, the
Printer object from
accepting new jobs, i.e., cause MUST accept the Printer to reject subsequent Job
Creation operations request and return suspend 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 current job if there is
a current job in the Create-Job operation had
already been accepted.  All previously created 'processing' or submitted Jobs and
currently processing Jobs continue unaffected.

The IPP Printer 'processing-stopped' state;
otherwise, it MUST accept reject the request in any state.  The Printer sets and return 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 'client-error-not-
possible' status code.  If more than one job is in the previous value was.  This operation has no immediate 'processing' or
direct effect on
'processing-stopped' states, all of them are suspended.

Warning:  On a shared printer, there is a race condition.  Between the Printer's "printer-state" and "printer-state-
reasons" attributes.

Access Rights: The authenticated
time that a user (see [ipp-mod] section 8.3)
performing issues this 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 its acceptance, the same
attribute groups and attributes as current
job might change to a different job.  If the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including user or operator is

                     Expires:  February 15, 2001

authenticated to suspend the new "printer-
message-from-operator" job, the wrong job is suspended.  To
prevent this race from pausing the wrong job, the client MAY supply the
"job-id" operation attribute (see section 5).

                      Expires:  January 6, 2001

Enable-Printer Operation

This OPTIONAL operation allows a client to start which is checked against the Printer object
accepting jobs, i.e., cause 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 to accept subsequent Job
Creation operations.  The MUST reject this operation and
return the 'client-error-not-possible' status code.  Otherwise, the
Printer still accepts all other operations.
All previously submitted Jobs suspends the specified job and currently processing Jobs continue
unaffected. processed other jobs.

The IPP Printer MUST accept the reject a Resume-Job request (and return the 'client-
error-not-possible') for a job that has been suspended , i.e., for a job
in any state.  The Printer sets the value of its "printer-is-accepting-jobs" READ-ONLY Printer
Description attribute to 'true' (see [ipp-mod] section 4.4.20), no
matter what 'processing-stopped' state, with the previous 'job-suspended' value was.  This operation has no immediate or
direction effect on the Printer's "printer-state" and "printer-state-
reasons" attributes. in its
"job-state-reasons" attribute.

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

The Enable-Printer Suspend-Current-Job Request and Enable-Printer Suspend-Current-Job 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), section 3.2.8 ), including the new "printer-
message-from-operator" "job-message-from-
operator" operation attribute (see section 5).

11.2 The Pause and Resume Printer Operations

This section leaves 6), with the OPTIONAL IPP/1.1 Pause-Printer (see [ipp-mod]
sections 3.2.7) to be ambiguous as 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 whether or not it stops
     verify that the
Printer immediately or after identified job is still the current job and defines on the
     target Printer object.  The IPP object MUST supports this operation
     attribute, if it supports this operation.

4.3.2 Resume-Job operation

This OPTIONAL
Pause-Printer-After-All-Current-Jobs operation allows a client to be after the current
job.  These operations affect resume the scheduling of IPP jobs.  If either of
these Pause Printer operations are supported, then target job at the Resume-Printer
operation MUST be supported.

These operations allow
point where it was suspended.  The Printer moves the operator target job to control whether or not the
Printer will send new IPP jobs to
'pending' state and removes the associated Output Device(s) that 'job-suspended' value from the IPP Printer object represents.  These operations have no other
effect on job's
"job-state-reasons" attribute.

If the Printer, so that target job is not in the Printer continues to accept all
operations.  In other words, these operation control 'processing-stopped' state with the "output of new
jobs" to
'job-suspended' value in the Output Device(s) while job's "job-state-reasons" attribute, the Disable and Enable
Printer
Operations MUST reject the request and return the 'client-error-not-
possible' status code, since the job was not suspended.

Access Rights: The authenticated user (see [ipp-mod] section 11.1) independently control 8.3)
performing this operation must either be the "input job owner (as determined in
the Job Creation operation) or an operator or administrator of new
jobs" to the IPP Printer.
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Pause Resume-Job Request and Resume Printer Operations MUST NOT affect jobs that were
submitted using other job submission protocols to the associated Output
Device; Resume-Job Response have the Pause same attribute
groups and Resume Device Operations (see [ipp-device-ops])
are intended to stop attributes as the acceptance of all jobs by Release-Job operation (see [ipp-mod]
section 3.3.6), including the associated Output
Device(s). new "job-message-from-operator" operation
attribute (see section 6).

                     Expires:  January 6,  February 15, 2001

4.4 Job Scheduling Operations

This document and [ipp-device-ops] define distinct operations in order section defines jobs that allow an operator to disambiguate control the Pause-Printer
scheduling of jobs.

4.4.1 Promote-Job operation as shown

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 Table 7.  The
Printer Operations affect only Jobs submitted using IPP, while a production printing environment where the
Device Operations affect all jobs no matter what operator
is involved in job submission protocol
was used to submit them to scheduling.

If the Output Device.

        Table 7 - Pause and Resume Printer and Device Operations

     Pause and Resume Printer   Description
     and Device Operations

     IPP/1.1 Pause Printer      Stops target job is in the IPP Printer from sending
                                new IPP Jobs to 'pending' state, this operation does not
change the Output Device(s)
                                either immediately or job's state, but causes the job to be processed after the
current job(s) complete.  If the target job completes, depending on
                                implementation, as defined is not in [ipp-
                                mod].
     Pause-Printer-After-       Stops the IPP 'pending'
state, the Printer from sending
     Current-Job                new IPP Jobs to MUST reject the Output Device(s)
                                after request and return the current jobs finish
     Resume-Printer             Starts 'client-error-
not-possible' status code.

If the IPP Printer sending IPP
                                Jobs to the Output Device again.
     Pause-Device-Now           Stops implements the Output Device immediately
                                from producing marked media (current
                                page, sheet, depending on
                                implementation) for any job. Like "job-priority" Job Template attribute (see
[ipp-mod] section 4.2.1), the
                                Pause button on Printer sets the Output Device.
     Pause-Device-After-        Stops job's "job-priority" to
the Output Device from
     Current-Copy               producing marked media after highest value supported (so that the
                                current copy job will print before any of
the current job.
     Pause-Device-After-        Stops other pending jobs).  The Printer returns the Output Device from
     Current-Job                producing marked media target job immediately
after the current job.
     Resume-Device              Starts job(s) in a Get-Jobs response (see [ipp-mod] section
3.2.6) for the Output Device processing
                                any jobs again.

Pause-Printer-After-Current-Job operation

This OPTIONAL 'not-completed' jobs.

When the current job completes, is canceled, suspended (see section
4.3.1), or aborted, the target of this operation allows is processed next.

If a client to stop issues this request (again) before the Printer object from
starting to send IPP jobs to any target of its Output Devices or Subordinate
Printers.  If the IPP Printer is in the middle
operation of sending an IPP job to
an Output Device or Subordinate Printer, the IPP Printer MUST complete
sending that Job.  However, after receiving original request started processing, the target of this operation,
new request is processed before the IPP
Printer MUST NOT start previous job that was to send any additional be
processed next.

IPP jobs is specified not to any require queues for job scheduling, since there
are other implementation techniques for scheduling multiple jobs, such
as re-evaluating a criteria function for each job on a scheduling cycle.
However, if an implementation does implement queues for jobs, then the
Promote-Job puts the specified job at the front of its
Output Devices or Subordinate Printers.  In addition, after having
received this operation, the IPP Printer MUST NOT start queue.  A
subsequent Promote-Job before the first job starts processing any
more jobs, so additional jobs MUST NOT enter puts that
specified job at the 'processing' state.

If front of the IPP Printer queue, so that it is not sending an IPP Job to "in front" of the Output Device or
Subordinate Printer (whether
previously promoted job.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or not administrator of the Output Device or Subordinate
Printer is busy processing any jobs), the IPP
Printer object transitions
immediately to (see [ipp-mod] Sections 1 and 8.5).

The Promote-Job Request and Promote-Job Response have the 'stopped' state by setting its "printer-state" same attribute to 'stopped', removing
groups and attributes as the 'moving-to-paused' value, if Cancel-Job operation (see [ipp-mod] section
3.3.3), including the new "job-message-from-operator" operation
attribute (see section 6).

                     Expires:  January 6,  February 15, 2001

present, from its "printer-state-reasons" attribute, and adding the
'paused' value

4.4.2 Schedule-Job-After operation

This OPTIONAL operation allows a client to its "printer-state-reasons" attribute.

If request the implementation will take appreciable time Printer to complete sending an
IPP
schedule the target job so that it has started sending will be processed immediately after
the specified predecessor job, all other scheduling factors being equal.
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 an Output Device be processed after the
predecessor job completes.  The predecessor job can be in the 'pending',
'processing', or Subordinate
Printer, 'processing-stopped' states.  If the target job is not
in the 'pending' state or the predecessor job is not in the 'pending',
'processing', or 'processing-stopped' states, the IPP Printer adds MUST reject
the 'moving-to-paused' value to request and returns the 'client-error-not-possible' status code,
since the job cannot have its position changed.

If the Printer object's "printer-state-reasons" implements the "job-priority" Job Template attribute (see
[ipp-mod] section [ipp-
mod] 4.4.12).  When 4.2.1), the IPP Printer has completed sending IPP jobs that
it was in sets the process job's "job-priority" to
that of sending, the Printer object transitions to predecessor job (so that the
'stopped' state by setting its "printer-state" attribute to 'stopped',
removing job will print after the 'moving-to-paused' value, if present, from its "printer-
state-reasons" attribute, and adding
predecessor job).  The Printer returns the 'paused' value to its "printer-
state-reasons" attribute.

This operation MUST NOT affect target job immediately after
the acceptance of Job Creation requests predecessor in a Get-Jobs response (see Disable-Printer [ipp-mod] section 0).

For any jobs that are 'pending' 3.2.6) for
the 'not-completed' jobs.

When the predecessor job completes processing or 'pending-held', is canceled or aborted
while processing, the 'printer-stopped'
value target of this operation is processed next.

If the jobs' "job-state-reasons" attribute also applies.  However, client does not supply a predecessor job, this operation has the
same semantics as Promote-Job (see section 4.4).

IPP Printer NEED NOT update those jobs' "job-state-reasons"
attributes and only need return the 'printer-stopped' value when those
jobs is specified not to require queues for job scheduling, since there
are queried using other implementation techniques for scheduling multiple jobs, such
as re-evaluating a criteria function for each job on a scheduling cycle.
However, if an implementation does implement queues for jobs, then the Get-Job-Attributes or Get-Jobs operations
(so-called "lazy evaluation").

The IPP Printer MUST accept
Schedule-Job-After operation puts the request specified job immediately after
the specified job in any state and transition the
Printer queue.  A subsequent Schedule-Job-After
operation specifying the same job will cause its target job to be placed
after that job, even though it is between the indicated new "printer-state" first target job 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'       '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,
specified job.  For example, suppose the "printer-
                                        state" becomes 'stopped', job queue consisted of jobs: A,
B, C, D, and E, in that order.  A Schedule-Job-After with job E as the 'paused' value replaces
target and B as the
                                        'moving-to-paused' value specified job would result in the
                                        "printer-state-reasons"
                                        attribute

  'processing' 'stopped'    'paused'  REQUIRED:  'successful-ok'; following queue:
A, B, E, C, D.  A subsequent Schedule-Job-After with Job D as the
                                        IPP Printer wasn't target
and B as the specified job would result in the middle
                                        of sending an IPP following queue:  A, B,
D, E, C.  In other words, the link between the two jobs in a Schedule-
Job-After operation is not retained, i.e., there is no attribute on
either job that points to an
                                        Output Device

  'stopped'    'stopped'    'paused'  REQUIRED:  'successful-ok' the other job as a result of this operation.

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

                      Expires:  January 6, 2001

The Pause-Printer-After-Current-Job Schedule-Job-After Request and Pause-Printer-After-
Current-Job Response have the same attribute groups and
attributes as the Pause-Printer Cancel-Job operation (see [ipp-mod] sections 3.2.7.1 and
3.2.7.2), including section 3.3.3),
plus the new "printer-message-from-operator" "job-message-from-operator" operation attribute (see

                     Expires:  February 15, 2001

section 5).

11.3 Hold and Release New Jobs operations

This section defines operations to condition 6).  In addition, the Printer to hold any new
jobs and to release them.

Hold-New-Jobs operation

This OPTIONAL following operation allows a attributes are
defined:

  "predecessor-job-id":
     The client to condition the OPTIONALLY supplies this attribute.  The Printer MUST
     support it, if it supports this operation.  This attribute
     specifies the job after which the target job is to
complete be processed.
     If the current 'pending' and  'processing' IPP Jobs but not start
processing any subsequently created IPP Jobs.  If the IPP Printer is in
the middle of sending an IPP job to an Output Device or Subordinate
Printer, client omits this attribute, the IPP Printer MUST complete sending that Job.  Furthermore, process the IPP Printer MUST send all of
     target job next, i.e., after the current 'pending' IPP Jobs to job, if any.

The Schedule-Job-After Response has the
Output Device(s) or Subordinate IPP Printer object(s).  Any subsequently
received Job Creation operations will cause same attribute groups,
attributes, and status codes as the IPP Printer to put 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
Job into target job was not in the 'pending-held' 'pending'
     state with or the 'job-held-on-create' value
being added to predecessor job was no in the job's "job-state-reasons" attribute.  Thus all newly
accepted jobs will be automatically held by 'pending', 'processing',
     or 'processing-stopped' states.
  'client-error-not-found' - either the Printer.

When target job or the predecessor
     job was not found.

5  Additional status codes

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

5.1 'server-error-printer-is-deactivated' (0x050A)

The Printer completes all of has been deactivated using the 'pending' Deactivate-Printer operation
and 'processing' jobs,
it enters is only accepting the 'idle' state as usual. Activate-Printer (see section 3.5.1), Get-Job-
Attributes, Get-Jobs, Get-Printer-Attributes, and any other Get-Xxxx
operations.  An operator that is monitoring
Printer state changes will know when can perform the Printer has completed all
current jobs because Activate-Printer operation to
allow the Printer enters to accept other operations.

6  Use of Operation Attributes that are Messages from the 'idle' state. Operator

This operation MUST NOT affect the acceptance of Job Creation requests
(see Disable-Printer section 0), except to put the Jobs into summarizes the
'pending-held' state, instead usage of the 'pending' or 'processing' state.

The IPP Printer MUST accept the request in any state, MUST NOT
transition "printer-message-from-operator"
and "job-message-from-operator" operation attributes that set the
corresponding Printer to any other "printer-state", and MUST add the
'hold-new-jobs' value to the Printer's "printer-state-reasons" attribute
(whether the value was present or not).

Access Rights: The authenticated user Job Description attributes (see [ipp-mod] section 8.3)
performing this [ipp-set-ops]
for the definition of these operation must be an operator or administrator attributes).  These operation
attributes are defined for most of the
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Hold-New-Jobs Request Device and Hold-New-Jobs Response have Job operations that
operators are likely to perform, respectively, so that operators can
indicate the same
attribute groups and attributes as reasons for their actions.

Table 4 shows the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including attributes that are defined for use with the new "printer-
message-from-operator" operation attribute (see section 5).

Release-Held-New-Jobs operation

This OPTIONAL operation allows
Printer Operations.

Legend:

     REQ - REQUIRED for a client Printer to undo the effect of support
     OPT - OPTIONAL for a previous
Hold-New-Jobs operation.  In particular, Printer to support; the Printer releases all of ignores the
attribute if not supported

                     Expires:  January 6,  February 15, 2001

jobs that it had held as a consequence of a Hold-New-Jobs operations,
i.e., while the 'hold-new-jobs' value was present in
     <blank> - not defined for use with the Printer's
"printer-state-reasons" attribute.  In addition, operation; the Printer MUST accept
this request in any state, MUST NOT transition
ignores the attribute

      Table 4 - Operation attribute support for Printer to any other
"printer-state", and MUST remove the 'hold-new-jobs' value from its
"printer-state-reasons" attribute (whether the value was present or not)
so that the Operations

Operation    Pause-     Hold-New- Pur  Get-    Enabl Rest Shut
Attribute    Printer,   Jobs,     ge-  Printe  e-    art- down
             Pause-     Release-  Job  r-      Print Prin -
             Printer-   Held-New- s    Attrib  ,     ter  Prin
             After-     Jobs           utes,   Disab       ter,
             Current-                   Set-    le-         Star
             Job,                       Printe  Print       tup-
             Resume-                    r-      er          Prin
             Printer no longer holds newly created jobs.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an                    Attrib              ter
                                        utes

attributes-     REQ        REQ    REQ   REQ    REQ   REQ  REQ
charset

attributes-     REQ        REQ    REQ   REQ    REQ   REQ  REQ
natural-
language

printer-uri     REQ        REQ    REQ   REQ    REQ   REQ  REQ

requesting-     REQ        REQ    REQ   REQ    REQ   REQ  REQ
user-name

printer-        OPT        OPT    OPT           OPT   OPT  OPT
message-
from-
operator or administrator of the
Printer object (see [ipp-mod] Sections 1 and 8.5).

The Release-Held-New-Jobs Request and Release-Held-New-Jobs Response
have the same attribute groups and attributes as

Table 5 shows the Pause-Printer operation (see [ipp-mod] sections 3.2.7.1 and 3.2.7.2), including attributes that are defined for use with the
new "printer-message-from-operator" operation attribute (see section 5).

11.4 Deactivate and Activate
Job operations.
Legend:
     REQ - REQUIRED for a Printer Operations

This section defines the to support
     O - OPTIONAL Deactivate-Printer and Activate- for a Printer operations that stop and start to support; the IPP Printer object from
accepting all requests except queries and performing work.  If either of
these operations are supported, both MUST be supported.

These operations allow ignores the operator to put
          attribute if supplied, but not supported
     <blank> - not defined for use with the Printer into a dormant
read-only condition and to take it out of such a condition.  These
operations are a combination of operation; the Deactivate and Pause operations,
plus preventing Printer
     ignores the acceptance of any other requests, except queries. attribute

        Table 5 - Operation attribute support for Job operations

Operation        Can  Canc Hol  Sus  Res  Get-   Rest Repr  Pro  Sch
Attribute        cel  el-  d-   pen  ume  Job-   art- oces  mot  edu
                 -    Curr Job  d-   -    Attrib Job  s-    e-   le-
                 Job  ent- ,    Cur  Job  utes,        Job   Job  Job
                      Job  Rel  ren       Set-                    -
                            eas  t-        Job-                    Aft
                            e-   Job       Attrib                  er
                            Job            utes

attributes-      REQ  REQ  REQ  REQ  REQ   REQ   REQ  REQ  REQ  REQ
charset

attributes-      REQ  REQ  REQ  REQ  REQ   REQ   REQ  REQ  REQ  REQ
natural-language

printer-uri      REQ  REQ  REQ  REQ  REQ   REQ   REQ  REQ  REQ  REQ

                     Expires:  February 15, 2001

Operation        Can  Canc Hol  Sus  Res  Get-   Rest Repr  Pro  Sch
Attribute        cel  el-  d-   pen  ume  Job-   art- oces  mot  edu
                 -    Curr Job  d-   -    Attrib Job  s-    e-   le-
                 Job  ent- ,    Cur  Job  utes,        Job   Job  Job
                      Job  Rel  ren       Set-                    -
                            eas  t-        Job-                    Aft
                            e-   Job       Attrib                  er
                            Job            utes

job-uri          REQ      REQ      REQ   REQ   REQ  REQ  REQ  REQ

job-id           REQ  REQ  REQ  REQ  REQ   REQ   REQ  REQ  REQ  REQ

requesting-user- REQ  REQ  REQ  REQ  REQ   REQ   REQ  REQ  REQ  REQ
name

job-message-     OPT  OPT  OPT  OPT  OPT         OPT  OPT  OPT  OPT
from-operator

message [to-     OPT      OPT  OPT  OPT         OPT  OPT  OPT  OPT
operator]

job-hold-until             OPT                       OPT*
                             *                           *

*    The Deactivate and Activate Printer Operations MUST NOT affect support the
submission of jobs using other job submission protocols to "job-hold-until" operation attribute
if it supports the
associated Output Device; "job-hold-until" Job Template attribute.
**  The Printer MUST support the Deactivate "job-hold-until" operation attribute if
it supports the Set-Job-Attributes operation, so that the client can
hold the job with the Reprocess-Job operation and Activate Device Operations
(see [ipp-device-ops]) the modify the job
before releasing it to be processed.

7  New Printer Description Attributes

The following new Printer Description attributes are intended needed to stop support
the associated Output
Device(s) from performing work new operations defined in this document and accepting operations, except query
operations.

Deactivate-Printer operation

This OPTIONAL operation allows a client to stop the concepts of Printer object from
starting to send IPP jobs to any of its Output Devices or
Fan-Out (see section 11).

7.1 subordinate-printers-supported (1setOf uri)

This Printer attribute is REQUIRED if an implementation supports
Subordinate Printers (Pause-Printer-After-Current-Job) (see section 11) and stop contains the Printer object
from accepting any, but query requests.  The Printer performs a Disable-
Printer and a Pause-Printer-After-Current-Job operation immediately,
including use of all URIs of the "printer-state-reasons" if these two
operations cannot be completed immediately.  In addition, the
immediate Subordinate Printer
MUST immediately reject all requests, except Activate-Printer, queries
(Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs, etc.), Send-
Document, and Send-URI (so that partial job submission can be completed
- see section 0) and return the 'server-error-service-unavailable'
status code.

                      Expires:  January 6, 2001

The IPP object(s) associated with this Printer MUST accept the request in any state.  Immediately, the
object.  Each Non-Leaf Printer object MUST set the 'deactivated' value in its "printer-state-reasons" support this Printer
Description attribute.  Note: neither the Disable-Printer nor  A Leaf Printer object either does not support
the Pause-Printer-
After-Current-Job set "subordinate-printers-supported" attribute or does so with the 'deactivated' value.

Access Rights: The authenticated user 'no-
value' out-of-band value (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator 4.1), depending on
implementation.

The precise format of the Subordinate Printer object URIs is implementation
dependent (see [ipp-mod] Sections 1 and 8.5).

The Deactivate-Printer Request and Deactivate-Printer Response section 11.4).

If the Printer object does not have an associated Output Device, the
same attribute groups and attributes as
Printer MAY automatically copy the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including value of the new "printer-
message-from-operator" operation Subordinate Printer
object's "printer-name" MAY be used to populate the Job object's

                     Expires:  February 15, 2001

"output-device-assigned" attribute (see [ipp-mod] section 5).

Activate-Printer operation

This OPTIONAL operation allows a client to undo the effects of 4.3.13).  The
"output-device-assigned" Job attribute identifies the
Deactivate-Printer, i.e., allow Output Device to
which the Printer object to start sending IPP
jobs to any of its Output Devices has assigned a job, for example, when a single
Printer object is supporting Device Fan-Out or Printer Fan-Out.

7.2 parent-printers-supported (1setOf uri)

This Printer attribute is REQUIRED if an implementation supports
Subordinate Printers (Pause-
Printer-After-Current-Job) (see section 11) and start contains the URI of the Non-
Leaf printer object(s) for which this Printer object from accepting
any requests.  The Printer performs an Enable-Printer and a Resume-
Printer operation immediately.  In addition, is the immediate
Subordinate, i.e., this Printer's immediate "parent" or "parents".  Each
Subordinate Printer object MUST
immediately start accepting all requests.

The IPP support this Printer MUST accept the request in any state.  Immediately, the Description
attribute.  A Printer MUST immediately remove that has no parents, either does not support the 'deactivated' value from its
"printer-state-reasons"
"parent-printers-supported" attribute (whether present or not).

Access Rights: The authenticated user does so with the 'no-value'
out-of-band value (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator of 4.1), depending on
implementation.

8  Additional Values for "printer-state-reasons"

This section defines additional values for the "printer-state-reasons"
Printer object (see [ipp-mod] Sections 1 and 8.5). Description attribute.

8.1 'hold-new-jobs'

  'hold-new-jobs': The Activate-Printer Request and Activate-Printer Response have the same
attribute groups and attributes as the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including operator has issued the new "printer-
message-from-operator" Hold-New-Jobs operation attribute
     (see section 5).

11.5Restart-Printer, Shutdown-Printer, and Startup-Printer operations

This section defines 3.3.1) or other means, but the OPTIONAL Restart-Printer, Shutdown-Printer, and
Startup-Printer operations that initialize, shutdown, and startup output-device(s) are
     taking an appreciable time to stop.  Later, when all output has
     stopped, the
Printer object, respectively.  Each of these operations is OPTIONAL and
any combination MAY be supported.

The Restart-Printer, Shutdown-Printer, "printer-state" becomes 'stopped', and Startup-Printer operations
MUST NOT affect the submission of jobs using other job submission
protocols to the associated Output Device; 'paused'
     value replaces the Reset-Device and Power-
Off-Device Operations (see [ipp-device-ops]) are intended to initialize
or power off 'moving-to-paused' value in the associated Output Device(s).

                      Expires:  January 6, 2001

Restart-Printer operation "printer-state-
     reasons" attribute.  This OPTIONAL value MUST be supported, if the Hold-New-
     Jobs operation allows is supported and the implementation takes
     significant time to pause a device in certain circumstances.

8.2 'deactivated'

  'deactivated':  A client to restart has issued a Deactivate-Printer operation
     for the Printer object
whose operation (see section 3.4.1) and the Printer is in need of initialization because of incorrect or
erratic behavior, i.e., perform
     the effect process of a software re-boot. becoming deactivated or has become deactivated. The
implementation
     Printer MUST attempt to save any information about Jobs 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 3.1.1) and return the
Printer object before re-initializing.  However, this operation MAY have
drastic consequences on the running system, so the operator should first
try 'server-error-
     service-unavailable' status code.

9  Additional Values for "job-state-reasons"

This section defines additional values for the Deactivate-Printer to minimize "job-state-reasons" Job
Description attribute.

                     Expires:  February 15, 2001

9.1 'job-suspended'

  'job-suspended':  The job has been suspended while processing using
     the effect Suspend-Current-Job operation and other jobs can be processed
     on the current state
of the system. Printer.  The effects of previous Disable-Printer, Pause Printer,
and Deactivate-Printer operations are lost. Job can be resumed using the Resume-Job
     operation which removes this value.

10 Additional events

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

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

11 Use of the request in any state.  The Printer object MUST initialize its Printer's "printer-state" to 'idle', remove
the state reasons from its "printer-state-reasons" attribute, represent IPP Printer Fan-Out and its
"printer-is-accepting-jobs" attribute to 'true'.

Access Rights: The authenticated user (see [ipp-mod] IPP
   Printer Fan-In

This section 8.3)
performing this operation must be an operator or administrator of defines how the Printer object (see [ipp-mod] Sections 1 MAY be used to represent IPP
Printer Fan-Out and 8.5). IPP Printer Fan-In.  Fan-Out is where an IPP Printer
is used to represent other IPP Printer objects.  Fan-In is where several
IPP Printer objects are used to represent another IPP Printer object.

11.1 IPP Printer Fan-Out

The Restart-Printer Request and Restart-Printer Response have the same
attribute groups IPP/1.1 Model and attributes as Semantics introduces the Pause-Printer operation semantic concept of an
IPP Printer object that represents more than one Output Device (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).

                      Expires:  January 6, 2001

Shutdown-Printer Operation 2.1).  This OPTIONAL operation allows a client to shutdown a Printer, i.e.,
stop processing jobs and make the Printer object no longer available for
any operations using the IPP protocol without losing any jobs.  There concept is called "Output Device Fan-Out".
However, there was no way to bring represent the instance individual states of the Printer object back
Output Devices or to being used,
except for the Startup-Printer (see section 0) which starts up perform operations on a new
instance specific Output Device when
there was Fan-Out.  This document generalizes the semantics of the
Printer object for hosted implementations.  The purpose
of Shutdown-Printer is to shutdown the represent such Subordinate Fan-Out Output Devices as
IPP Printer for an extended period,
not to reset the device(s) or modify objects.  This concept is called "Printer object Fan-Out".
A Printer object that has a Subordinate Printer attribute.  See Restart- object is called a Non-
Leaf Printer (section 0), Startup-Printer (section ), and Reset-Device [ipp-
device-ops] for the way to initialize the software or reset the Output
Device(s).  See the Disable-Printer operation (section 11.1) for object.  Thus a way
for the client to stop the Non-Leaf Printer from accepting Job Creation requests
without stopping processing object supports one or shutting down.

The Printer MUST add the 'shutdown' value (see [ipp-mod] section 4.4.11)
immediately to its "printer-state-reasons"
more Subordinate Printer Description attribute
and performs a Deactivate-Printer operation (see section 0) which
performs a Disable-Printer and Pause-Printer-After-Current-Job
operation).

Note:  In objects in order to shutdown the represent Printer after all the currently
submitted jobs object
Fan-Out. A Printer object that does not have completed, the operator issues any Subordinate Printer
objects is called a Disable-Printer
operation (see section 0) Leaf Printer object.

Each Non-Leaf Printer object submits jobs to its immediate Subordinate
Printers and then waits until all otherwise controls the Subordinate Printers using IPP or
other protocols.  Whether pending jobs have
completed and are kept in the Non-Leaf Printer goes into the 'idle' state before issuing the
Shutdown-Printer operation.

The
until a Subordinate Printer object MUST can accept this operation them or are kept in any state and
transition the Printer object through the "printer-states" and "printer-
state-reasons" defined for the Pause-Printer-After-Current-Job operation
until the activity is completed
Subordinate Printers depends on implementation and/or configuration
policy.  Furthermore, a Subordinate Printer object MAY, in turn, have
Subordinate Printer objects.  Thus a Printer object can be both a Non-
Leaf Printer and the a Subordinate Printer.

A Subordinate Printer object disappears.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must MUST be an operator or administrator a conforming Printer object, so it
MUST support all of the
Printer object (see REQUIRED [ipp-mod] Sections 1 and 8.5).

The Shutdown-Printer Request operations and Shutdown-Printer Response have attributes.
However, with access control, the same
attribute groups Subordinate Printer MAY be configured

                     Expires:  February 15, 2001

so that end-user clients are not permitted to perform any operations (or
just Get-Printer-Attributes) while one or more Non-Leaf Printer
object(s) are permitted to perform any operation.

11.2 IPP Printer Fan-In

The IPP/1.1 Model and attributes as Semantics did not preclude the Pause-Printer operation semantic concept of
multiple IPP Printer objects that represent a single Output Device (see
[ipp-mod] sections 3.2.7.1 and 3.2.7.2), including the new "printer-
message-from-operator" operation attribute (see section 5).

Startup-Printer operation

This OPTIONAL operation allows a 2.1).  However, there was no way for the client to startup an instance of a
Printer object, provided
determine that there isn't one already instantiated.  The
purpose of Startup-Printer is to allow was a hosted implementation Fan-In configuration, nor was there a way to
perform operations on the Subordinate device.  This specification
generalizes the semantics of the
IPP Printer object (i.e., a Server that implements an to allow several Non-
Leaf IPP Printer on
behalf of objects to represent 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 way to initialize
the software or reset the Output Device(s) when the IPP single Subordinate Printer object
has already been instantiated.

                      Expires:  January 6, 2001

The host MUST accept this operation only when the
object.  Thus a Non-Leaf Printer object has not
been instantiated.  If the MAY share a Subordinate Printer
object already exists, the host must
return the 'client-error-not-possible' status code.

The result of this operation MUST be with the one or more other Non-Leaf Printer object's "printer-
state" set to 'idle', the state reasons removed from its "printer-state-
reasons" attribute, and its "printer-is-accepting-jobs" attribute set objects in order to
'false'.  Then the operator can reconfigure the
represent IPP Printer before
performing an Enable-Printer operation.  However, Fan-In.

As with Fan-Out (see section 11.1), when a Printer object is
first powered up, a Non-Leaf
Printer, it is RECOMMENDED that its "printer-is-accepting-jobs"
attribute be set MUST NOT have an associated Output Device.  As with Fan-Out,
a Leaf Printer object has one or more associated Output Devices.  As
with Fan-Out, the Non-Leaf Printer objects submit jobs to 'true' their
Subordinate Printer objects and otherwise control the Subordinate
Printer.  As with Fan-Out, whether pending jobs are kept in order to achieve easy "out of the box"
operation.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator Non-Leaf
Printers until the Subordinate Printer can accept them or administrator of are kept in
the Subordinate Printer depends on implementation and/or configuration
policy.

11.3 Printer object (see [ipp-mod] Sections 1 attributes used to represent Printer Fan-Out and 8.5).
    Printer Fan-In

The Shutdown-Printer Request and Shutdown-Printer Response have the same
attribute groups and following Printer Description attributes as are defined to represent
the Pause-Printer operation (see
[ipp-mod] sections 3.2.7.1 relationship between Printer object(s) and 3.2.7.2), including their Subordinate Printer
object(s):

1."subordinate-printers-supported" (1setOf uri) - contains the new "printer-
message-from-operator" operation attribute (see section 5).

                      Expires:  January 6, 2001

12 Definition URI of
  the Job Operations

All Job operations are directed at Job objects.  A client MUST always
supply some means immediate Subordinate Printer object(s).

2."parent-printers-supported (1setOf uri) - contains the URI of identifying the Job
  Non-Leaf printer object(s) for which this Printer object in order to identify the
correct target of is the operation.  That job identification MAY either be
a single Job URI
  immediate Subordinate, i.e., this Printer's immediate "parent" or a combination of a
  "parents".

11.4 Subordinate Printer URI with a Job ID.  The
IPP

Each Subordinate Printer object implementation MUST support both forms has a URI which is used as the target of identification for
every job.
each operation on the Subordinate Printer.  The Job Operations means for configuring
URIs for Subordinate Printer objects is implementation-dependent as are summarized in Table 8:

            Table 8 - Job
all URIs.  However, there are two distinct approaches:

     a. When the implementation wants to make sure that no operation Operation-Id assignments

  Operation Name  Operati Brief description
                  on-Id
  Reprocess-Job   0x??    Creates on
     a copy of Subordinate Printer object as a completed target
                           job with a new Job ID and processes it
  Cancel-Current- 0x??    Cancels the current job on "sneaks by" the target
  Job parent

                     Expires:  February 15, 2001
     Printer or object (or the specified job if it Subordinate Printer is fronting for a device
     that is not networked), the current job
  Suspend-        0x??    Suspends the current processing job on
  Current-Job              the target Printer or host part of the specified job
                           if it is URI specifies the current job, allowing
                           other jobs to be processed instead
  Resume-Job      0x??    Resume host
     of the suspended target job
  Promote-Job     0x??    Promote parent Printer.  Then the pending target job to be
                           next after parent Printer object can easily
     reflect the current job(s) complete
  Redirect-Job    0x??    Redirect state of the target job to Subordinate Printer objects in the
                           specified
     parent's Printer on object state and state reasons as the same server.
  Schedule-Job-   0x??    Schedule operation
     passes "through" the target job immediately
  After                    after parent Printer object.

     b. When the specified job, all other
                           scheduling factors being equal.

                      Expires:  January 6, 2001

12.1 Reprocess-Job Operation

This OPTIONAL operation Subordinate Printer is a create job operation that networked and the implementation
     allows a client operations to re-process a copy go directly to the Subordinate Printer (with
     proper access control) without knowledge 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 parent Printer
     object, the same as host part of the Restart-Job
operation (see [ipp-mod] section 3.3.7), except that URI is different than the host part of
     the parent Printer creates
a new job that is object.  In such a copy of case, the target job parent Printer
     object MUST keep its "printer-state" and "printer-state-reasons" up
     to date, either by polling the target job is
unchanged.  The new job is assigned new values Subordinate Printer object or by
     subscribing to events with the "job-uri" and
"job-id" attributes and Subordinate Printer object (see
     [ipp-not-spec] for means to subscribe to event notification when
     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 Subordinate Printer object supports IPP notification).

11.5 Printer object attributes used to 0 as with any create job operation.  The target job moves represent Output Device Fan-Out

Only Leaf IPP Printer objects are allowed to the Job
History after a suitable period, independent of whether have one or more
Reprocess-Job operations have been performed on it.

If associated
Output Devices.  Each Leaf Printer object MAY support the Set-Job-Attributes operation is supported, then "output-
devices-supported" (1setOf name(127)) to indicate the "job-hold-
until" operation attribute MUST be supported with at least user-friendly
name(s) of the
'indefinite' value, so Output Device(s) that a client can modify the new job before it Leaf Printer object represents.
It is
scheduled for processing using the Set-Job-Attributes operation.  After
modifying the job, RECOMMENDED that each Leaf Printer object have only one associated
Output Device, so that the client individual Output Devices can release the job for processing, be represented
completely and controlled completely by
using the Release-Job operation specifying the newly assigned "job-uri"
or "job-id" for clients.  In other words, the new job.

                      Expires:  January 6, 2001

12.2 Cancel-Current-Job Operation

This OPTIONAL operation allows
Leaf Printer's "output-devices-supported" attribute SHOULD have only one
value.

Non-Leaf Printer MUST NOT have associated Output Devices.  However, a client to cancel the current job on the
target
Non-Leaf Printer or the specified job if it is the current job on the
Printer.  See [ipp-mod] section 3.3.3 for SHOULD support an "output-devices-supported" (1setOf
name(127)) Printer Description attribute that contains all the semantics values of canceling a
job.
its immediate Subordinate Printers.  Since a Job might already such Subordinate Printers MAY
be marking by Leaf or Non-Leaf, the time a Cancel-Current-
Job is received, some media sheet pages might be printed before same rules apply to them, etc.  Thus any Non-
Leaf Printer SHOULD have an "output-devices-supported" (1setOf
name(127)) attribute that contains all the job
is actually terminated.

If values of the client does not supply Output Devices
associated with Leaf Printers of its complete sub-tree.

When adding, removing, or changing a "job-id" operation attribute, the
Printer MUST accept the request configuration of Printers and cancel the current job if
Output Devices, there is a
current job can be moments in time when 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 tree structure is in
not consistent.  In other words, times when a Non-Leaf Printer's
"subordinate-printers-supported" does not agree with the 'processing' or
'processing-stopped' states, Subordinate
Printer's "parent-printers-supported".   Therefore, the one operator SHOULD
first Deactivate all Printers 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 being configured in this operation way,
update all pointer attributes, and its acceptance, the current
job might change to then reactivate.  A useful client
tool would validate a different job.  If tree structure before Activating the user or operator is
authenticated Printers
involved.

                     Expires:  February 15, 2001

11.6 Figures to cancel the new job, the wrong job is canceled.  To
prevent this race show all possible configurations

Figure 1, Figure 2, and Figure 3 are taken from canceling the wrong job, the client MAY supply [ipp-mod] to show 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
configurations possible with IPP/1.0 and
return the 'client-error-not-possible' status code.  Otherwise, the IPP/1.1 where all Printer cancels the specified job.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must either be the job owner (as determined in
the Job Creation operation) or an operator or administrator of the
objects are Leaf Printer object (see [ipp-mod] Sections 1 and 8.5). objects.  The Cancel-Current-Job Request and Cancel-Current-Job Response have the
same attribute groups remaining figures show additional
configurations that this document defines using Non-Leaf 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 5), Leaf
Printer objects. Legend for all figures:

----> indicates a network protocol with the addition direction 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 its requests

##### indicates a Printer object.  The IPP object MUST supports this operation
     attribute, if it supports this operation.

                      Expires:  January 6, 2001

12.3 Suspend and Resume Job operations

This section defines the Suspend-Current-Job and Resume-Job operations.
These operations allow which is either:
        - embedded in an operator Output Device or user to suspend
        - hosted in 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-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 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 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
job might change to a different job.  If the user or operator is
authenticated to suspend the new job, the wrong job is 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' status code.  Otherwise, the
Printer suspends the specified job and processed other jobs.

The Printer MUST reject a Resume-Job request (and return the 'client-
error-not-possible') for a job that has been suspended , i.e., for a job
in the 'processing-stopped' state, with the 'job-suspended' value in its
"job-state-reasons" attribute.

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

                      Expires:  January 6, 2001

The Suspend-Current-Job Request and Suspend-Current-Job Response have
the same attribute groups and attributes as the Pause-Printer operation
(see [ipp-mod] section 3.2.8 ), including the new "job-message-from-
operator" operation attribute (see section 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.

Resume-Job operation

This OPTIONAL operation allows a client to resume the target job at the
point where it was suspended.  The Printer moves the target job to the
'pending' state and removes the '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-suspended' value in the job's "job-state-reasons" attribute, the
Printer MUST reject the request and return the 'client-error-not-
possible' status code, since the job was not suspended.

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

The Resume-Job Request and Resume-Job Response have the same attribute
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 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. server.  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, suspended, object
      might 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.

IPP is specified might not to require queues for job scheduling, since there
are other implementation techniques for scheduling multiple jobs, such
as re-evaluating a criteria function for each job on a scheduling cycle.
However, if an implementation does implement queues for jobs, then the
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: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must be an operator or administrator capable of the queuing/spooling.

any   indicates any network protocol or direct
      connect, including IPP
                                               Output Device
                                             +---------------+
                                             |  ###########  |
 O   +--------+                              |  # (Leaf)  #  |
/|\  | client |------------IPP-----------------># Printer object (see [ipp-mod] Sections #  |
/ \  +--------+                              |  # Object  #  |
                                             |  ###########  |
                                             +---------------+

                   Figure 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 5).

12.5 Redirect-Job operation

This OPTIONAL operation allows a - Embedded Printer object

                          ###########          Output Device
 O   +--------+           # (Leaf)  #        +---------------+
/|\  | client to redirect a not-completed job
to another |---IPP----># Printer on the same server.  Redirect-Job is defined to be a
Job Creation operation, along with the 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 new #---any->|               |
/ \  +--------+           # object  #        |               |
                          ###########        +---------------+

                    Figure 2 - Hosted Printer
validates the job using all of its "xxx-supported" attributes and either
accepts or rejects the job.  If the job is rejected, it remains in its object

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

                    Figure 3 - Output Device Fan-Out

                     Expires:  January 6,  February 15, 2001

original state before the Redirect-Job operation was attempted.  As an
other example, the Job inherits the defaults for the new
                          ###########           ###########
 O   +--------+           # Non-Leaf#           # subord. #
/|\  | client |---IPP----># Printer (since
the defaults aren't copied onto the Job #---IPP----># Printer #
/ \  +--------+           # object when it is created, but
are applied when the job is processed - see [ipp-mod]).  Finally, this
operation generates  #           # object  #
                          ###########           ###########

The Subordinate Printer can be a 'job-created' event Non-Leaf Printer as does any Job Creation
Operation.

In order in Figure 4 to preserver the "ipp-attribute-fidelity" semantics that the
original client supplied when the job was first created, each Job
Creation Operation copies the "ipp-attributes-fidelity" (boolean)
operation attribute o the job as
Figure 6, or can be a Job Description attribute, if the
Redirect-Job operation is supported.  Then the "ipp-attribute-fidelity"
attribute is re-used by the new Leaf Printer during its job validation,
unless the as in Figure 1 to Figure 3.

                 Figure 4 - Chained IPP Printer Objects

                +------IPP--------------------->###########
               /                           +---># subord. #
              /                           /     # Printer #
             /            ###########   any     # object  #
 O   +--------+           # Non-Leaf#   /       ###########
/|\  | client performing the Redirect-Job operation supplies the
"ipp-attribute-fidelity" operation attribute.

This operation is limited |---IPP----># Printer #--*
/ \  +--------+           # object  #   \
             \            ###########   any     ###########
              \                           \     # subord. #
               \                           +---># Printer #
                +------IPP---------------------># object  #
                                                ###########

The Subordinate Printer can be a Non-Leaf Printer as in Figure 4 to redirecting
Figure 6, or can be a job Leaf Printer as in Figure 1 to another Figure 3.

                 Figure 5 - IPP Printer Object 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 on the
same server.  Thus the same copy of the job MAY can be used, depending on
implementation.  Also, depending on implementation, the new a Non-Leaf Printer MAY
generate as in Figure 4, Figure
5, or Figure 6, or can be a new job-id and job-uri, Leaf Printer as in Figure 1, Figure 2, or use the same one.  In either case
the response contains the "job-id" and "job-uri" for
Figure 3.

                  Figure 6 - IPP Printer Object Fan-In

                     Expires:  February 15, 2001

11.7 Forwarding requests

This section describes the redirected job
as for any forwarding of 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 Printer requests to
Subordinate Printer objects.

11.7.1    Forwarding requests that are associated with the job.

The affect Printer MUST accept this operation whenever the job is in the
'pending' or 'pending-held' states.  The objects

In Printer MUST reject this
operation whenever the job is in the 'completed', 'aborted', or
'canceled' states Fan-Out, Printer Fan-In, and return the 'client-error-not-possible' status
code.  Whether Chained Printers, the Non-Leaf
IPP Printer accepts this operation when the job is in object MUST NOT forward the
'processing' or 'processing-stopped' states depends on implementation.

Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must either be operations that affect Printer
objects to its Subordinate Printer objects.  If a client wants to
explicitly target a Subordinate Printer, the job owner (as determined in client MUST specify the Job Creation operation) or an operator or administrator URI
of the
Printer object (see [ipp-mod] Sections 1 and 8.5). Subordinate Printer.   The Redirect-Job Request have the same attribute groups and attributes
as client can determine the Create-Job operation (see [ipp-mod] section 3.2.4), plus URI of any
Subordinate Printers by querying the new
"job-message-from-operator" operation Printer's "subordinate-printers-
supported (1setOf uri) attribute (see section 5).  In
addition, the following operation attributes are defined:

  Target:
     Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX))
     or (2) 7.1).

Table 6 lists the "job-uri" (uri) operation attribute(s) which define operations that affect Printer objects and the
     target for this operation as described in
forwarding behavior that a Non-Leaf Printer MUST exhibit to its
immediate Subordinate Printers.  Operations that affect jobs have a
different forwarding rule (see section 11.7.2 and Table 7):

      Table 6 - Forwarding operations that affect Printer objects

Printer Operation     Non-Leaf Printer action

Printer Operations:
  Enable-Printer     MUST NOT forward to any of its Subordinate
                      Printers
  Disable-Printer    MUST NOT forward to any of its Subordinate
                      Printers
  Hold-New-Jobs      MUST NOT forward to any of its Subordinate
                      Printers
  Release-Held-New-  MUST NOT forward to any of its Subordinate
  Jobs               Printers
  Deactivate-Printer MUST NOT forward to any of its Subordinate
                      Printers
  Activate-Printer   MUST NOT forward to any of its Subordinate
                      Printers
  Restart-Printer    MUST NOT forward to any of 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       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

                     Expires:  February 15, 2001

Printer Operation     Non-Leaf Printer action

  Attributes         Printers

11.7.2    Forwarding requests that affect Jobs

Unlike Printer Operations that only affect Printer objects (see section 3.1.5.
     The client MUST supply this attribute and the
11.7.1), a Non-Leaf Printer object MUST support
     it.

  new-printer-uri (uri):
     The URI forward operations that directly
affect jobs to the appropriate Job object(s) in one or more of another its
immediate Subordinate Printer objects.  Forwarding is REQUIRED since the
purpose of such a Job operation is to affect the indicated job which
itself may have been forwarded.  Such forwarding MAY be immediate or
queued, depending on the same server.  The client MUST
     supply this attribute operation and the implementation.  For example,
a Non-Leaf Printer MUST support it.

                      Expires:  January 6, 2001
  ipp-attribute-fidelity (boolean):
     The client object MAY supply this attribute, but the Printer MUST support
     it.  It indicates whether queue/spool jobs, feeding a job at a time
to its Subordinate Printer(s), or not MAY forward jobs immediately to one of
its Subordinate Printers.  In either case, the Non-Leaf Printer object
is forwarding Job Template attributes on Creation operations to one of its Subordinate
Printers.  Only the
     Job object MUST be supported by time of forwarding of the new Printer.  If Job Creation operations
depends on whether the client
     omits this attribute, policy is to queue/spool jobs in the new Non-Leaf
Printer uses the value copied to or the
     job as Subordinate Printer.

When a Non-Leaf Printer object creates a Job Description attribute when the job was originally
     created.  The object in its Subordinate
Printer, whether that Non-Leaf Printer object keeps a fully formed Job Description attribute is not affected
object or just keeps a mapping from the "job-ids" that it assigned to
those assigned by its Subordinate Printer object is IMPLEMENTATION-
DEPENDENT.  In either case, the
     value supplied in this request, so Non-Leaf Printer MUST be able to accept
and carry out future Job operations that specify the original user's intent
     is preserved across multiple Redirect-Job operations.

The Redirect-Job Response has "job-id" that the same attribute groups, attributes,
Non-Leaf Printer assigned and
status codes as the Create-Job operation (see [ipp-mod] section 3.2.4).
The following status codes have particular meaning for this operation:

  'client-error-not-possible' - returned to the job was in the 'completed',
     'aborted', or 'canceled' states or submitting client.

Table 7 lists the implementation does not
     support operations that directly affect jobs and the Redirect-Job operation on
forwarding behavior that a job when it is in the
     'processing' or 'processing-stopped' states.
  'client-error-not-found' - the target job was not found.
  'client-error-attributes-or-values-not-supported' Non-Leaf Printer MUST exhibit to its
Subordinate Printers:

        Table 7 - the specified Forwarding operations that affect Jobs objects

  Job operation       Non-Leaf Printer is not supported for redirection, i.e., action

  Job operations:
        Reprocess-Job MUST forward to the URI was not
     amongst appropriate Job in one of
                      its Subordinate Printers
        Cancel-       MUST NOT forward
  Current-Job
        Resume-Job    MUST forward to the Printer's "redirection-printers-supported" (1setOf
     uri).

12.6 Schedule-Job-After operation

This OPTIONAL operation allows a client appropriate Job in one of
                      its Subordinate Printers
        Promote-Job   MUST forward to request the appropriate Job in one of
                      its Subordinate Printers
  IPP/1.1 Printer
  Operations:
        Print-Job     MUST forward immediately or queue to
schedule the target job so that it will be processed
                      appropriate Subordinate Printer
        Print-URI     MUST forward immediately after
the specified job, all other scheduling factors being equal.

IPP is specified not or queue to require queues for job scheduling, since there
are other implementation techniques for scheduling multiple jobs, such
as re-evaluating a criteria function for each job on a scheduling cycle.
However, if an implementation does implement queues for jobs, then the
Schedule-Job-After
                      appropriate Subordinate Printer

                     Expires:  February 15, 2001
  Job operation puts       Non-Leaf Printer action

        Validate-Job  MUST forward to the specified job appropriate Subordinate
                      Printer
        Create-Job    MUST forward immediately after or queue to the specified job
                      appropriate Subordinate Printer
        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 queue to the
                      appropriate Job in one of its Subordinate
                      Printers
        Send-URI      MUST forward immediately or queue to the queue.  A subsequent Schedule-Job-After
operation specifying
                      appropriate Job in one of its Subordinate
                      Printers
        Cancel-Job    MUST forward to the same job will cause appropriate Job in one of
                      its target job Subordinate Printers
        Get-Job-      MUST forward to be placed
after that job, even though it is between the first target job and appropriate Job in one of
  Attributes          its Subordinate Printers, if the
specified job.  For example, suppose Non-Leaf
                      Printer doesn't know the job queue consisted complete status of jobs: A,
B, C, D, and E, in that order.  A Schedule-Job-After with job E as the
target and B as
                      Job object
        Hold-Job      MUST forward to the specified job would result appropriate Job in one of
                      its Subordinate Printers
        Release-Job   MUST forward to the following queue:
A, B, E, C, D.  A subsequent Schedule-Job-After with appropriate Job D as the target
and B as the specified job would result in one of
                      its Subordinate Printers
        Restart-Job   MUST forward to the following queue:  A, B,
D, E, C.  In other words, the link between the two jobs appropriate Job in a Schedule-
Job-After is ephemeral, rather than setting an attribute of either one of
                      its Subordinate Printers
  IPP Set operations: See [ipp-set-ops]
        Set-Job-      MUST forward to the jobs.

If the target job is not appropriate Job in the 'pending' state, the one of
  Attributes          its Subordinate Printers

When a Printer MUST reject
the receives a request that REQUIRES forwarding, it does so
on a "best efforts basis", and returns the 'client-error-not-possible' status code,
since the job cannot have a response to its position changed.  The predecessor job client without
waiting for responses from any of its Subordinate Printers.  Such
forwarded requests could fail.  In order for a client to become aware of
such a condition, a new 'forwarded-operation-failed' event is defined,
which a client can
be in the 'pending', 'processing', or 'processing-stopped' states.

                      Expires:  January 6, 2001

Access Rights: The authenticated user subscribe to (see [ipp-mod] section 8.3)
performing 10 and [ipp-ntfy]).

The following Job Description attributes are defined to help represent
Job relationships for Fan-Out and forwarding of jobs:

1."output-device-assigned" (name(127)) - from [ipp-mod]: This attribute
  identifies the Output Device to which the Printer object has assigned
  this operation must job.  If an Output Device implements an embedded Printer object,
  the Printer object NEED NOT set this attribute.  If a print server
  implements a Printer object, the value MAY be operator empty (zero-length
  string) or administrator of not returned until the Printer object (see [ipp-mod] Sections 1 and 8.5).

The Schedule-Job-After Request have assigns an Output
  Device to the same job.  This attribute groups and
attributes as the Cancel-Job operation (see [ipp-mod] section 3.3.3),
plus the new "job-message-from-operator" is particularly useful when a
  single Printer object supports multiple devices (so called "Fan-
  Out").

2."original-requesting-user-name" (name(MAX)) - operation attribute (see
section 5).  In addition,
  containing the user name of the original user, i.e., corresponds to

                     Expires:  February 15, 2001
  the following "requesting-user-name" operation attributes are
defined:

  "predecessor-job-id":
     The client OPTIONALLY supplies this attribute.  The Printer MUST
     support it, if it supports this operation.  This attribute
     specifies that the job after which original
  client supplied to the target job first Printer object.  The IPP/1.1
  "requesting-user-name" operation attribute (see [ipp-mod]) is updated
  by each client to be scheduled.
     If itself on each hop, i.e., the client omits this attribute, "requesting-user-
  name" is the Printer MUST schedule client forwarding the
     target job next, i.e., after request, not the current job, if any. original client.
  The Schedule-Job-After Response has the same "job-originating-user-name" Job Description attribute groups,
attributes, and status codes remains as
  the 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 target job was authenticated original user, not in the 'pending'
     state or the predecessor job was no in the 'pending', 'processing',
     or 'processing-stopped' states.
  'client-error-not-found' - either the target job or parent Printer's
  authenticated host, and is forwarded by each client without changing
  the predecessor
     job was not found.

                      Expires:  January 6, 2001

13 value.

12 Conformance Requirements

The Job and Printer Administrative operations defined in this document
are OPTIONAL operations.  However, some operations MUST be implemented
if others are implemented as shown in Table 9. 8.

     Table 9 8 - 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

Schedule-Job-After     Promote-Job

Table 10 9 and Table 11list 10 list the "printer-state-reasons" and "job-state-
reasons" values that are REQUIRED if the indicated operations are
supported.

                     Expires:  February 15, 2001
   Table 10- 9 - Conformance Requirement Dependencies for "printer-state-
                            reasons" Values

"printer-state-       Conforman  If any of the following Printer
reasons" values:      ce         Operations 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         REQUIRED   Deactivate-Printer

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

"job-state-reasons"   Conforman  If any of the following Job operations
values:               ce         are supported:
                      Requireme
                      nt

'job-suspended'       REQUIRED   Suspend-Current-Job

'printer-stopped'     REQUIRED   always REQUIRED

14

13 IANA Considerations

The operations and 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/ipp-admin-ops.txt

15

14 Internationalization Considerations

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

16

15 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 the mechanism by which the
client proves its identity to the server in a secure manner. Server
Authentication is the mechanism by which the server proves its identity
to the client in a secure manner. Operation Privacy is defined as a
mechanism for protecting operations from eavesdropping.

17

                     Expires:  February 15, 2001

16 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

17 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-ntfy]
     Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
     Bergman, R., "Internet Printing Protocol/1.1: IPP Event
     Notification Specification", <draft-ietf-ipp-not-spec-04.txt>, July
     13, 2000.

[ipp-ops-admin-req]
     Hastings, T., "Internet Printing Protocol (IPP): Requirements for
     Job, Printer, and Device Administrative Operations", <draft-ietf-
     ipp-ops-admin-req-00.txt>, work in progress, July 19, 2000.

                     Expires:  February 15, 2001

[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

Change History of this document is available at:
     ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-change-
     history.txt

18 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,
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:  January 6,  February 15, 2001