Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: IPP

RFC 3196

Internet Printing Protocol/1.1: Implementor's Guide

Pages: 96
Obsoletes:  2639
Part 5 of 5 – Pages 79 to 96
First   Prev   None

Top   ToC   RFC3196 - Page 79   prevText
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
   Directory Schema.

   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?
Top   ToC   RFC3196 - Page 80
   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.
Top   ToC   RFC3196 - Page 81
7  Encoding and Transport

   This section discusses various aspects of IPP/1.1 Encoding and
   Transport [RFC2910].

   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
   non-blocking I/O.

   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.
Top   ToC   RFC3196 - Page 82
     - 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 header.
     - 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.
Top   ToC   RFC3196 - Page 83
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
     Control   must

   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
                                                Content-Length is

   Upgrade     not     not     not    not

   Via         not     not     not    not
Top   ToC   RFC3196 - Page 84
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-
                                    Authenticate" header.

   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
Top   ToC   RFC3196 - Page 85
   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
Top   ToC   RFC3196 - Page 86
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
                     if             redirection.

   Proxy-                  must   per RFC 2616
     e             not

   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.
Top   ToC   RFC3196 - Page 87
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 codings.

   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
                                                    if Transfer-
                                                    Encoding is

   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
Top   ToC   RFC3196 - Page 88
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
   number 1.0.

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:

      TE: identity

   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
Top   ToC   RFC3196 - Page 89
   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

8  References

   [CGI]             CGI/1.1 (

   [IANA-CS]         IANA Registry of Coded 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.
Top   ToC   RFC3196 - Page 90
   [RFC2566]         Herriot, R., Butler, S., Moore, P. and R. Turner,
                     "Internet Printing Protocol/1.0: Encoding and
                     Transport", RFC 2565, April 1999.

   [RFC2567]         Wright, D., "Design Goals for an Internet Printing
                     Protocol", RFC 2567, April 1999.

   [RFC2568]         Zilles, S., "Rationale for the Structure and Model
                     and Protocol for the Internet Printing Protocol",
                     RFC 2568, April 1999.

   [RFC2569]         Herriot, R., Hastings, T., Jacobs, N. and J.
                     Martin, "Mapping between LPD and IPP Protocols",
                     RFC 2569, April 1999.

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

   [RFC2910]         Herriot, R., Butler, S., Moore, P. and R. Turner,
                     "Internet Printing Protocol/1.0: Encoding and
                     Transport", RFC 2910, September, 2000.

   [RFC2911]         DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
                     and P. Powell, "Internet Printing Protocol/1.0:
                     Model and Semantics", RFC 2911, September, 2000.

   [Servlet]         Servlet Specification Version 2.1

   [svrloc-printer]  St. Pierre, P., Isaacson, S., McDonald, I.,
                     "Definition of the Printer Abstract Service Type
                     templates/printer.2.0.en (IANA Registered, May 27,

   [SSL]             Netscape, The SSL Protocol, Version 3, (Text
                     version 3.02), November 1996.
Top   ToC   RFC3196 - Page 91
9.  Authors' Addresses

   Thomas N. Hastings
   Xerox Corporation
   701 Aviation Blvd.
   El Segundo, CA 90245


   Carl-Uno Manros
   Independent Consultant
   1601 N. Sepulveda Blvd. #505
   Manhattan Beach, CA 90266


   Carl Kugler
   Mail Stop 003G
   IBM Printing Systems Co
   6300 Diagonal Hwy
   Boulder CO 80301


   Henrik Holst
   i-data Printing Systems
   Vadstrupvej 35-43
   2880 Bagsvaerd, Denmark


   Peter Zehler
   Xerox Corporation
   800 Philips Road
   Webster, NY 14580

Top   ToC   RFC3196 - Page 92
   IPP Web Page:
   IPP Mailing List:

   To subscribe to the ipp mailing list, send the following email:

      1) send it to
      2) leave the subject line blank
      3) put the following two lines in the message body:
         subscribe ipp

   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
   mailing list.

   Other Participants:

   Chuck Adams - Tektronix            Shivaun Albright - HP

   Stefan Andersson - Axis            Jeff Barnett - IBM

   Ron Bergman - Hitachi Koki         Dennis Carney - IBM
   Imaging Systems

   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
Top   ToC   RFC3196 - Page 93
   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
Top   ToC   RFC3196 - Page 94
   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
                                      Information Systems

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
Top   ToC   RFC3196 - Page 95
   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
   are addressed.

   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
   Daemon) implementations.
Top   ToC   RFC3196 - Page 96
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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.