4.5 Empty Jobs
The IPP object model does not prohibit a job that contains no
documents. Such a job may be created in a number of ways including a
'create-job' followed by an 'add-document' that contains no data and
has the 'last-document' flag set.
An empty job is processed just as any other job. The operation that
"closes" an empty job is not rejected because the job is empty. If
no other conditions exist, other than the job is empty, the response
to the operation will indicate success. After the job is scheduled
and processed, the job state SHALL be 'completed'.
There will be some variation in the value(s) of the "job-state-
reasons" attribute. It is required that if no conditions, other than
the job being empty, exist the "job-state-reasons" SHALL include the
'completed-successfully'. If other conditions existed, the
'completed-with-warnings' or 'completed-with-errors' values may be
5 Directory Considerations
5.1 General Directory Schema Considerations
The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object
attributes for directory schemas. See [RFC2911] APPENDIX E: Generic
The SLP printer template is defined in the "Definition of the Printer
Abstract Service Type v2.0" document [svrloc-printer]. The LDAP
printer template is defined in the "Internet Printing Protocol (IPP):
LDAP Schema for Printer Services" document [ldap-printer]. Both
documents systematically add "printer-" to any attribute that doesn't
already start with "printer-" in order to keep the printer directory
attributes distinct from other directory attributes. Also, instead
of using "printer-uri-supported", "uri-authentication-supported", and
"uri-security-supported", they use a "printer-xri-supported"
attribute with special syntax to contain all of the same information
in a single attribute.
5.2 IPP Printer with a DNS name
If the IPP printer has a DNS name should there be at least two values
for the printer-uri-supported attribute. One URL with the fully
qualified DNS name the other with the IP address in the URL?
The printer may contain one or the other or both. It's up to the
administrator to configure this attribute.
6 Security Considerations
The security considerations given in [RFC2911] Section 8 "Security
Considerations" all apply to this document. In addition, the
following sub-sections describes security consideration that have
arisen as a result of implementation testing.
6.1 Querying jobs with IPP that were submitted using other job
submission protocols (Issue 1.32)
The following clarification was added to [RFC2911] section 8.5:
8.5 Queries on jobs submitted using non-IPP protocols If the
device that an IPP Printer is representing is able to accept jobs
using other job submission protocols in addition to IPP, it is
RECOMMEND that such an implementation at least allow such
"foreign" jobs to be queried using Get-Jobs returning "job-id" and
"job-uri" as 'unknown'. Such an implementation NEED NOT support
all of the same IPP job attributes as for IPP jobs. The IPP
object returns the 'unknown' out-of-band value for any requested
attribute of a foreign job that is supported for IPP jobs, but not
for foreign jobs.
It is further RECOMMENDED, that the IPP Printer generate "job-id"
and "job-uri" values for such "foreign jobs", if possible, so that
they may be targets of other IPP operations, such as Get-Job-
Attributes and Cancel-Job. Such an implementation also needs to
deal with the problem of authentication of such foreign jobs. One
approach would be to treat all such foreign jobs as belonging to
users other than the user of the IPP client. Another approach
would be for the foreign job to belong to 'anonymous'. Only if
the IPP client has been authenticated as an operator or
administrator of the IPP Printer object, could the foreign jobs be
queried by an IPP request. Alternatively, if the security policy
were to allow users to query other users' jobs, then the foreign
jobs would also be visible to an end-user IPP client using Get-
Jobs and Get-Job- Attributes.
Thus IPP MAY be implemented as a "universal" protocol that
provides access to jobs submitted with any job submission
protocol. As IPP becomes widely implemented, providing a more
universal access makes sense.
7 Encoding and Transport
This section discusses various aspects of IPP/1.1 Encoding and
A server is not required to send a response until after it has
received the client's entire request. Hence, a client must not
expect a response until after it has sent the entire request.
However, we recommend that the server return a response as soon as
possible if an error is detected while the client is still sending
the data, rather than waiting until all of the data is received.
Therefore, we also recommend that a client listen for an error
response that an IPP server MAY send before it receives all the data.
In this case a client, if chunking the data, can send a premature
zero-length chunk to end the request before sending all the data (and
so the client can keep the connection open for other requests, rather
than closing it). If the request is blocked for some reason, a
client MAY determine the reason by opening another connection to
query the server using Get-Printer-Attributes.
IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793]
to throttle clients when Printers are busy. Therefore, it is
perfectly normal for an IPP client transmitting a Job to be blocked
for a really long time. Accordingly, socket timeouts must be
avoided. Some socket implementations have a timeout option, which
specifies how long a write operation on a socket can be blocked
before it times out and the blocking ends. A client should set this
option for infinite timeout when transmitting Job submissions.
Some IPP client applications might be able to perform other useful
work while a Job transmission is blocked. For example, the client
may have other jobs that it could transmit to other Printers
simultaneously. A client may have a GUI, which must remain
responsive to the user while the Job transmission is blocked. These
clients should be designed to spawn a thread to handle the Job
transmission at its own pace, leaving the main application free to do
other work. Alternatively, single-threaded applications could use
Some Printer conditions, such as jam or lack of paper, could cause a
client to be blocked indefinitely. Clients may open additional
connections to the Printer to Get-Printer-Attributes, determine the
state of the device, alert a user if the printer is stopped, and let
a user decide whether to abort the job transmission or not.
In the following sections, there are tables of all HTTP headers,
which describe their use in an IPP client or server. The following
is an explanation of each column in these tables.
- the "header" column contains the name of a header
- the "request/client" column indicates whether a client sends the
- the "request/ server" column indicates whether a server supports
the header when received.
- the "response/ server" column indicates whether a server sends
- the "response /client" column indicates whether a client
supports the header when received.
- the "values and conditions" column specifies the allowed header
values and the conditions for the header to be present in a
The table for "request headers" does not have columns for responses,
and the table for "response headers" does not have columns for
The following is an explanation of the values in the "request/client"
and "response/ server" columns.
- must: the client or server MUST send the header,
- must-if: the client or server MUST send the header when the
condition described in the "values and conditions" column is
- may: the client or server MAY send the header
- not: the client or server SHOULD NOT send the header. It is not
relevant to an IPP implementation.
The following is an explanation of the values in the
"response/client" and "request/ server" columns.
- must: the client or server MUST support the header,
- may: the client or server MAY support the header
- not: the client or server SHOULD NOT support the header. It is
not relevant to an IPP implementation.
7.1 General Headers
The following is a table for the general headers.
General- Request Response Values and Conditions
Client Server Server Client
Cache- not must not "no-cache" only
Connection must- must must- must "close" only. Both
if if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
for the last operation
in such a sequence.
Date may may must may per RFC 1123 [RFC1123]
from RFC 2616
Pragma must not must not "no-cache" only
Transfer- must- must must- must "chunked" only. Header
Encoding if if MUST be present if
Upgrade not not not not
Via not not not not
7.2 Request Headers
The following is a table for the request headers.
Request- Client Server Request Values and Conditions
Accept may must "application/ipp" only. This
value is the default if the
client omits it
Accept- not not Charset information is within the
Charset application/ipp entity
Accept- may must empty and per RFC 2616 [RFC2616]
Encoding and IANA registry for content-
Accept- not not language information is within the
Language application/ipp entity
Authorization must- must per RFC 2616. A client MUST send
if this header when it receives a
401 "Unauthorized" response and
does not receive a "Proxy-
From not not per RFC 2616. Because RFC
recommends sending this header
only with the user's approval,
it is not very useful
Host must must per RFC 2616
If-Match not not
If-Modified- not not
If-None-Match not not
If-Range not not
If- not not
Request- Client Server Request Values and Conditions
Max-Forwards not not
Proxy- must- not per RFC 2616. A client MUST send
Authorizati if this header when it receives a
on 401 "Unauthorized" response and
a "Proxy-Authenticate" header.
Range not not
Referrer not not
User-Agent not not
7.3 Response Headers
The following is a table for the request headers.
Response- Server Client Response Values and Conditions
Accept-Ranges not not
Age not not
Location must- may per RFC 2616. When URI needs
Proxy- must per RFC 2616
Public may may per RFC 2616
Retry-After may may per RFC 2616
Server not not
Vary not not
Warning may may per RFC 2616
WWW- must- must per RFC 2616. When a server needs
Authenticate if to authenticate a client.
7.4 Entity Headers
The following is a table for the entity headers.
Entity-Header Request Response Values and
Client Server Server Client
Allow not not not not
Content-Base not not not not
Content- may must must must per RFC 2616 and
Encoding IANA registry for
Content- not not not not Application/ipp
Language handles language
Content- must- must must- must the length of the
Length if if message-body per
RFC 2616. Header
MUST be present
Content- not not not not
Content-MD5 may may may may per RFC 2616
Content-Range not not not not
Content-Type must must must must "application/ipp"
ETag not not not not
Expires not not not not
Last-Modified not not not not
7.5 Optional support for HTTP/1.0
IPP implementations consist of an HTTP layer and an IPP layer. In
the following discussion, the term "client" refers to the HTTP client
layer and the term "server" refers to the HTTP server layer. The
Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST
be supported by all clients and all servers. However, a client
and/or a server implementation may choose to also support HTTP 1.0.
This option means that a server may choose to communicate with a
(non-conforming) client that only supports HTTP 1.0. In such cases
the server should not use any HTTP 1.1 specific parameters or
features and should respond using HTTP version number 1.0.
This option also means that a client may choose to communicate with a
(non-conforming) server that only supports HTTP 1.0. In such cases,
if the server responds with an HTTP 'unsupported version number' to
an HTTP 1.1 request, the client should retry using HTTP version
7.6 HTTP/1.1 Chunking
7.6.1 Disabling IPP Server Response Chunking
Clients MUST anticipate that the HTTP/1.1 server may chunk responses
and MUST accept them in responses. However, a (non-conforming) HTTP
client that is unable to accept chunked responses may attempt to
request an HTTP 1.1 server not to use chunking in its response to an
operation by using the following HTTP header:
This mechanism should not be used by a server to disable a client
from chunking a request, since chunking of document data is an
important feature for clients to send long documents.
7.6.2 Warning About the Support of Chunked Requests
This section describes some problems with the use of chunked requests
and HTTP/1.1 servers.
The HTTP/1.1 standard [RFC2616] requires that conforming servers
support chunked requests for any method. However, in spite of this
requirement, some HTTP/1.1 implementations support chunked responses
in the GET method, but do not support chunked POST method requests.
Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
servlets [Servlet] require that the client supply a Content-Length.
These implementations might reject a chunked POST method and return a
411 status code (Length Required), might attempt to buffer the
request and run out of room returning a 413 status code (Request
Entity Too Large), or might successfully accept the chunked request.
Because of this lack of conformance of HTTP servers to the HTTP/1.1
standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP
Printer object implementation support chunked requests and that
conforming clients accept chunked responses. Therefore, IPP object
implementers are warned to seek HTTP server implementations that
support chunked POST requests in order to conform to the IPP standard
and/or use implementation techniques that support chunked POST
[CGI] CGI/1.1 (http://www.w3.org/CGI/).
[IANA-CS] IANA Registry of Coded Character Sets:
http://www.iana.org/assignments/character-sets[ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald,
"Internet Printing Protocol (IPP): LDAP Schema for
Printer Services", Work in Progress.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", RFC 1123, October, 1989.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119 , March 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
and P. Powell, "Internet Printing Protocol/1.0:
Model and Semantics", RFC 2566, April 1999.
9. Authors' Addresses
Thomas N. Hastings
701 Aviation Blvd.
El Segundo, CA 90245
1601 N. Sepulveda Blvd. #505
Manhattan Beach, CA 90266
Mail Stop 003G
IBM Printing Systems Co
6300 Diagonal Hwy
Boulder CO 80301
i-data Printing Systems
2880 Bagsvaerd, Denmark
800 Philips Road
Webster, NY 14580
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: firstname.lastname@example.org
To subscribe to the ipp mailing list, send the following email:
1) send it to email@example.com
2) leave the subject line blank
3) put the following two lines in the message body:
Implementers of this specification document are encouraged to join
the IPP Mailing List in order to participate in any discussions of
clarification issues and review of registration proposals for
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
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Dennis Carney - IBM
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Toshiba Lloyd Young - Lexmark
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang- Canon Information Frank Zhao - Panasonic
Steve Zilles - Adobe Rob Zirnstein - Canon
10. Description of the Base IPP Documents
In addition to this document, the base set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
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 [RFC2566, RFC2565]. A few OPTIONAL operator
operations have been added to IPP/1.1 [RFC2911, RFC2910].
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 IPP working group's major decisions.
The "Internet Printing Protocol/1.1: Model and Semantics" document
describes a simplified model with abstract objects, their attributes,
and their operations. The model introduces a Printer and a Job. The
Job supports multiple documents per Job. The model document also
addresses how 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 also defines the
encoding rules for a new Internet MIME media type called
"application/ipp". This document also defines the rules for
transporting a message body over HTTP whose Content-Type is
"application/ipp". This document defines the 'ipp' scheme for
identifying IPP printers and jobs.
The "Mapping between LPD and IPP Protocols" document gives some
advice to implementers of gateways between IPP and LPD (Line Printer
11 Full Copyright Statement
Copyright (C) The Internet Society (2001). 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
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.
Funding for the RFC Editor function is currently provided by the