Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations
draft-ietf-ipp-ops-admin-req-00
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3239.
|
|
|---|---|---|---|
| Authors | Thomas N. Hastings , Carl Kugler , Harry Lewis | ||
| Last updated | 2013-03-02 (Latest revision 2000-08-17) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 3239 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ipp-ops-admin-req-00
Internet Printing Protocol WG Carl Kugler
INTERNET-DRAFT H. Lewis
<draft-ietf-ipp-ops-admin-req-00.txt> IBM Corporation
Category: Informational T. Hastings (editor)
Xerox Corporation
August 15, 2000
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
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 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
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]).
Kugler, Hastings, Lewis [Page 1]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
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]
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
requests is given, including error checking. Motivation for some of the
specification decisions is also included.
Kugler, Hastings, Lewis [Page 2]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
Kugler, Hastings, Lewis [Page 3]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
Table of Contents
1 Introduction........................................................5
2 Terminology.........................................................5
3 Requirements and Use Cases..........................................6
4 IANA Considerations................................................10
5 Internationalization Considerations................................10
6 Security Considerations............................................10
7 Author's Addresses.................................................10
8 References.........................................................11
9 Appendix A: Full Copyright Statement...............................11
List of Tables
Table 1 - List of Printer Operations and corresponding Device Operations
..................................................................9
Kugler, Hastings, Lewis [Page 4]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
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 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
This section defines terminology used throughout this document and the
corresponding documents that define the Administrative operations on
Job, Printer, and Device objects.
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.
In addition, the following capitalized terms are 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.
Output Device Fan-Out - a configuration in which an IPP Printer
controls more that one output-device.
Printer fan-out - a configuration in which an IPP Printer object
controls more than one Subordinate IPP Printer object.
Printer 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.
Kugler, Hastings, Lewis [Page 5]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
3 Requirements and Use Cases
The Administrative operations for Job and Printer objects will be
defined in one document [ipp-admin-ops]. The Administrative operations
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
affecting the Output Device, so its clear what the intent of each is
and implementers can implement one or the other or both.
2.Support fan-out of Printer objects.
3.Support fan-out of Output Devices.
4.Support fan-in of Printer objects, as long as it doesn't make the
semantics more complicated when not supporting fan-in.
5.Support fan-in of output objects, as long as it doesn't make the
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) 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
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.
Usage: Operator is preparing to take the IPP Printer out of service
or to change the configuration of the IPP Printer.
Suggested name and operations: Disable-Printer and Enable-Printer
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 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 to the Output Device),
but continue to accept new IPP jobs. Need a companion operation to
start processing/sending IPP jobs again.
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.
Suggested name and operations: Pause-Printer-After-Current-Job,
(IPP/1.1) Resume-Printer
Kugler, Hastings, Lewis [Page 6]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
10. Need a Device Operation to stop the processing the current job
"immediately", no matter what protocol. Its like the 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.
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.
Suggested name and operations: Pause-Device-Now, Resume-Device
11. Need a Printer Operation to stop the processing of IPP jobs after
all of the currently accepted jobs have been processed, but any newly
accepted jobs go into the 'processing-held' state.
Usage: This allows an operator to reconfigure the Output Device in
order to let jobs that are held waiting for resources, such as
special media, to get a chance. Then the operator uses another
operation after reconfiguring. He repeats the two operations to
restore the Output Device to its normal media.
Suggested name and operations: Hold-New-Jobs, Release-Held-New-Jobs
12. Need a Device Operation to stop the processing the current any-
protocol job at a convenient point, such as after the current copy
(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.
The paper path is run out.
Suggested name and operations: Pause-Device-After-Current-Copy,
Resume-Device
13. Need a Device Operation that always pauses on a device-defined
boundary, no matter how many copies, in order to not break up a job.
Need a companion operation to start processing the current any-
protocol job or next job without losing any thing.
Usage: The operator wants to empty the output bin that is near full,
but he doesn't want to break up a job in case it has multiple copies.
The paper path is run out.
Suggested name and operations: Pause-Device-After-Current-Job,
Resume-Device
14. Need a Printer Operation that combines Disable-Printer, Pause-
Printer-After-Current-Job, and rejects all other Job, Printer, and
Device Operations, except Job and Printer queries, System
Administrator Set-Printer-Attributes, and the companion operation to
resume activity. In other words, this operation makes the Printer a
read-only object in a graceful manner for end-users and the operator.
Usage: The administrator wants to reconfigure the Printer object
using the Set-Printer-Attributes operation without disturbing the
Kugler, Hastings, Lewis [Page 7]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
current in process work, but wants to make sure that the operator
isn't also trying to change the Printer object as part of running the
Printer.
Suggested name and operation: Deactivate-Printer, Activate-Printer
15. Need a Device Operation that combines Disable-Device, Pause-Device-
After-Current-Job, and rejects all other Device Operations, except
Job 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
disturbing the current in process work, perhaps to replace staples,
or replace the toner cartridge.
Suggested name and operation: Deactivate-Device, Activate-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 :-).
Usage: The IPP Printer software has gotten confused or isn't
responding properly.
Suggested name and operation: Restart-Printer
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 :-).
Usage: The Output Device has gotten confused or need resetting to
some initial conditions.
Suggested name and operation: Reset-Device
18. Need a Printer Operation to put the IPP Printer object out 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.
Usage: The Printer is being moved or the building's power is being
shut off.
Suggested name and operation: Shutdown-Printer
19. Need a Printer Operation to bring an IPP Printer to life when there
is an already running host.
Usage: After the host is started (by means outside the IPP
protocol), the operator is able to ask the host to bring up any
Kugler, Hastings, Lewis [Page 8]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
number of Printer objects (that the host has been configured in some
way) each with distinct URLs.
Suggested name and operation: Startup-Printer
20. Need a Device Operation to power off the Output Device after
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
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
21. Need a Device Operation to startup a powered-off 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).
Suggest name and operation: Power-On-Device
The tentative list of Printer and the corresponding Device Operations is
shown in Table 1:
Table 1 - List of Printer Operations and corresponding Device Operations
Printer Operation Corresponding Device Operation
equivalent
(see [ipp-device-ops])
Disable-Printer Disable-Device
Enable-Printer Enable-Device
Pause-Printer (IPP/1.1 - Pause-Device-Now
[ipp-mod] - one
interpretation)
no Pause-Device-After-Current-Copy
Pause-Printer-After-Current- Pause-Device-After-Current-Job
Job
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 and
Device Operations. Either MAY be supported without supporting the
corresponding operations.
Kugler, Hastings, Lewis [Page 9]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
4 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
5 Internationalization Considerations
This document has the same localization considerations as the [ipp-mod].
6 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.
7 Author's Addresses
Carl Kugler
IBM
Boulder CO
Phone: (303) 924-5060
FAX:
e-mail: kugler@us.ibm.com
Tom Hastings
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com
Harry Lewis
IBM
Boulder CO
Phone: (303) 924-5337
FAX:
e-mail: harryl@us.ibm.com
Kugler, Hastings, Lewis [Page 10]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
8 References
[ipp-device-ops]
Kugler, C., Hastings, T., Lewis, H., "Internet Printing Protocol
(IPP): Device Administrative Operations", <draft-ietf-ipp-ops-set3-
00.txt>, work in progress, TBD.
[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-ops-set2]
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]
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.
9 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
Kugler, Hastings, Lewis [Page 11]
Expires: January 17, 2001
INTERNET-DRAFT IPP: Job and Printer Admin. Operations July 17, 2000
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.
Kugler, Hastings, Lewis [Page 12]
Expires: January 17, 2001