tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2639


Internet Printing Protocol/1.0: Implementer's Guide

Part 3 of 3, p. 50 to 64
Prev RFC Part


prevText      Top      Up      ToC       Page 50 
2.7 The "queued-job-count" Printer Description attribute

2.7.1 Why is "queued-job-count" RECOMMENDED?

   The reason that "queued-job-count" is RECOMMENDED, is that some
   clients look at that attribute alone when summarizing the status of a
   list of printers, instead of doing a Get-Jobs to determine the number
   of jobs in the queue.  Implementations that fail to support the
   "queued-job-count" will cause that client to display 0 jobs when
   there are actually queued jobs.

   We would have made it a REQUIRED Printer attribute, but some
   implementations had already been completed before the issue was
   raised, so making it a SHOULD was a compromise.

2.7.2 Is "queued-job-count" a good measure of how busy a printer is?

   The "queued-job-count" is not a good measure of how busy the printer
   is when there are held jobs.  A future registration could be to add a
   "held-job-count" (or an "active-job-count") Printer Description
   attribute if experience shows that such an attribute (combination) is
   needed to quickly indicate how busy a printer really is.

2.8 Sending empty attribute groups

   The [RFC2566] and [RFC2565] specifications RECOMMEND that a sender
   not send an empty attribute group in a request or a response.
   However, they REQUIRE a receiver to accept an empty attribute group
   as equivalent to the omission of that group.  So a client SHOULD omit
   the Job Template Attributes group entirely in a create operation that
   is not supplying any Job Template attributes.  Similarly, an IPP
   object SHOULD omit an empty Unsupported Attributes group if there are
   no unsupported attributes to be returned in a response.

Top      Up      ToC       Page 51 
   The [RFC2565] specification REQUIRES a receiver to be able to receive
   either an empty attribute group or an omitted attribute group and
   treat them equivalently.  The term "receiver" means an IPP object for
   a request and a client for a response.  The term "sender' means a
   client for a request and an IPP object for a response.

   There is an exception to the rule for Get-Jobs when there are no
   attributes to be returned.  [RFC2565] contains the following

      The syntax allows an xxx-attributes-tag to be present when the
      xxx-attribute-sequence that follows is empty. The syntax is
      defined this way to allow for the response of Get-Jobs where no
      attributes are returned for some job-objects.  Although it is
      RECOMMENDED that the sender not send an xxx-attributes-tag if
      there are no attributes (except in the Get-Jobs response just
      mentioned), the receiver MUST be able to decode such syntax.

2.9 Returning unsupported attributes in Get-Xxxx responses

   In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
   responses, the client cannot depend on getting unsupported attributes
   returned in the Unsupported Attributes group that the client
   requested, but are not supported by the IPP object.  However, such
   unsupported requested attributes will not be returned in the Job
   Attributes or Printer Attributes group (since they are unsupported).
   Furthermore, the IPP object is REQUIRED to return the 'successful-
   ok-ignored-or-substituted-attributes' status code, so that the client
   knows that not all that was requested has been returned.

2.10 Returning job-state in Print-Job response

   An IPP client submits a small job via Print-Job.  By the time the IPP
   printer/print server is putting together a response to the operation,
   the job has finished printing and been removed as an object from the
   print system.  What should the job-state be in the response?

   The Model suggests that the Printer return a response before it even
   accepts the document content.  The Job Object Attributes are returned
   only if the IPP object returns one of the success status codes. Then
   the job-state would always be "pending" or "pending-held".

   This issue comes up for the implementation of an IPP Printer object
   as a server that forwards jobs to devices that do not provide job
   status back to the server.  If the server is reasonably certain that
   the job completed successfully, then it should return the job-state
   as 'completed'.  Also the server can keep the job in its "job
   history" long after the job is no longer in the device.  Then a user

Top      Up      ToC       Page 52 
   could query the server and see that the job was in the 'completed'
   state and completed as specified by the job's "time-at-completed"
   time which would be the same as the server submitted the job to the

   An alternative is for the server to respond to the client before or
   while sending the job to the device, instead of waiting until the
   server has finished sending the job to the device.  In this case, the
   server can return the job's state as 'pending' with the 'job-
   outgoing' value in the job's "job-state-reasons" attribute.

   If the server doesn't know for sure whether the job completed
   successfully (or at all), it could return the (out-of-band) 'unknown'

   On the other hand, if the server is able to query the device and/or
   setup some sort of event notification that the device initiates when
   the job makes state transitions, then the server can return the
   current job state in the Print-Job response and in subsequent queries
   because the server knows what the job state is in the device (or can
   query the device).

   All of these alternatives depend on implementation of the server and
   the device.

2.11 Flow controlling the data portion of a Print-Job request

   A paused printer (or one that is stopped due to paper out or jam or
   spool space full or buffer space full, may flow control the data of a
   Print-Job operation (at the TCP/IP layer), so that the client is not
   able to send all the document data.  Consequently, the Printer will
   not return a response until the condition is changed.

   The Printer should not return a Print-Job response with an error code
   in any of these conditions, since either the printer will be resumed
   and/or the condition will be freed either by human intervention or as
   jobs print.

   In writing test scripts to test IPP Printers, the script must also be
   written not to expect a response, if the printer has been paused,
   until the printer is resumed, in order to work with all possible

2.12 Multi-valued attributes

   What is the attribute syntax for a multi-valued attribute?  Since
   some attributes support values in more than one data type, such as
   "media", "job-hold-until", and "job-sheets", IPP semantics associate

Top      Up      ToC       Page 53 
   the attribute syntax with each value, not with the attribute as a
   whole.  The protocol associates the attribute syntax tag with each
   value.  Don't be fooled, just because the attribute syntax tag comes
   before the attribute keyword.  All attribute values after the first
   have a zero length attribute keyword as the indication of a
   subsequent value of the same attribute.

2.13 Querying jobs with IPP that were submitted using other job
     submission protocols

   The following clarification was added to [RFC2566] 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
      is 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

Top      Up      ToC       Page 54 
2.14 The 'none' value for empty sets

   [RFC2566] states that the 'none' value should be used as the value of
   a 1SetOf when the set is empty. In most cases, sets that are
   potentially empty contain keywords so the keyword 'none' is used, but
   for the 3 finishings attributes, the values are enums and thus the
   empty set is represented by the enum 3.  Currently there are no other
   attributes with 1SetOf values which can be empty and can contain
   values that are not keywords.  This exception requires special code
   and is a potential place for bugs.  It would have been better if we
   had chosen an out-of-band value, either "no-value" or some new value,
   such as 'none'.  Since we didn't, implementations have to deal with
   the different representations of 'none', depending on the attribute

2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?

   In [RFC2566] section 'Get-Jobs Request', if the attribute '
   my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
   attribute be there to, and if it's not present what should the IPP
   printer do?

   [RFC2566] Section 8.3 describes the various cases of "requesting-
   user-name" being present or not for any operation.  If the client
   does not supply a value for "requesting-user-name", the printer MUST
   assume that the client is supplying some anonymous name, such as

2.16 The "multiple-document-handling" Job Template attribute and support
     of multiple document jobs

   ISSUE:  IPP/1.0 is silent on which of the four effects an
   implementation would perform if it supports Create-Job, but does not
   support "multiple-document-handling".

   A fix to IPP/1.0 would be to require implementing all four values of
   "multiple-document-handling" if Create-Job is supported at all.  Or
   at least 'single-document-new-sheet' and 'separate-documents-
   uncollated-copies'.  In any case, an implementation that supports
   Create-Job SHOULD also support "multiple-document-handling".  Support
   for all four values is RECOMMENDED, but at least the 'single-
   document-new-sheet' and 'separate-documents-uncollated-copies'
   values, along with the "multiple-document-handling-default"
   indicating the default behavior and "multiple-document-handling-
   supported" values.  If an implementation spools the data, it should
   also support the 'separate-documents-collated-copies' value as well.

Top      Up      ToC       Page 55 
3  Encoding and Transport

   This section discusses various aspects of IPP/1.0 Encoding and
   Transport [RFC2565].

   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.

   In the following sections, there are a 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 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

Top      Up      ToC       Page 56 
      - 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.

3.1 General Headers

   The following is a table for the general headers.

   General-     Request         Response       Values and Conditions

                Client  Server Server Client

   Cache-       must    not    must   not     .no-cache. only

   Connection   must-if must   must-  must    .close. only. Both
                                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 2068

   Pragma       must    not    must   not     .no-cache. only

   Transfer-    must-if must   must-  must    .chunked. only .
   Encoding                     if             Header MUST be present
                                                if Content-Length is

Top      Up      ToC       Page 57 
   Upgrade      not     not    not    not

   Via          not     not    not    not

3.2 Request  Headers

   The following is a table for the request headers.

   Request-Header   Client   Server  Request Values and Conditions

   Accept           may      must    .application/ipp. only.  This
                                      value is the default if the

   Request-Header   Client   Server  Request Values and Conditions

                                      client omits it

   Accept-Charset   not      not      Charset information is within
                                      the application/ipp entity

   Accept-Encoding  may      must    empty and per RFC 2068 [RFC2068]
                                      and IANA registry for content-

   Accept-Language  not      not     language information is within
                                      the application/ipp entity

   Authorization    must-if  must    per RFC 2068. A client MUST send
                                      this header when it receives a
                                      401 .Unauthorized. response and
                                      does not receive a  .Proxy-
                                      Authenticate. header.

   From             not      not     per RFC 2068. Because RFC
                                      recommends sending this header
                                      only with the user.s approval, it
                                      is not very useful

   Host             must     must    per RFC 2068

   If-Match         not      not

   If-Modified-     not      not

   If-None-Match    not      not

Top      Up      ToC       Page 58 
   If-Range         not      not

   If-Unmodified-   not      not

   Max-Forwards     not      not

   Proxy-           must-if  not     per RFC 2068. A client MUST send
   Authorization                      this header when it receives a
                                      401 .Unauthorized. response and a
                                      .Proxy-Authenticate. header.

   Range            not      not

   Referer          not      not

   User-Agent       not      not

3.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-if may     per RFC 2068. When URI needs

   Proxy-         not     must    per RFC 2068

   Public         may     may     per RFC 2068

   Retry-After    may     may     per RFC 2068

   Server         not     not

   Vary           not     not

   Warning        may     may     per RFC 2068

Top      Up      ToC       Page 59 
   WWW-           must-if must    per RFC 2068. When a server needs to
   Authenticate                    authenticate a client.

3.4 Entity  Headers

   The following is a table for the entity headers.

   Entity-Header  Request         Response        Values and Conditions

                  Client  Server Server  Client

   Allow          not     not    not     not

   Content-Base   not     not    not     not

   Content-       may     must   must    must   per RFC 2068 and IANA
   Encoding                                       registry for content

   Content-       not     not    not     not    Application/ipp
   Language                                       handles language

   Content-       must-if must   must-if must   the length of the
   Length                                         message-body per RFC
                                                  2068. Header MUST be
                                                  present if Transfer-

   Entity-Header  Request         Response        Values and Conditions

                  Client  Server Server  Client

                                                  Encoding is absent.

   Content-       not     not    not     not

   Content-MD5    may     may    may     may    per RFC 2068

   Content-Range  not     not    not     not

   Content-Type   must    must   must    must   .application/ipp.

   ETag           not     not    not     not

   Expires        not     not    not     not

Top      Up      ToC       Page 60 
   Last-Modified  not     not    not     not

3.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 [RFC2565] 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.

3.6 HTTP/1.1 Chunking

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

3.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 [HTTP] 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.

Top      Up      ToC       Page 61 
   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 [RFC2565] 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

4  References

   [CGI]     Coar, K. and D. Robinson, "The WWW Common Gateway Interface
             Version 1.1 (CGI/1.1)", Work in Progress.

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

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

   [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
             Powell, "Internet Printing Protocol/1.0: Model and
             Semantics", RFC 2566, April 1999.

   [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
             Printing Protocol/1.0: Encoding and Transport", RFC 2565,
             April 1999.

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

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

   [RFC1123] Braden, S., "Requirements for Internet Hosts - Application
             and Support", STD 3, RFC 1123, October 1989.

Top      Up      ToC       Page 62 
   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.

   [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
             2068, January 1997.

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

   [Servlet] Servlet Specification Version 2.1

   [SSL]     Netscape, The SSL Protocol, Version 3, (Text version 3.02),
             November 1996.

4.1 Authors' Addresses

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


   Carl-Uno Manros
   Xerox Corporation
   701 Aviation Blvd.
   El Segundo, CA 90245


5  Security Considerations

   Security issues are discussed in sections 2.2, 2.3.1, and 8.5.

6  Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it

Top      Up      ToC       Page 63 
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11 [BCP-11].
   Copies of claims of rights made available for publication and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

Top      Up      ToC       Page 64 
Full Copyright Statement

   Copyright (C) The Internet Society (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

   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.