draft-ietf-ipp-ops-admin-req-00.txt   rfc3239.txt 
Internet Printing Protocol WG Carl Kugler Network Working Group C. Kugler
INTERNET-DRAFT H. Lewis Request for Comments: 3239 H. Lewis
<draft-ietf-ipp-ops-admin-req-00.txt> IBM Corporation Category: Informational IBM Corporation
Category: Informational T. Hastings (editor) T. Hastings
Xerox Corporation Xerox Corporation
August 15, 2000 February 2002
Internet Printing Protocol (IPP):
Requirements for Job, Printer, and Device 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 Internet Printing Protocol (IPP):
provisions of Section 10 of [rfc2026]. Internet-Drafts are working Requirements for Job, Printer, and Device Administrative Operations
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 Status of this Memo
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 This memo provides information for the Internet community. It does
http://www.ietf.org/ietf/1id-abstracts.txt not specify an Internet standard of any kind. Distribution of this
The list of Internet-Draft Shadow Directories can be accessed as memo is unlimited.
http://www.ietf.org/shadow.html.
Abstract Copyright Notice
This document is a submission to the Internet Printing Protocol Working Copyright (C) The Internet Society (2002). All Rights Reserved.
Group of the Internet Engineering Task Force (IETF). After approval, it
is intended to be an Informational RFC. Comments should be submitted to
the ipp@pwg.org mailing list.
This document specifies the requirements and use cases for some OPTIONAL Abstract
administrative operations for use with the Internet Printing
Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 [ipp-mod, ipp-pro].
Some of these administrative operations operate on the IPP Job and
Printer objects. The remaining operations operate on a new Device
object that more closely models a single output device (see [ipp-mod]).
Expires: January 17, 2001 This document specifies the requirements and uses cases for some
The scope of IPP, is characterized in RFC2526 "Design Goals for an optional administrative operations for use with the Internet Printing
Internet Printing Protocol". It is not the intent of this document to Protocol (IPP) version 1.0 and version 1.1. Some of these
revise or clarify this scope or conjecture as to the degree of industry administrative operations operate on the IPP Job and Printer objects.
adoption or trends related to IPP within printing systems. It is the The remaining operations operate on a new Device object that more
intent of this document to extend the original set of operations - in a closely models a single output device.
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: Table of Contents
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]
The "Design Goals for an Internet Printing Protocol" document takes a 1 Introduction.....................................................2
broad look at distributed printing functionality, and it enumerates 2 Terminology......................................................2
real-life scenarios that help to clarify the features that need to be 3 Requirements and Use Cases.......................................3
included in a printing protocol for the Internet. It identifies 4 IANA Considerations.............................................10
requirements for three types of users: end users, operators, and 5 Internationalization Considerations.............................10
administrators. It calls out a subset of end user requirements that are 6 Security Considerations.........................................10
satisfied in IPP/1.0. A few OPTIONAL operator operations have been 7 References......................................................11
added to IPP/1.1. Appendix A: Description of base IPP documents......................12
Authors' Addresses.................................................14
Full Copyright Statement...........................................15
The "Rationale for the Structure and Model and Protocol for the Internet List of Tables
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 Table 1 - List of Printer Operations and corresponding Device
simplified model with abstract objects, their attributes, and their Operations ..................................................... 9
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 1 Introduction
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 The Internet Printing Protocol (IPP) is an application level protocol
insight and advice to implementers of IPP clients and IPP objects. It that can be used for distributed printing using Internet tools and
is intended to help them understand IPP/1.1 and some of the technologies. IPP version 1.1 ([RFC2911, RFC2910]) focuses on end
considerations that may assist them in the design of their client and/or user functionality with a few administrative operations included (for
IPP object implementations. For example, a typical order of processing a description of the base IPP documents, see Appendix A). This
requests is given, including error checking. Motivation for some of the document defines the requirements and use cases for additional
specification decisions is also included. optional end user, operator, and administrator operations used to
control Job objects, Printer objects (see [RFC2911]) and a new Device
object. The new Device object more closely models a single output
device and has no notion of a job, while the Printer object models a
print service which understands jobs and may represent one or more
output devices.
Expires: January 17, 2001 The scope of IPP is characterized in RFC 2567 [RFC2567] "Design Goals
The "Mapping between LPD and IPP Protocols" document gives some advice for an Internet Printing Protocol". It is not the intent of this
to implementers of gateways between IPP and LPD (Line Printer Daemon) document to revise or clarify this scope or conjecture as to the
implementations. 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.
Expires: January 17, 2001 2 Terminology
Table of Contents
1 Introduction........................................................5 This section defines terminology used throughout this document and
the corresponding documents that define the Administrative operations
on Job, Printer, and Device objects.
2 Terminology.........................................................5 This document uses terms such as "client", "Printer", "Job",
"attributes", "keywords", and "support". These terms have special
meaning and are defined in the model terminology [RFC2911] section
12.2.
3 Requirements and Use Cases..........................................6 In addition, the following capitalized terms are defined:
4 IANA Considerations................................................10 IPP Printer object (or Printer for short) - a software abstraction
defined by [RFC2911].
5 Internationalization Considerations................................10 Printer Operation - an operation whose target is an IPP Printer
object and whose effect is on the Printer object.
6 Security Considerations............................................10 Output Device - the physical imaging mechanism that an IPP Printer
controls. Note: while this term is capitalized in this
specification (but not in [RFC2911]), there is no formal object
called an Output Device.
7 Author's Addresses.................................................10 Device Operation - an operation whose target is an IPP Printer
object and whose defined effect is on an Output Device.
8 References.........................................................11 Output Device Fan-Out - a configuration in which an IPP Printer
controls more that one output-device.
9 Appendix A: Full Copyright Statement...............................11 Printer fan-out - a configuration in which an IPP Printer object
controls more than one Subordinate IPP Printer object.
List of Tables Printer fan-in - a configuration in which an IPP Printer object is
Table 1 - List of Printer Operations and corresponding Device Operations controlled by more than one IPP Printer object.
..................................................................9
Expires: January 17, 2001 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.
1 Introduction Leaf Printer - a Subordinate Printer that has no Subordinate
Printers.
The Internet Printing Protocol (IPP) is an application level protocol Non-Leaf Printer - an IPP Printer object that has one or more
that can be used for distributed printing using Internet tools and Subordinate Printers.
technologies. IPP version 1.1 ([ipp-mod, ipp-pro]) focuses on end user
functionality with a few administrative operations included. This
document defines the requirements and use cases for additional OPTIONAL
end user, operator, and administrator operations used to control Job
objects, Printer objects (see [ipp-mod]) and a new Device object. The
new Device object more closely models a single output device and has no
notion of a job, while the Printer object models a print service which
understands jobs and MAY represent one or more output devices.
2 Terminology Chained Printer - a Non-Leaf Printer that has exactly one
Subordinate Printer.
This section defines terminology used throughout this document and the Job Creation operations - IPP operations that create a Job object:
corresponding documents that define the Administrative operations on Print-Job, Print-URI, and Create-Job.
Job, Printer, and Device objects.
This document uses terms such as "attributes", "keywords", and 3 Requirements and Use Cases
"support". These terms have special meaning and are defined in the
model terminology [ipp-mod] section 12.2.
In addition, the following capitalized terms are defined: The Administrative operations for Job and Printer objects will be
defined in one document [ipp-ops-set2]. The Administrative
operations for Device objects will be defined in a separate document.
The requirements are presented here together to show the parallelism.
IPP Printer object (or Printer for short) - a software abstraction 1. Have separate operations for affecting the IPP Printer
defined by [ipp-mod]. versus affecting the Output Device, so its clear what the
intent of each is, and implementers can implement one or the
other or both.
Printer Operation - an operation whose target is an IPP Printer 2. Support fan-out of Printer objects.
object and whose effect is on the Printer object.
Output Device - the physical imaging mechanism that an IPP Printer 3. Support fan-out of Output Devices.
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 4. Support fan-in of Printer objects, as long as it doesn't
and whose defined effect is on an Output Device. make the semantics more complicated when not supporting
fan-in.
Output Device Fan-Out - a configuration in which an IPP Printer 5. Support fan-in of output objects, as long as it doesn't make
controls more that one output-device. the semantics more complicated when not supporting fan-in.
Printer fan-out - a configuration in which an IPP Printer object 6. Instead of having operation attributes that alter the
controls more than one Subordinate IPP Printer object. 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) and it is simple to
describe the capabilities of a Printer implementation in
written documentation (just list the optional operations
supported).
Printer fan-in - a configuration in which an IPP Printer object is 7. Need a Printer Operation to prevent a Printer object from
controlled by more than one IPP Printer object. accepting new IPP jobs, but currently accepted jobs continue
unaffected to be scheduled and processed. Need a companion
one to restore the Printer object to accept new IPP jobs.
Subordinate Printer - an IPP Printer object that is controlled by Usage: Operator is preparing to take the IPP Printer out of
another IPP Printer object. Such a Subordinate Printer MAY have service or to change the configuration of the IPP Printer.
one or more Subordinate Printers.
Leaf Printer - a Subordinate Printer that has no Subordinate Suggested name and operations: Disable-Printer and Enable-
Printers. Printer
Non-Leaf Printer - an IPP Printer object that has one or more 8. Need a Device Operation to prevent an Output Device from
Subordinate Printers. accepting any new jobs from any job submission protocol and
a companion one to restore the Output Device to accepting
any jobs.
Chained Printer - a Non-Leaf Printer that has exactly one Subordinate Usage: Operator is preparing to take the Output Device out
Printer. of service.
Job Creation operations - IPP operations that create a Job object: Suggested name and operations: Disable-Device and Enable
Print-Job, Print-URI, and Create-Job. Device
Expires: January 17, 2001 9. Need a Printer Operation to stop the processing after the
current IPP job completes and not start processing any
additional IPP jobs (either by scheduling the jobs or
sending them to the Output Device), but continue to accept
new IPP jobs. Need a companion operation to start
processing/sending IPP jobs again.
3 Requirements and Use Cases Usage: Operator wants to gracefully stop the IPP Printer at
the next job boundary. The Pause-Printer-After-Current-Job
operation is also invoked implicitly by the Deactivate-
Printer and the Shutdown-Printer Operations.
The Administrative operations for Job and Printer objects will be Suggested name and operations: Pause-Printer-After-
defined in one document [ipp-admin-ops]. The Administrative operations Current-Job, (IPP/1.1) Resume-Printer
for Device objects will be defined in a separate document (see [ipp-
device-ops]). The requirements are presented here together to show the
parallelism.
1.Have separate operations for affecting the IPP Printer versus 10. Need a Device Operation to stop the processing the current
affecting the Output Device, so its clear what the intent of each is job "immediately", no matter what protocol. Its like the
and implementers can implement one or the other or both. Pause button on 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 a companion operation to
start processing the current any-protocol job without losing
any thing.
2.Support fan-out of Printer objects. Usage: Operator sees something bad about to happen, such as
the paper is about to jam, or the toner is running out, or
the device is overheating or wants to add more paper.
3.Support fan-out of Output Devices. Suggested name and operations: Pause-Device-Now, Resume-
Device
4.Support fan-in of Printer objects, as long as it doesn't make the 11. Need a Printer Operation to stop the processing of IPP jobs
semantics more complicated when not supporting fan-in. after all of the currently accepted jobs have been
processed, but any newly accepted jobs go into the
'processing-held' state.
5.Support fan-in of output objects, as long as it doesn't make the Usage: This allows an operator to reconfigure the Output
semantics more complicated when not supporting fan-in. Device in order to let jobs that are held waiting for
resources, such as special media, get a chance. Then the
operator uses another operation after reconfiguring. He
repeats the two operations to restore the Output Device to
its normal media.
6.Instead of having operation attributes that alter the behavior of the Suggested name and operations: Hold-New-Jobs, Release-
operation significantly, have separate operations, so that it is Held-New-Jobs
simple and clear to a client which semantics the Printer is
supporting (by querying the "operations-supported" attribute) and it
is simple to describe the capabilities of a Printer implementation in
written documentation (just list the OPTIONAL operations supported).
7.Need a Printer Operation to prevent a Printer object from accepting 12. Need a Device Operation to stop processing the current any-
new IPP jobs, but currently accepted jobs continue unaffected to be protocol job at a convenient point, such as after the
scheduled and processed. Need a companion one to restore the Printer current copy (or end of job if last or only copy). Need a
object to accept new IPP jobs. companion operation to start processing the current any-
protocol job or next job without losing any thing.
Usage: Operator is preparing to take the IPP Printer out of service Usage: The operator wants to empty the output bin that is
or to change the configuration of the IPP Printer. near full. The paper path is run out.
Suggested name and operations: Disable-Printer and Enable-Printer Suggested name and operations: Pause-Device-After-Current-
Copy, Resume-Device
8.Need a Device Operation to prevent an Output Device from accepting 13. Need a Device Operation that always pauses on a device-
any new jobs from any job submission protocol and a companion one to defined boundary, no matter how many copies, in order to not
restore the Output Device to accepting any jobs. break up a job. Need a companion operation to start
processing the current any-protocol job or next job without
losing any thing.
Usage: Operator is preparing to take the Output Device out of Usage: The operator wants to empty the output bin that is
service. 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: Disable-Device and Enable Device Suggested name and operations: Pause-Device-After-Current-
Job, Resume-Device
9.Need a Printer Operation to stop the processing after the current IPP 14. Need a Printer Operation that combines Disable-Printer,
job completes and not start processing any additional IPP jobs Pause-Printer-After-Current-Job, and rejects all other Job,
(either by scheduling the jobs or sending them to the Output Device), Printer, and Device Operations, except Job and Printer
but continue to accept new IPP jobs. Need a companion operation to queries, System Administrator Set-Printer-Attributes, and
start processing/sending IPP jobs again. the companion operation to resume activity. In other words,
this operation makes the Printer a read-only object in a
graceful manner for end-users and the operator.
Usage: Operator wants to gracefully stop the IPP Printer at the next Usage: The administrator wants to reconfigure the Printer
job boundary. The Pause-Printer-After-Current-Job operation is also object using the Set-Printer-Attributes operation without
invoked implicitly by the Deactivate-Printer and the Shutdown-Printer disturbing the current in process work, but wants to make
Operations. sure that the operator isn't also trying to change the
Printer object as part of running the Printer.
Suggested name and operations: Pause-Printer-After-Current-Job, Suggested name and operation: Deactivate-Printer,
(IPP/1.1) Resume-Printer Activate-Printer
Expires: January 17, 2001 15. Need a Device Operation that combines Disable-Device,
Pause-Device-After-Current-Job, and rejects all other Device
Operations, except Job and Printer queries and the companion
operation to resume activity. In other words, this
operation makes the Output Device a read-only object in a
graceful manner.
10. Need a Device Operation to stop the processing the current job Usage: The field service person wants to open up the device
"immediately", no matter what protocol. Its like the Pause button on without disturbing the current in process work, perhaps to
the Output Device. This operation is for emergencies. The stop replace staples, or replace the toner cartridge.
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 a companion
operation to start processing the current any-protocol job without
losing any thing.
Usage: Operator sees something bad about to happen, such as the Suggested name and operation: Deactivate-Device, Activate-
paper is about to jam, or the toner is running out, or the device is Device
overheating or wants to add more paper.
Suggested name and operations: Pause-Device-Now, Resume-Device 16. Need a Printer Operation to recover from 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-initialized. No
companion operation is needed to undo this. We don't want
to go back to the "confused" state :-).
11. Need a Printer Operation to stop the processing of IPP jobs after Usage: The IPP Printer software has gotten confused or
all of the currently accepted jobs have been processed, but any newly isn't responding properly.
accepted jobs go into the 'processing-held' state.
Usage: This allows an operator to reconfigure the Output Device in Suggested name and operation: Restart-Printer
order to let jobs that are held waiting for resources, such as
special media, to get a chance. Then the operator uses another
operation after reconfiguring. He repeats the two operations to
restore the Output Device to its normal media.
Suggested name and operations: Hold-New-Jobs, Release-Held-New-Jobs 17. Need a Device Operation to recover from the Output Device
hardware and software that has gotten confused (gotten into
a state that it doesn't seem to be able to get out of, run
out of heap memory, etc.). This is a condition that
shouldn't happen, but does in real life. This is the same
and has the same options as the Printer MIB reset. No
companion operation is needed to undo this. We don't want
to go back to the "confused" state :-).
12. Need a Device Operation to stop the processing the current any- Usage: The Output Device has gotten confused or need
protocol job at a convenient point, such as after the current copy resetting to some initial conditions.
(or end of job if last or only copy). 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 the output bin that is near full. Suggested name and operation: Reset-Device
The paper path is run out.
Suggested name and operations: Pause-Device-After-Current-Copy, 18. Need a Printer Operation to put the IPP Printer object out
Resume-Device of business with no way in the protocol to bring that
instantiation back to life (but see Startup-Printer which
brings up exactly one new instantiation to life with the
same URL). Any volatile information is saved if possible.
13. Need a Device Operation that always pauses on a device-defined Usage: The Printer is being moved or the building's power
boundary, no matter how many copies, in order to not break up a job. is being shut off.
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 the output bin that is near full, Suggested name and operation: Shutdown-Printer
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, 19. Need a Printer Operation to bring an IPP Printer to life
Resume-Device when there is an already running host.
14. Need a Printer Operation that combines Disable-Printer, Pause- Usage: After the host is started (by means outside the IPP
Printer-After-Current-Job, and rejects all other Job, Printer, and protocol), the operator is able to ask the host to bring up
Device Operations, except Job and Printer queries, System any number of Printer objects (that the host has been
Administrator Set-Printer-Attributes, and the companion operation to configured in some way) each with distinct URLs.
resume activity. In other words, this operation makes the Printer a
read-only object in a graceful manner for end-users and the operator.
Usage: The administrator wants to reconfigure the Printer object Suggested name and operation: Startup-Printer
using the Set-Printer-Attributes operation without disturbing the
Expires: January 17, 2001 20. Need a Device Operation to power off the Output Device after
current in process work, but wants to make sure that the operator writing out any software state. It is assumed that other
isn't also trying to change the Printer object as part of running the operations have more gracefully prepared the Output Device
Printer. for this drastic and immediate. There is no companion
Device Operation to bring the power back on.
Suggested name and operation: Deactivate-Printer, Activate-Printer Usage: The Output Device is going to be moved, the power in
the building is going to be shutoff, the repair man has
arrived and needs to take the Output Device apart.
15. Need a Device Operation that combines Disable-Device, Pause-Device- Suggested name and operation: Power-Off-Device
After-Current-Job, and rejects all other Device Operations, except
Job and Printer queries and the companion operation to resume
activity. In other words, this operation makes the Output Device a
read-only object in a graceful manner.
Usage: The field service person wants to open up the device without 21. Need a Device Operation to startup a powered-off device.
disturbing the current in process work, perhaps to replace staples,
or replace the toner cartridge.
Suggested name and operation: Deactivate-Device, Activate-Device Usage: After a Power-Off-Device, if the device can be
powered back up (possibly by an intervening host that
supports the Device Operation).
16. Need a Printer Operation to recover from the IPP Printer software Suggest name and operation: Power-On-Device
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-
initialized. No companion operation is needed to undo this. We
don't want to go back to the "confused" state :-).
Usage: The IPP Printer software has gotten confused or isn't The tentative list of Printer and the corresponding Device Operations
responding properly. is shown in Table 1:
Suggested name and operation: Restart-Printer Table 1 - List of Printer Operations and corresponding Device
Operations
17. Need a Device Operation to recover from the Output Device hardware Printer Operation Corresponding Device Operation
and software that has gotten confused (gotten into a state that it equivalent
doesn't seem to be able to get out of, run out of heap memory, etc.).
This is a condition that shouldn't happen, but does in real life.
This is the same and has the same options as the Printer MIB reset.
No companion operation is needed to undo this. We don't want to go
back to the "confused" state :-).
Usage: The Output Device has gotten confused or need resetting to Disable-Printer Disable-Device
some initial conditions.
Suggested name and operation: Reset-Device Enable-Printer Enable-Device
18. Need a Printer Operation to put the IPP Printer object out of Pause-Printer (IPP/1.1 - [RFC2911] Pause-Device-Now
business with no way in the protocol to bring that instantiation back - one interpretation)
to life (but see Startup-Printer which brings up exactly one new
instantiation to life with the same URL). Any volatile information
is saved if possible.
Usage: The Printer is being moved or the building's power is being no Pause-Device-After-Current-Copy
shut off.
Suggested name and operation: Shutdown-Printer Pause-Printer-After-Current-Job Pause-Device-After-Current-Job
19. Need a Printer Operation to bring an IPP Printer to life when there Resume-Printer (IPP/1.1 - Resume-Device
is an already running host. [RFC2911])
Usage: After the host is started (by means outside the IPP Hold-New-Jobs no
protocol), the operator is able to ask the host to bring up any
Expires: January 17, 2001 Release-Held-New-Jobs no
number of Printer objects (that the host has been configured in some
way) each with distinct URLs.
Suggested name and operation: Startup-Printer Deactivate-Printer Deactivate-Device
20. Need a Device Operation to power off the Output Device after Activate-Printer Activate-Device
writing out any software state. It is assumed that other operations
have more gracefully prepared the Output Device for this drastic and
immediate. There is no companion Device Operation to bring the power
back on.
Usage: The Output Device is going to be moved, the power in the Purge-Jobs (IPP/1.1 - [RFC2911]) Purge-Device
building is going to be shutoff, the repair man has arrived and needs
to take the Output Device apart.
Suggested name and operation: Power-Off-Device Restart-Printer Reset-Device
21. Need a Device Operation to startup a powered-off device. Shutdown-Printer Power-Off-Device
Usage: After a Power-Off-Device, if the device can be powered back Startup-Printer Power-On-Device
up (possibly by an intervening host that supports the Device
Operation).
Suggest name and operation: Power-On-Device There are no conformance dependencies between Printer Operations and
Device Operations. Either may be supported without supporting the
corresponding operations.
The tentative list of Printer and the corresponding Device Operations is 4 IANA Considerations
shown in Table 1:
Table 1 - List of Printer Operations and corresponding Device Operations This document does not define anything to be registered. When a
document is produced that defines operations that meet the
requirements in this document, those operations will be registered
according to the procedures in [RFC2911] section 6.4.
Printer Operation Corresponding Device Operation 5 Internationalization Considerations
equivalent
(see [ipp-device-ops])
Disable-Printer Disable-Device This document has the same localization considerations as the
[RFC2911].
Enable-Printer Enable-Device 6 Security Considerations
Pause-Printer (IPP/1.1 - Pause-Device-Now This document defines the requirements for operations that are
[ipp-mod] - one intended to be used by an operator or system administrator. These
interpretation) operations, when defined, would affect how the Printer behaves and
establish policy and/or operating behavior that ordinary users
shouldn't be able to perform. Printer implementations that support
such operations should authenticate users and authorized them as
being an operator or a system administrator for the system.
Otherwise, unprivileged users could affect the policy and behavior of
IPP Printers, thereby affecting other users. Similarly clients that
supports such operations should be prepared to provide the necessary
authentication information. See the security provisions in [RFC2911]
for authentication, such as TLS.
no Pause-Device-After-Current-Copy 7 References
Pause-Printer-After-Current- Pause-Device-After-Current-Job [ipp-ntfy] Herriot, R., Hastings, T., Isaacson, S., Martin, J.,
Job deBry, R., Shepherd, M. and R. Bergman, "Internet
Printing Protocol/1.1: IPP Event Notifications and
Subscriptions", Work in Progress.
Resume-Printer (IPP/1.1 - Resume-Device [ipp-ops-set2] Kugler, C., Hastings, T. and H. Lewis, "Internet
[ipp-mod]) Printing Protocol (IPP): Job and Printer
Administrative Operations", Work in Progress.
Hold-New-Jobs no [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner,
"Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2565, April 1999.
Release-Held-New-Jobs no [RFC2566] deBry, R., Hastings, T., Herriot, R. and S. Isaacson,
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
Deactivate-Printer Deactivate-Device [RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
Activate-Printer Activate-Device [RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC
2568, April 1999.
Purge-Jobs (IPP/1.1 - [ipp- Purge-Device [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
mod]) "Mapping between LPD and IPP Protocols", RFC 2569,
April 1999.
Restart-Printer Reset-Device [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
Shutdown-Printer Power-Off-Device [RFC2910] Herriot, R., Butler, S., Moore, P. and R. Tuner,
"Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
Startup-Printer Power-On-Device [RFC2911] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2911, September 2000.
There are no conformance dependencies between Printer Operations and [RFC3196] Hastings, T., Manros, C., Zehler, P., Kuger, C. and H.
Device Operations. Either MAY be supported without supporting the Holst, "Internet Printing Protocol/1.1: Implementer's
corresponding operations. Guide", RFC 3196, November 2001.
Expires: January 17, 2001 Appendix A: Description of base IPP documents
4 IANA Considerations
The operations and attributes in this registration proposal will be The base set of IPP documents includes:
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 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 [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]
Internet Printing Protocol (IPP): IPP Event Notifications and
Subscriptions [ipp-ntfy]
5 Internationalization Considerations 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.
This document has the same localization considerations as the [ipp-mod]. 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.
6 Security Considerations The "Internet Printing Protocol/1.1: Model and Semantics" document
describes a simplified model with abstract objects, their attributes,
and their operations that are independent of encoding and transport.
It introduces a Printer and a Job object. The Job object optionally
supports multiple documents per Job. It also addresses security,
internationalization, and directory issues.
The IPP Model and Semantics document [ipp-mod] discusses high level The "Internet Printing Protocol/1.1: Encoding and Transport" document
security requirements (Client Authentication, Server Authentication and is a formal mapping of the abstract operations and attributes defined
Operation Privacy). Client Authentication is the mechanism by which the in the model document onto HTTP/1.1 [RFC2616]. It defines the
client proves its identity to the server in a secure manner. Server encoding rules for a new Internet MIME media type called
Authentication is the mechanism by which the server proves its identity "application/ipp". This document also defines the rules for
to the client in a secure manner. Operation Privacy is defined as a transporting over HTTP a message body whose Content-Type is
mechanism for protecting operations from eavesdropping. "application/ipp". This document defines the 'ippget' scheme for
identifying IPP printers and jobs.
7 Author's Addresses The "Internet Printing Protocol/1.1: Implementer's Guide" document
gives insight and advice to implementers of IPP clients and IPP
objects. It is intended to help them understand IPP/1.1 and some of
the considerations that may assist them in the design of their client
and/or IPP object implementations. For example, a typical order of
processing requests is given, including error checking. Motivation
for some of the specification decisions is also included.
Carl Kugler The "Mapping between LPD and IPP Protocols" document gives some
IBM advice to implementers of gateways between IPP and LPD (Line Printer
Boulder CO Daemon) implementations.
Phone: (303) 924-5060 The "IPP Event Notifications and Subscriptions" document defines an
FAX: extension to IPP/1.0 [RFC2566, RFC2565] and IPP/1.1 [RFC2911,
e-mail: kugler@us.ibm.com RFC2910]. This extension allows a client to subscribe to printing
related Events and defines the semantics for delivering asynchronous
Tom Hastings Event Notifications to the specified Notification Recipient via a
Xerox Corporation specified Delivery Method (i.e., protocols) defined in (separate)
737 Hawaii St. ESAE 231 Delivery Method documents.
El Segundo, CA 90245
Phone: 310-333-6413 Authors' Addresses
Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com
Harry Lewis Carl Kugler
IBM IBM
Boulder CO Boulder CO
Phone: (303) 924-5337 Phone: (303) 924-5060
FAX: EMail: kugler@us.ibm.com
e-mail: harryl@us.ibm.com
Expires: January 17, 2001 Tom Hastings
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
8 References Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
[ipp-device-ops] Harry Lewis
Kugler, C., Hastings, T., Lewis, H., "Internet Printing Protocol IBM
(IPP): Device Administrative Operations", <draft-ietf-ipp-ops-set3- Boulder CO
00.txt>, work in progress, TBD.
[ipp-iig] Phone: (303) 924-5337
Hastings, T., Manros, C., "Internet Printing Protocol/1.1: draft- EMail: harryl@us.ibm.com
ietf-ipp-implementers-guide-v11-01.txt, work in progress, May 9,
2000.
[ipp-mod] IPP Web Page: http://www.pwg.org/ipp/
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, IPP Mailing List: ipp@pwg.org
"Internet Printing Protocol/1.0: Model and Semantics", <draft-ietf-
ipp-model-v11-07.txt>, May 22, 2000.
[ipp-ops-set2] To subscribe to the ipp mailing list, send the following email:
Kugler, C., , Hastings, T., Lewis, H, "Internet Printing Protocol
(IPP): Job and Printer Administrative Operations", <draft-ietf-ipp-
ops-set2-01.txt>, work in progress, July 19, 2000.
[ipp-pro] 1) send it to majordomo@pwg.org
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 2) leave the subject line blank
Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 3) put the following two lines in the message body:
06.txt, May 30, 2000. subscribe ipp
end
[RFC2566] Implementers of this specification document are encouraged to join
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, the IPP Mailing List in order to participate in any discussions of
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, clarification issues and review of registration proposals for
April 1999. additional attributes and values. In order to reduce spam the
mailing list rejects mail from non-subscribers, so you must subscribe
to the mailing list in order to send a question or comment to the
mailing list.
9 Appendix A: Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1998,1999). All Rights Reserved Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it
assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are included kind, provided that the above copyright notice and this paragraph are
on all such copies and derivative works. However, this document itself included on all such copies and derivative works. However, this
may not be modified in any way, such as by removing the copyright notice document itself may not be modified in any way, such as by removing
or references to the Internet Society or other Internet organizations, the copyright notice or references to the Internet Society or other
except as needed for the purpose of developing Internet standards in Internet organizations, except as needed for the purpose of
which case the procedures for copyrights defined in the Internet developing Internet standards in which case the procedures for
Standards process must be followed, or as required to translate it into copyrights defined in the Internet Standards process must be
languages other than English. followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "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 17, 2001 Acknowledgement
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 17, 2001 Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 149 change blocks. 
422 lines changed or deleted 456 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/