tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3196

 
 
 

Internet Printing Protocol/1.1: Implementor's Guide

Part 4 of 5, p. 55 to 78
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 55 
3.1.3  Status codes returned by operation

   This section corresponds to [RFC2911] section 3.1.6 "Operation
   Response Status Codes and Status Messages".  This section lists all
   status codes once in the first operation (Print-Job).  Then it lists
   the status codes that are different or specialized for subsequent
   operations under each operation.

3.1.3.1  Printer Operations

3.1.3.1.1   Print-Job

   The Printer object MUST return one of the following "status-code"
   values for the indicated reason.  Whether all of the document data
   has been accepted or not before returning the success or error
   response depends on implementation.  See Section 13 in [RFC2911] for
   a more complete description of each status code.

   For the following success status codes, the Job object has been
   created and the "job-id", and "job-uri" assigned and returned in the
   response:

      successful-ok:  no request attributes were substituted or ignored.

      successful-ok-ignored-or-substituted-attributes:  some supplied
      (1) attributes were ignored or (2) unsupported attribute syntaxes
      or values were substituted with supported values or were ignored.
      Unsupported attributes, attribute syntax's, or values MUST be
      returned in the Unsupported Attributes group of the response.

      successful-ok-conflicting-attributes:  some supplied attribute
      values conflicted with the values of other supplied attributes and
      were either substituted or ignored.  Attributes or values which
      conflict with other attributes and have been substituted or
      ignored MUST be returned in the Unsupported Attributes group of
      the response as supplied by the client.

   [RFC2911] section 3.1.6 Operation Status Codes and Messages states:

      If the Printer object supports the "status-message" operation
      attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a
      status message for the following error status codes (see section
      13 in [RFC2911]): 'client-error-bad-request', 'client-error-
      charset-not-supported', 'server-error-internal-error', 'server-

Top      Up      ToC       Page 56 
      error-operation-not-supported', and 'server-error-version-not-
      supported'.  In this case, it MUST set the value of the
      "attributes-charset" operation attribute to 'utf-8' in the error
      response.

      For the following error status codes, no job is created and no
      "job-id" or "job-uri" is returned:

         client-error-bad-request:  The request syntax does not conform
         to the specification.

         client-error-forbidden:  The request is being refused for
         authorization or authentication reasons.  The implementation
         security policy is to not reveal whether the failure is one of
         authentication or authorization.

         client-error-not-authenticated:  Either the request requires
         authentication information to be supplied or the authentication
         information is not sufficient for authorization.

         client-error-not-authorized:  The requester is not authorized
         to perform the request on the target object.

         client-error-not-possible: The request cannot be carried out
         because of the state of the system.  See also 'server-error-
         not-accepting-jobs' status code, which MUST take precedence if
         the Printer object's "printer-accepting-jobs" attribute is
         'false'.

         client-error-timeout:  not applicable.

         client-error-not-found:  the target object does not exist.

         client-error-gone:  the target object no longer exists and no
         forwarding address is known.

         client-error-request-entity-too-large:  the size of the request
         and/or print data exceeds the capacity of the IPP Printer to
         process it.

         client-error-request-value-too-long:  the size of request
         variable length attribute values, such as 'text' and 'name'
         attribute syntax's, exceed the maximum length specified in
         [RFC2911] for the attribute and MUST be returned in the
         Unsupported Attributes Group.

Top      Up      ToC       Page 57 
         supplied is not supported.  The "document-format" attribute
         with the unsupported value MUST be returned in the Unsupported
         Attributes Group.  This error SHOULD take precedence over any
         other 'xxx-not-supported' error, except 'client-error-charset-
         not-supported'.

         client-error-attributes-or-values-not-supported:  one or more
         supplied attributes, attribute syntax's, or values are not
         supported and the client supplied the "ipp-attributes-
         fidelity" operation attribute with a 'true' value.  They MUST
         be returned in the Unsupported Attributes Group as explained
         below.

         client-error-uri-scheme-not-supported:  not applicable.

         client-error-charset-not-supported:  the charset supplied in
         the "attributes-charset" operation attribute is not supported.
         The Printer's "configured-charset" MUST be returned in the
         response as the value of the "attributes-charset" operation
         attribute and used for any 'text' and 'name' attributes
         returned in the error response.  This error SHOULD take
         precedence over any other error, unless the request syntax is
         so bad that the client's supplied "attributes-charset" cannot
         be determined.

         client-error-conflicting-attributes:  one or more supplied
         attribute values conflicted with each other and the client
         supplied the "ipp-attributes-fidelity" operation attribute with
         a 'true' value.  They MUST be returned in the Unsupported
         Attributes Group as explained below.

         server-error-internal-error:  an unexpected condition prevents
         the request from being fulfilled.

         server-error-operation-not-supported:  not applicable (since
         Print-Job is REQUIRED).

         server-error-service-unavailable:  the service is temporarily
         overloaded.

         server-error-version-not-supported:  the version in the request
         is not supported.  The "closest" version number supported MUST
         be returned in the response.

         server-error-device-error:  a device error occurred while
         receiving or spooling the request or document data or the IPP
         Printer object can only accept one job at a time.

Top      Up      ToC       Page 58 
         server-error-temporary-error:  a temporary error such as a
         buffer full write error, a memory overflow, or a disk full
         condition occurred while receiving the request and/or the
         document data.

         server-error-not-accepting-jobs: the Printer object's
         "printer-is-not-accepting-jobs" attribute is 'false'.

         server-error-busy:  the Printer is too busy processing jobs to
         accept another job at this time.

         server-error-job-canceled:  the job has been canceled by an
         operator or the system while the client was transmitting the
         document data.

3.1.3.1.2   Print-URI

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Print-URI with the following
   specializations and differences.  See Section 14 for a more complete
   description of each status code.

         client-error-uri-scheme-not-supported:  the URI scheme supplied
         in the "document-uri" operation attribute is not supported and
         is returned in the Unsupported Attributes group.

         server-error-operation-not-supported: the Print-URI operation
         is not supported.

3.1.3.1.3   Validate-Job

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Validate-Job.  See Section 13 in
   [RFC2911] for a more complete description of each status code.

3.1.3.1.4   Create-Job

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Create-Job with the following
   specializations and differences.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

         server-error-operation-not-supported:  the Create-Job operation
         is not supported.

Top      Up      ToC       Page 59 
         client-error-multiple-document-jobs-not-supported: while the
         Create-Job and Send-Document operations are supported, this
         implementation doesn't support more than one document with
         data.

3.1.3.1.5   Get-Printer-Attributes

         All of the Print-Job status codes described in Section
         3.1.3.1.1 Print-Job Response are applicable to the Get-
         Printer-Attributes operation with the following
         specialization's and differences.   See Section 13 in [RFC2911]
         for a more complete description of each status code.

         For the following success status codes, the requested
         attributes are returned in Group 3 in the response:

         successful-ok:  no operation attributes or values were
         substituted or ignored (same as Print-Job) and no requested
         attributes were unsupported.

         successful-ok-ignored-or-substituted-attributes: The
         "requested-attributes" operation attribute MAY, but NEED NOT,
         be returned with the unsupported values.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For the error status codes, Group 3 is returned containing no
   attributes or is not returned at all:

         client-error-not-possible:  Same as Print-Job, in addition the
         Printer object is not accepting any requests.

         client-error-request-entity-too-large:  same as Print-job,
         except that no print data is involved.

         client-error-attributes-or-values-not-supported:  not
         applicable, since unsupported operation attributes and/or
         values MUST be ignored and an appropriate success code returned
         (see above).

         client-error-conflicting-attributes:  same as Print-Job, except
         that "ipp-attribute-fidelity" is not involved.

         server-error-operation-not-supported: not applicable (since
         Get-Printer-Attributes is REQUIRED).

         server-error-device-error:  same as Print-Job, except that no
         document data is involved.

Top      Up      ToC       Page 60 
         server-error-temporary-error:  same as Print-Job, except that
         no document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-busy:  same as Print-Job, except the IPP object is
         too busy to accept even query requests.

         server-error-job-canceled:  not applicable.

3.1.3.1.6   Get-Jobs

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to the Get-Jobs operation with the
   following specialization's and differences.   See Section 13 in
   [RFC2911] for a more complete description of each status code.

   For the following success status codes, the requested attributes are
   returned in Group 3 in the response:

         successful-ok:  same as Get-Printer-Attributes (see section
         3.1.3.1.5).

         successful-ok-ignored-or-substituted-attributes: same as Get-
         Printer-Attributes (see section 3.1.3.1.5).

         successful-ok-conflicting-attributes: same as Get-Printer-
         Attributes (see section 3.1.3.1.5).

   For any error status codes, Group 3 is returned containing no
   attributes or is not returned at all.  The following brief error
   status code descriptions contain unique information for use with
   Get-Jobs operation.  See section 14 for the other error status codes
   that apply uniformly to all operations:

         client-error-not-possible:  Same as Print-Job, in addition the
         Printer object is not accepting any requests.

         client-error-request-entity-too-large:  same as Print-job,
         except that no print data is involved.

         client-error-document-format-not-supported:  not applicable.

         client-error-attributes-or-values-not-supported:  not
         applicable, since unsupported operation attributes and/or
         values MUST be ignored and an appropriate success code returned
         (see above).

Top      Up      ToC       Page 61 
         client-error-conflicting-attributes:  same as Print-Job, except
         that "ipp-attribute-fidelity" is not involved.

         server-error-operation-not-supported:  not applicable (since
         Get-Jobs is REQUIRED).

         server-error-device-error:  same as Print-Job, except that no
         document data is involved.

         server-error-temporary-error:  same as Print-Job, except that
         no document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

3.1.3.1.7   Pause-Printer

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Pause-Printer with the following
   specializations and differences.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

   For the following success status codes, the Printer object is being
   stopped from scheduling jobs on all its devices.

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:  same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Printer object has not been
   stopped from scheduling jobs on all its devices.

         client-error-not-possible: not applicable.

         client-error-not-found:  the target Printer object does not
         exist.

         client-error-gone:  the target Printer object no longer exists
         and no forwarding address is known.

         client-error-request-entity-too-large:  same as Print-Job,
         except no document data is involved.

Top      Up      ToC       Page 62 
         client-error-document-format-not-supported:  not applicable.

         client-error-conflicting-attributes:  same as Print-Job, except
         that the Printer's "printer-is-accepting-jobs" attribute is not
         involved.

         server-error-operation-not-supported: the Pause-Printer
         operation is not supported.

         server-error-device-error: not applicable.

         server-error-temporary-error:  same as Print-Job, except no
         document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

3.1.3.1.8   Resume-Printer

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Pause-
   Printer are applicable to Resume-Printer.  See Section 13 in
   [RFC2911] for a more complete description of each status code.

   For the following success status codes, the Printer object resumes
   scheduling jobs on all its devices.

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:   same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Printer object does not resume
   scheduling jobs.

         server-error-operation-not-supported: the Resume-Printer
         operation is not supported.

Top      Up      ToC       Page 63 
3.1.3.1.8.1   What about Printers unable to change state due to an error
              condition?

   If, in case, the IPP printer is unable to change its state due to
   some problem with the actual printer device (say, it is shut down or
   there is a media-jam as indicated in [RFC2911]), what should be the
   result of the "Resume-Printer" operation?  Should it still change the
   'printer-state-reasons' and return success or should it fail ?

   The Resume-Printer operation must clear the 'paused' or 'moving-to-
   paused' 'printer-state-message'.  The operation must return a
   'successful-ok' status code.

3.1.3.1.8.2   How is "printer-state" handled on Resume-Printer?

   If the Resume-Printer operation succeeds, what should be the value of
   "printer-state" and  who should take care of the "printer-state"
   attribute value later on ?

   The Resume-Printer operation may change the "printer-state-reasons"
   value.

   The "printer-state" will change to one of three states:

      1. 'idle' - no additional jobs and no error conditions present

      2. 'processing' - job available and no error conditions present

      3. current state (i.e. no change) an error condition is present
         (e.g. media jam)

   In the third case the "printer-state-reason" will be cleared by
   automata when it detects the error condition no longer exists.  The
   "printer-state" will move to 'idle' or 'processing' when conditions
   permit. (i.e. no more error conditions)

3.1.3.1.9   Purge-Printer

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Pause-
   Printer are applicable to Purge-Printer.  See Section 13 in [RFC2911]
   for a more complete description of each status code.

   For the following success status codes, the Printer object purges all
   it's jobs.

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

Top      Up      ToC       Page 64 
         successful-ok-ignored-or-substituted-attributes:   same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Printer object does not purge
   any jobs.

         server-error-operation-not-supported: the Purge-Printer
         operation is not supported.

3.1.3.2  Job Operations

3.1.3.2.1   Send-Document

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to the Get-Printer-Attributes
   operation with the following specialization's and differences.   See
   Section 13 in [RFC2911] for a more complete description of each
   status code.

   For the following success status codes, the document has been added
   to the specified Job object and the job's "number-of-documents"
   attribute has been incremented:

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:  same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For the error status codes, no document has been added to the Job
   object and the job's "number-of-documents" attribute has not been
   incremented:

         client-error-not-possible: Same as Print-Job, except that the
         Printer's "printer-is-accepting-jobs" attribute is not
         involved, so that the client is able to finish submitting a job
         that was created with a Create-Job operation after this
         attribute has been set to 'true'.  Another condition is that
         the state of the job precludes Send-Document, i.e., the job has

Top      Up      ToC       Page 65 
         already been closed out by the client.  However, if the IPP
         Printer closed out the job due to timeout, the 'client-error-
         timeout' error status SHOULD  be returned instead.

         client-error-timeout: This request was sent after the Printer
         closed the job, because it has not received a Send-Document or
         Send-URI operation within the Printer's "multiple-operation-
         time-out" period .

         client-error-request-entity-too-large:  same as Print-Job.

         client-error-conflicting-attributes:  same as Print-Job, except
         that "ipp-attributes-fidelity" operation attribute is not
         involved..

         server-error-operation-not-supported:  the Send-Document
         request is not supported.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  the job has been canceled by an
         operator or the system while the client was transmitting the
         data.

3.1.3.2.2   Send-URI

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Send-
   Document are applicable to Send-URI.  See Section 13 in [RFC2911] for
   a more complete description of each status code.

         client-error-uri-scheme-not-supported:  the URI scheme supplied
         in the "document-uri" operation attribute is not supported and
         the "document-uri" attribute MUST be returned in the
         Unsupported Attributes group.

         server-error-operation-not-supported: the Send-URI operation is
         not supported.

3.1.3.2.3   Cancel-Job

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Cancel-Job with the following
   specializations and differences.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

   For the following success status codes, the Job object is being
   canceled or has been canceled:

Top      Up      ToC       Page 66 
         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:   same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Job object has not been
   canceled or was previously canceled.

         client-error-not-possible:  The request cannot be carried out
         because of the state of the Job object ('completed',
         'canceled', or 'aborted') or the state of the system.

         client-error-not-found:  the target Printer and/or Job object
         does not exist.

         client-error-gone:  the target Printer and/or Job object no
         longer exists and no forwarding address is known.

         client-error-request-entity-too-large:  same as Print-Job,
         except no document data is involved.

         client-error-document-format-not-supported:  not applicable.

         client-error-attributes-or-values-not-supported:  not
         applicable, since unsupported operation attributes and values
         MUST be ignored.

         client-error-conflicting-attributes:  same as Print-Job, except
         that the Printer's "printer-is-accepting-jobs" attribute is not
         involved.

         server-error-operation-not-supported:  not applicable (Cancel-
         Job is REQUIRED).

         server-error-device-error:  same as Print-Job, except no
         document data is involved.

         server-error-temporary-error:  same as Print-Job, except no
         document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

Top      Up      ToC       Page 67 
3.1.3.2.4   Get-Job-Attributes

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Get-Job-Attributes with the
   following specializations and differences.  See Section 13 in
   [RFC2911] for a more complete description of each status code.

   For the following success status codes, the requested attributes are
   returned in Group 3 in the response:

         successful-ok:  same as Get-Printer-Attributes (see section
         3.1.3.1.5).

         successful-ok-ignored-or-substituted-attributes:  same as Get-
         Printer-Attributes (see section 3.1.3.1.5).

         successful-ok-conflicting-attributes:  same as Get-Printer-
         Attributes (see section 3.1.3.1.5).

   For the error status codes, Group 3 is returned containing no
   attributes or is not returned at all.

         client-error-not-possible:  Same as Print-Job, in addition the
         Printer object is not accepting any requests.

         client-error-document-format-not-supported:  not applicable.

         client-error-attributes-or-values-not-supported:  not
         applicable.

         client-error-uri-scheme-not-supported:  not applicable.

         client-error-attributes-or-values-not-supported:  not
         applicable, since unsupported operation attributes and/or
         values MUST be ignored and an appropriate success code returned
         (see above).

         client-error-conflicting-attributes:  not applicable

         server-error-operation-not-supported:  not applicable (since
         Get-Job-Attributes is REQUIRED).

         server-error-device-error:  same as Print-Job, except no
         document data is involved.

         server-error-temporary-error:  sane as Print-Job, except no
         document data is involved..

Top      Up      ToC       Page 68 
         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

3.1.3.2.5   Hold-Job

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Hold-Job with the following
   specializations and differences.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

   For the following success status codes, the Job object is being held
   or has been held:

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:   same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Job object has not been held
   or was previously held.

         client-error-not-possible:  The request cannot be carried out
         because of the state of the Job object ('completed',
         'canceled', or 'aborted') or the state of the system.

         client-error-not-found:  the target Printer and/or Job object
         does not exist.

         client-error-gone:  the target Printer and/or Job object no
         longer exists and no forwarding address is known.

         client-error-request-entity-too-large:  same as Print-Job,
         except no document data is involved.

         client-error-document-format-not-supported:  not applicable.

         client-error-conflicting-attributes:  same as Print-Job, except
         that the Printer's "printer-is-accepting-jobs" attribute is not
         involved.

         server-error-operation-not-supported: the Hold-Job operation is
         not supported.

         server-error-device-error: not applicable.

Top      Up      ToC       Page 69 
         server-error-temporary-error:  same as Print-Job, except no
         document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

3.1.3.2.6   Release-Job

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Hold-Job
   are applicable to Release-Job.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

         server-error-operation-not-supported: the Release-Job operation
         is not supported.

3.1.3.2.7   Restart-Job

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Hold-Job
   are applicable to Restart-Job.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

         server-error-operation-not-supported: the Restart-Job operation
         is not supported.

3.1.3.2.7.1   Can documents be added to a restarted job?

   Assume I give a Create-Job request along with a set of 5 documents.
   All the documents get printed and the job state is moved to
   completed.  I issue a Restart-Job request on the job. Now the issue
   is that, if I try to add new documents to the restarted job, will the
   IPP Server permit me to do so or  return "client-error-not-possible "
   and again print those 5 jobs?

   A job can not move to the 'completed' state until all the documents
   have been processed.  The 'last-document' flag indicates when the
   last document for a job is being sent from the client.  This is the
   semantic equivalent of closing a job.  No documents may be added once
   a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job
   is moved to the 'pending' job state and restarts the beginning on the
   same IPP Printer object with the same attribute values."  'number-
   of-documents' is a job attribute.

Top      Up      ToC       Page 70 
3.1.4  Returning unsupported attributes in Get-Xxxx responses (Issue
       1.18)

   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.

3.1.5  Sending empty attribute groups

   The [RFC2911] and [RFC2910] 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.

   The [RFC2910] 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.  [RFC2910] contains the following
   paragraph:

   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.

Top      Up      ToC       Page 71 
3.2  Printer Operations

3.2.1  Print-Job operation

3.2.1.1  Flow controlling the data portion of a Print-Job request (Issue
         1.22)

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

3.2.1.2  Returning job-state in Print-Job response (Issue 1.30)

   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
   could query the server and see that the job was in the 'completed'
   state and completed as specified by the jobs "time-at-completed"
   time, which would be the same as the server submitted the job to the
   device.

Top      Up      ToC       Page 72 
   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'
   value.

   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.

3.2.2  Get-Printer-Attributes operation

   If a Printer supports the "printer-make-and-model" attribute and
   returns the .INF file model name of the printer in that attribute,
   the Microsoft client will automatically install the correct driver
   (if available).

   Clients which poll periodically for printer status or queued-job-
   count should use the "requested-attributes" operation attribute  to
   limit the scope of the query in order to save Printer and network
   resources.

3.2.3  Get-Jobs operation

3.2.3.1  Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
         1.39)?

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

   [RFC2911] 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
   "anonymous".

Top      Up      ToC       Page 73 
3.2.3.2  Why is there a "limit" attribute in the Get-Jobs operation?

   When using the Get-Jobs operation a client implementer might choose
   to limit the number of jobs that the client shows on the first
   screenful.  For example, if its UI can only display 50 jobs, it can
   defend itself against a printer that would otherwise return 500 jobs,
   perhaps taking a long time on a slow dial-up line. The client can
   then go and ask for a larger number of jobs in the background, while
   showing the user the first 50 jobs. Since the job history is returned
   in reverse order, namely the most recently completed jobs are
   returned first, the user is most likely interested in the first jobs
   that are returned. Limiting the number of jobs may be especially
   useful for a client that is requesting 'completed' jobs from a
   printer that keeps a long job history. Clients that don't mind
   sometimes getting very large responses, can omit the "limit"
   attribute in their Get-Jobs requests.

3.2.4  Create-Job operation

   A Printer may respond to a Create-Job operation with "job-state"
   'pending' or 'pending-held' and " job-state-reason" 'job-data-
   insufficient' to indicate that operation has been accepted by the
   Printer, but the Printer is expecting additional document data before
   it can move the job into the 'processing' state.  Alternatively, it
   may respond with "job-state" 'processing' and "job-state-reason"
   'job-incoming'  to indicate that the Create-Job operation has been
   accepted by the Printer, but the Printer is expecting additional
   Send-Document and/or Send-URI operations and/or is
   accessing/accepting document data.  The second alternative is for
   non-spooling Printers that don't implement the 'pending' state.

   Should the server wait for the "last-document" operation attribute
   set to 'true' before starting to "process" the job?

   It depends on implementation. Some servers spool the entire job,
   including all document data, before starting to process, so such an
   implementation would wait for the "last-document" before starting to
   process the job. If the time-out occurs without the "last-document",
   then the server takes one of the indicated actions in section 3.3.1
   in the [RFC2911] document. Other servers will start to process
   document data as soon as they have some. These are the so-called
   "non-spooling" printers. Currently, there isn't a way for a client to
   determine whether the Printer will spool all the data or will start
   to process (and print) as soon as it has some data.

Top      Up      ToC       Page 74 
3.3  Job Operations

3.3.1  Validate-Job

   The Validate-Job operation has been designed so that its
   implementation may be a part of the Print-Job operation.  Therefore,
   requiring Validate-Job is not a burden on implementers.  Also it is
   useful for client's to be able to count on its presence in all
   conformance implementations, so that the client can determine before
   sending a long document, whether the job will be accepted by the IPP
   Printer or not.

3.3.2   Restart-Job

   The Restart-Job operation allows the reprocessing of a completed job.
   Some jobs store the document data on the printer.  Jobs created using
   the Print-Job operation are an example.  It is required that the
   printer retains the job data after the job has moved to a 'completed
   state' in order for the Restart-Job operation to succeed.

   Some jobs contain only a reference to the job data.  A job created
   using the Print-URI is an example of such a job.  When the Restart-
   Job operation is issued the job is reprocessed. The job data MUST be
   retrieved again to print the job.

   It is possible that a job fails while attempting to access the print
   data.  When such a job is the target of a Restart-Job  the Printer
   SHALL attempt to retrieve the job data again.

4  Object Attributes

4.1  Attribute Syntax's

4.1.1  The 'none' value for empty sets (Issue 1.37)

   [RFC2911] 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
   syntax.

Top      Up      ToC       Page 75 
4.1.2  Multi-valued attributes (Issue 1.31)

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

4.1.3  Case Sensitivity in URIs (issue 1.6)

   IPP client and server implementations must be aware of the diverse
   uppercase/lowercase nature of URIs.  RFC 2396 defines URL schemes and
   Host names as case insensitive but reminds us that the rest of the
   URL may well demonstrate case sensitivity.  When creating URL's for
   fields where the choice is completely arbitrary, it is probably best
   to select lower case.  However, this cannot be guaranteed and
   implementations MUST NOT rely on any fields being case-sensitive or
   case-insensitive in the URL beyond the URL scheme and host name
   fields.

   The reason that the IPP specification does not make any restrictions
   on URIs, is so that implementations of IPP may use off-the-shelf
   components that conform to the standards that define URIs, such as
   RFC 2396 and the HTTP/1.1 specifications [RFC2616].  See these
   specifications for rules of matching, comparison, and case-
   sensitivity.

   It is also recommended that System Administrators and implementations
   avoid creating URLs for different printers that differ only in their
   case.  For example, don't have Printer1 and printer1 as two different
   IPP Printers.

   Example of equivalent URI's

        http://abc.com:80/~smith/home.html

        http://ABC.com/%7Esmith/home.html

        http:/ABC.com:/%7esmith/home.html

   Example of equivalent URI's using the IPP scheme

        ipp://abc.com:631/~smith/home.html

Top      Up      ToC       Page 76 
        ipp://ABC.com/%7Esmith/home.html

        http:/ABC.com:631/%7esmith/home.html

   The HTTP/1.1 specification [RFC2616] contains more details on
   comparing URLs.

4.1.4  Maximum length for xxxWithLanguage and xxxWithoutLanguage

   The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes
   that have two components.  The first component is the 'language'
   component that can contain up to 63 octets.  The second component is
   the 'text' or 'name' component.  The maximum length of these are 1023
   octets and 255 octets respectively.  The definition of attributes
   with either syntax may further restrict the length (e.g., printer-
   name (name(127))).

   The length of the 'language' component has no effect on the allowable
   length of 'text' in 'textWithLanguage' or the length of 'name' in
   'nameWithLanguage'

4.2  Job Template Attributes

4.2.1  multiple-document-handling(type2 keyword)

4.2.1.1  Support of multiple document jobs

   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" or multiple documents per job.  IPP/1.1
   was changed so that a Printer could support Create-Job without having
   to support multiple document jobs.  The "multiple-document-jobs-
   supported" (boolean) Printer description attribute was added to
   IPP/1.1 along with the 'server-error-multiple-document-jobs-not-
   supported' status code for a Printer to indicate whether or not it
   supports multiple document jobs, when it supports the Create-Job
   operation.  Also IPP/1.1 was clarified that the Printer MUST support
   the "multiple-document-handling" (type2 keyword) Job Template
   attribute with at least one value if the Printer supports multiple
   documents per job.

4.3  Job Description Attributes

4.3.1  Getting the date and time of day

   The "date-time-at-creation", "date-time-at-processing", and "date-
   time-at-completed" attributes are returned as dateTime syntax.  These
   attributes are OPTIONAL for a Printer to support.  However, there are

Top      Up      ToC       Page 77 
   various ways for a Printer to get the date and time of day.  Some
   suggestions:

      1. A Printer can get time from an NTP timeserver if there's one
         reachable on the network .  See RFC 1305.  Also DHCP option 32
         in RFC 2132 returns the IP address of the NTP server.

      2. Get the date and time at startup from a human operator

      3. Have an operator set the date and time using a web
         administrative interface

      4. Get the date and time from incoming HTTP requests, though the
         problems of spoofing need to be considered.  Perhaps comparing
         several HTTP requests could reduce the chances of spoofing.

      5. Internal date time clock battery driven.

      6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"

4.4  Printer Description Attributes

4.4.1  queued-job-count (integer(0:MAX))

4.4.1.1  Why is "queued-job-count" RECOMMENDED (Issue 1.14)?

   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.

4.4.1.2  Is "queued-job-count" a good measure of how busy a printer is
         (Issue 1.15)?

   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.

Top      Up      ToC       Page 78 
4.4.2  printer-current-time (dateTime)

   A Printer implementation MAY support this attribute by obtaining the
   date and time by any number of implementation-dependent means at
   startup or subsequently.  Examples include:

      1. an internal date time clock,

      2. from the operator at startup using the console,

      3. from an operator using an administrative web page,

      4. from HTTP headers supplied in client requests,

      5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"

      6. from the network, using NTP [RFC1305] or DHCP option 32
         [RFC2132] that returns the IP address of the NTP server.

   If an implementation supports this attribute by obtaining the current
   time from the network (at startup or later), but the time is not
   available, then the implementation MUST return the value of this
   attribute using the out-of-band 'no-value' meaning not configured.
   See the beginning of section 4.1.

   Since the new "date-and-time-at-xxx" Job Description attributes refer
   to the "printer-current-time", they will be covered also.

4.4.3  Printer-uri

   Must the operational attribute for printer-uri match one of the
   values in "printer-uri-supported"?

   A forgiving printer implementation would not reject the operation.
   But the implementation has its rights to reject a printer or job
   operation if the operational attribute printer-uri is not a value of
   the printer-uri-supported.  The printer might not be improperly
   configured.  The request obviously reached the printer. The printer
   could treat the printer-uri as the logical equivalent of a value in
   the printer-uri-supported.  It would be implementation dependent for
   which value, and associated security policy, would apply. This does
   also apply to a job object specified with a printer-uri and job-id,
   or with a job-uri. See section 4.1.3 for how to compare URI's.


Next RFC Part