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

RFC 3196

 Errata 
Informational
Pages: 96
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IPP

Internet Printing Protocol/1.1: Implementor's Guide

Part 1 of 5, p. 1 to 17
None       Next RFC Part

Obsoletes:    2639


Top       ToC       Page 1 
Network Working Group                                        T. Hastings
Request for Comments: 3196                                     C. Manros
Obsoletes: 2639                                                P. Zehler
Category: Informational                                Xerox Corporation
                                                               C. Kugler
                                                 IBM Printing Systems Co
                                                                H. Holst
                                                 i-data Printing Systems
                                                           November 2001


          Internet Printing Protocol/1.1: Implementor's Guide

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP).

Table of Contents

   1  Introduction...................................................  4
   1.1   Conformance language........................................  5
   1.2   Other terminology...........................................  6
   1.3   Issues Raised from Interoperability Testing Events..........  6
   2  IPP Objects....................................................  6
   3  IPP Operations.................................................  7
   3.1   Common Semantics............................................  7
   3.1.1  Summary of Operation Attributes............................  8
   3.1.2  Suggested Operation Processing Steps for IPP Objects....... 16
   3.1.2.1   Suggested Operation Processing Steps for all Operations. 17
   3.1.2.1.1   Validate version number............................... 18
   3.1.2.1.2   Validate operation identifier......................... 20
   3.1.2.1.3   Validate the request identifier....................... 20
   3.1.2.1.4   Validate attribute group and attribute presence and
               order................................................. 20
   3.1.2.1.4.1   Validate the presence and order of attribute groups. 20
   3.1.2.1.4.2   Ignore unknown attribute groups in the expected
                 position............................................ 21

Top      ToC       Page 2 
   3.1.2.1.4.3   Validate the presence of a single occurrence of
                 required Operation attributes....................... 21
   3.1.2.1.5   Validate the values of the REQUIRED Operation
               attributes............................................ 29
   3.1.2.1.6   Validate the values of the OPTIONAL Operation
               attributes............................................ 33
   3.1.2.2   Suggested Additional Processing Steps for Operations
             that Create/Validate Jobs and Add Documents............. 37
   3.1.2.2.1   Default "ipp-attribute-fidelity" if not supplied...... 37
   3.1.2.2.2   Check that the Printer object is accepting jobs....... 38
   3.1.2.2.3   Validate the values of the Job Template attributes.... 38
   3.1.2.3   Algorithm for job validation............................ 39
   3.1.2.3.1   Check for conflicting Job Template attributes values.. 45
   3.1.2.3.2   Decide whether to REJECT the request.................. 46
   3.1.2.3.3   For the Validate-Job operation, RETURN one of the
               success status codes.................................. 48
   3.1.2.3.4   Create the Job object with attributes to support...... 48
   3.1.2.3.5   Return one of the success status codes................ 50
   3.1.2.3.6   Accept appended Document Content...................... 50
   3.1.2.3.7   Scheduling and Starting to Process the Job............ 50
   3.1.2.3.8   Completing the Job.................................... 50
   3.1.2.3.9   Destroying the Job after completion................... 51
   3.1.2.3.10  Interaction with "ipp-attribute-fidelity"............. 51
   3.1.2.3.11  Character set code conversion support................. 51
   3.1.2.3.12  What charset to return when an unsupported charset is
               requested (Issue 1.19)?....... ....................... 52
   3.1.2.3.13  Natural Language Override (NLO)....................... 53
   3.1.3  Status codes returned by operation......................... 55
   3.1.3.1   Printer Operations...................................... 55
   3.1.3.1.1   Print-Job............................................. 55
   3.1.3.1.2   Print-URI............................................. 58
   3.1.3.1.3   Validate-Job.......................................... 58
   3.1.3.1.4   Create-Job............................................ 58
   3.1.3.1.5   Get-Printer-Attributes................................ 59
   3.1.3.1.6   Get-Jobs.............................................. 60
   3.1.3.1.7   Pause-Printer......................................... 61
   3.1.3.1.8   Resume-Printer........................................ 62
   3.1.3.1.8.1   What about Printers unable to change state due to
                 an error condition?................................. 63
   3.1.3.1.8.2   How is "printer-state" handled on Resume-Printer?... 63
   3.1.3.1.9   Purge-Printer......................................... 63
   3.1.3.2   Job Operations.......................................... 64
   3.1.3.2.1   Send-Document......................................... 64
   3.1.3.2.2   Send-URI.............................................. 65
   3.1.3.2.3   Cancel-Job............................................ 65
   3.1.3.2.4   Get-Job-Attributes.................................... 67
   3.1.3.2.5   Hold-Job.............................................. 68
   3.1.3.2.6   Release-Job........................................... 69

Top      ToC       Page 3 
   3.1.3.2.7   Restart-Job........................................... 69
   3.1.3.2.7.1   Can documents be added to a restarted job?.......... 69
   3.1.4  Returning unsupported attributes in Get-Xxxx responses
          (Issue 1.18)............................................... 70
   3.1.5  Sending empty attribute groups............................. 70
   3.2   Printer Operations.......................................... 71
   3.2.1  Print-Job operation........................................ 71
   3.2.1.1   Flow controlling the data portion of a Print-Job
             request (Issue 1.22).................................... 71
   3.2.1.2   Returning job-state in Print-Job response (Issue 1.30).. 71
   3.2.2  Get-Printer-Attributes operation........................... 72
   3.2.3  Get-Jobs operation......................................... 72
   3.2.3.1   Get-Jobs, my-jobs='true', and 'requesting-user-name'
             (Issue 1.39)?..........................................  72
   3.2.3.2   Why is there a "limit" attribute in the Get-Jobs
             operation?.............................................. 73
   3.2.4  Create-Job operation....................................... 73
   3.3   Job Operations.............................................. 74
   3.3.1  Validate-Job............................................... 74
   3.3.2  Restart-Job................................................ 74
   4  Object Attributes.............................................. 74
   4.1   Attribute Syntax's.......................................... 74
   4.1.1  The 'none' value for empty sets (Issue 1.37)............... 74
   4.1.2  Multi-valued attributes (Issue 1.31)....................... 75
   4.1.3  Case Sensitivity in URIs (issue 1.6)....................... 75
   4.1.4  Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
   4.2   Job Template Attributes..................................... 76
   4.2.1  multiple-document-handling(type2 keyword).................. 76
   4.2.1.1   Support of multiple document jobs....................... 76
   4.3   Job Description Attributes.................................. 76
   4.3.1  Getting the date and time of day........................... 76
   4.4   Printer Description Attributes.............................. 77
   4.4.1  queued-job-count (integer(0:MAX)).......................... 77
   4.4.1.1   Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
   4.4.1.2   Is "queued-job-count" a good measure of how busy a
             printer is (Issue 1.15)?................................ 77
   4.4.2  printer-current-time (dateTime)............................ 78
   4.4.3  Printer-uri................................................ 78
   4.5   Empty Jobs.................................................. 79
   5  Directory Considerations....................................... 79
   5.1   General Directory Schema Considerations..................... 79
   5.2   IPP Printer with a DNS name................................. 79
   6  Security Considerations........................................ 80
   6.1   Querying jobs with IPP that were submitted using other job
         submission protocols (Issue 1.32)........................... 80
   7  Encoding and Transport......................................... 81
   7.1   General Headers............................................. 83
   7.2   Request  Headers............................................ 84

Top      ToC       Page 4 
   7.3   Response Headers............................................ 86
   7.4   Entity  Headers............................................. 87
   7.5   Optional support for HTTP/1.0............................... 88
   7.6   HTTP/1.1 Chunking........................................... 88
   7.6.1  Disabling IPP Server Response Chunking..................... 88
   7.6.2  Warning About the Support of Chunked Requests.............. 88
   8  References..................................................... 89
   9  Authors' Addresses............................................. 91
   10 Description of the Base IPP Documents.......................... 94
   11 Full Copyright Statement....................................... 96

Tables

   Table 1 - Summary of Printer operation attributes that sender MUST
             supply .................................................  8
   Table 2 - Summary of Printer operation attributes that sender MAY
             supply ................................................. 10
   Table 3 - Summary of Job operation attributes that sender MUST
             supply.................................................. 12
   Table 4 - Summary of Job operation attributes that sender MAY
             supply.................................................. 14
   Table 5 - Printer operation response attributes................... 16
   Table 6 - Examples of validating IPP version...................... 19
   Table 7 - Rules for validating single values X against Z.......... 40

1. Introduction

   IPP is an application level protocol that can be used for distributed
   printing using Internet tools and technologies.  This document
   contains information that supplements the IPP Model and Semantics
   [RFC2911] and the IPP Transport and Encoding [RFC2910] documents.  It
   is intended to help implementers understand IPP/1.1, as well as
   IPP/1.0 [RFC2565, RFC2566], and some of the considerations that may
   assist them in the design of their client and/or IPP object
   implementation.  For example, a typical order of processing requests
   is given, including error checking.  Motivation for some of the
   specification decisions is also included.

   This document obsoletes RFC 2639 which was the Implementor's Guide
   for IPP/1.0.  The IPP Implementor's Guide (IIG) (this document)
   contains information that supplements the IPP Model and Semantics
   [RFC2911] and the IPP Transport and Encoding [RFC2910] documents.
   This document is just one of a suite of documents that fully define
   IPP.  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
      Internet Printing Protocol [RFC2568]

Top      ToC       Page 5 
      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
      Internet Printing Protocol/1.1: Implementor's Guide (this
      document)
      Mapping between LPD and IPP Protocols [RFC2569]

   See section 10 for a description of these base IPP documents.  Anyone
   reading these documents for the first time is strongly encouraged to
   read the IPP documents in the above order.

   As such the information in this document is not part of the formal
   specification of IPP/1.1.  Instead information is presented to help
   implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565,
   RFC2566], including some of the motivation for decisions taken by the
   committee in developing the specification.  Some of the
   implementation considerations are intended to help implementers
   design their client and/or IPP object implementations.  If there are
   any contradictions between this document and [RFC2911] or [RFC2910],
   those documents take precedence over this document.

   Platform-specific implementation considerations will be included in
   this guide as they become known.

   Note:  In order to help the reader of the IIG and the IPP Model and
   Semantics document, the sections in this document parallel the
   corresponding sections in the Model document and are numbered the
   same for ease of cross reference.  The sections that correspond to
   the IPP Transport and Encoding are correspondingly offset.

1.1  Conformance language

   Usually, this document does not contain the terminology MUST, MUST
   NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
   However, when those terms do appear in this document, their intent is
   to repeat what the [RFC2911] and [RFC2910] documents require and
   allow, rather than specifying additional conformance requirements.
   These terms are defined in section 12 on conformance terminology in
   [RFC2911], most of which is taken from RFC 2119 [RFC2119].

   Implementers should read section 12 (APPENDIX A) in [RFC2911] in
   order to understand these capitalized words.  The words MUST, MUST
   NOT, and REQUIRED indicate what implementations are required to
   support in a client or IPP object in order to be conformant to
   [RFC2911] and [RFC2910].  MAY, NEED NOT, and OPTIONAL indicate was is
   merely allowed as an implementer option.  The verbs SHOULD and SHOULD
   NOT indicate suggested behavior, but which is not required or
   disallowed, respectively, in order to conform to the specification.

Top      ToC       Page 6 
1.2  Other terminology

   This document uses other terms, such as "attributes", "operation",
   and "Printer" as defined in [RFC2911] section 12.  In addition, the
   term "sender" refers to the client that sends a request or an IPP
   object that returns a response.  The term "receiver" refers to the
   IPP object that receives a request and to a client that receives a
   response.

1.3  Issues Raised from Interoperability Testing Events

   The IPP WG has conducted three open Interoperability Testing Events.
   The first one was held in September 1998, the second one was held in
   March 1999, and the third one was held in October 2000.  See the
   summary reports in:

      ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/

   The issues raised from the first Interoperability Testing Event are
   numbered 1.n in this document and have been incorporated into
   "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and
   Transport" [RFC2565] documents.  However, some of the discussion is
   left here in the Implementor's Guide to help understanding.

   The issues raised from the second Interoperability Testing Event are
   numbered 2.n in this document have been incorporated into "IPP/1.1
   Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and
   Transport" [RFC2910] documents.  However, some of the discussion is
   left here in the Implementor's Guide to help understanding.

   The issues raised from the third Interoperability Testing Event are
   numbered 3.n in this document and are described in:

      ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
      Off3.pdf

      ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
      Off3.doc

      ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
      Off3.txt

Top      ToC       Page 7 
2.  IPP Objects

   The term "client" in IPP is intended to mean any client that issues
   IPP operation requests and accepts IPP operation responses, whether
   it be a desktop or a server.  In other words, the term "client" does
   not just mean end-user clients, such as those associated with
   desktops.

   The term "IPP Printer" in IPP is intended to mean an object that
   accepts IPP operation requests and returns IPP operation responses,
   whether implemented in a server or a device.  An IPP Printer object
   MAY, if implemented in a server, turn around and forward received
   jobs (and other requests) to other devices and print
   servers/services, either using IPP or some other protocol.

3  IPP Operations

   This section  corresponds to Section 3 "IPP Operations" in the
   IPP/1.1 Model and Semantics document [RFC2911].

3.1  Common Semantics

   This section discusses semantics common to all operations.

Top      ToC       Page 8 
3.1.1  Summary of Operation Attributes

   Table 1 - Summary of Printer operation attributes that sender MUST
             supply

Printer Operations

                     Requests                               Responses
   Operation         PJ,    PU    CJ    GPA    GJ    PP,    All
   Attributes        VJ     (O)   (O)   (R)    (R)   RP,    Operations
                     (R)                             PP
                                                     (O+)

   Operation parameters--REQUIRED to be supplied by the sender:

   operation-id      R      R     R     R      R     R

   status-code                                              R

   request-id        R      R     R     R      R     R      R

   version-number    R      R     R     R      R     R      R

   Operation attributes--REQUIRED to be supplied by the sender:

   attributes-       R      R     R     R      R     R      R
     charset

   attributes-       R      R     R     R      R     R      R
     natural-
     language

   document-uri             R

   job-id*

   job-uri*

Top      ToC       Page 9 
Printer Operations

                     Requests                               Responses

   Operation         PJ,    PU    CJ    GPA    GJ    PP,    All
   Attributes        VJ     (O)   (O)   (R)    (R)   RP,    Operations
                     (R)                             PP
                                                     (O+)
   last-document

   printer-uri       R      R     R     R      R     R

   Operation  attributes--RECOMMENDED   to  be  supplied   by  the
     sender:

   job-name          R      R     R

   requesting-user-  R      R     R      R      R     R
     name

   Legend:

   PJ, VJ:  Print-Job, Validate-Job
   PU:  Print-URI
   CJ:  Create-Job
   GPA:  Get-Printer-Attributes
   GJ:  Get-Jobs
   PP, RP, PP:  Pause-Printer, Resume-Printer, Purge-Printer
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).
   +  indicates that this is not an IPP/1.0 feature, but is only a part
      of IPP/1.1 and future versions of IPP.

Top      ToC       Page 10 
     Table 2 - Summary of Printer operation attributes that sender MAY
               supply

Printer Operations

                         Requests                                Respon-
                                                                 ses
   Operation Attributes  PJ,    PU     CJ     GPA    GJ     PP,  All
                         VJ     (O)    (O)    (R)    (R)    RP,  Opera
                         (R)                                PP   tions
                                                            (O+)

   Operation attributes--OPTIONAL to be supplied by the sender:

   status-message                                                 O

   detailed-status-                                               O
     message

   document-access-                                               O**
     error

   compression           R      R

   document-format       R      R             R

   document-name         O      O

   document-natural-     O      O
     language

   ipp-attribute-        R      R      R
     fidelity

   job-impressions       O      O      O

   job-k-octets          O      O      O

   job-media-sheets      O      O      O

Top      ToC       Page 11 
Printer Operations

                         Requests                                Respon-
                                                                 ses
   Operation Attributes  PJ,    PU     CJ     GPA    GJ     PP,  All
                         VJ     (O)    (O)    (R)    (R)    RP,  Opera
                         (R)                                PP   tions
                                                            (O+)

   limit                                             R

   message

   my-jobs                                           R

   requested-attributes                       R      R

   which-jobs                                        R

   Legend:

   PJ, VJ:  Print-Job, Validate-Job
   PU:  Print-URI
   CJ:  Create-Job
   GPA:  Get-Printer-Attributes
   GJ:  Get-Jobs
   PP, RP, PP:  Pause-Printer, Resume-Printer, Purge-Printer
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).
   +  indicates that this is not an IPP/1.0 feature, but is only a part
      of IPP/1.1 and future versions of IPP.
   *  "job-id" is REQUIRED only if used together with "printer-uri" to
      identify the target job; otherwise, "job-uri" is REQUIRED.
   ** "document-access-error" applies to the Print-URI response only.

Top      ToC       Page 12 
   Table 3 - Summary of Job operation attributes that sender MUST supply

Job Operations

                        Requests                              Responses
   Operation            SD     SU      CJ      GJA    HJ      All
   Attributes           (O)    (O)     (R)     (R)    RJ, RJ Opera-
                                                      (O+)   tions

   Operation parameters--REQUIRED to be supplied by the sender:

   operation-id         R      R       R       R      R

   status-code                                                R

   request-id           R      R       R       R      R       R

   version-number       R      R       R       R      R       R

   Operation attributes--REQUIRED to be supplied by the sender:

   attributes-charset   R      R       R       R      R       R

   attributes-natural-  R      R       R       R      R       R
     language

   document-uri                R

   job-id*              R      R       R       R      R

   job-uri*             R      R       R       R      R

   last-document        R      R

   printer-uri          R      R       R       R      R

   Operation attributes--RECOMMENDED to be supplied by the sender:

   job-name

Top      ToC       Page 13 
Job Operations

                        Requests                              Responses

   Operation            SD     SU      CJ      GJA    HJ      All
   Attributes           (O)    (O)     (R)     (R)    RJ, RJ  Opera-
                                                      (O+)    tions

   requesting-user-     R      R       R       R      R
     name

   Legend:

   SD:  Send-Document
   SU:  Send-URI
   CJ:  Cancel-Job
   GJA:  Get-Job-Attributes
   HJ, RJ, RJ:  Hold-Job, Release-Job, Restart-Job
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).
   +  indicates that this is not an IPP/1.0 feature, but is only a part
      of IPP/1.1 and future versions of IPP.
   *  "job-id" is REQUIRED only if used together with "printer-uri" to
      identify the target job; otherwise, "job-uri" is REQUIRED.

Top      ToC       Page 14 
   Table 4 - Summary of Job operation attributes that sender MAY supply

Job Operations

                      Requests                                 Responses

   Operation          SD     SU     CJ     GJA    HJ,    SD    All
   Attributes         (O)    (O)    (R)    (R)    RJ,    (O)   Opera-
                                                  RJ           tions
                                                  (O+)

   Operation attributes--OPTIONAL to be supplied by the sender:

   status-message                                                O

   detailed-status-                                              O
     message

   document-access-                                              O**
     error

   compression        R      R

   document-format    R      R

   document-name      O      O

   document-natural-  O      O
     language

   ipp-attribute-
     fidelity

   job-impressions

   job-k-octets

   job-media-sheets

Top      ToC       Page 15 
Job Operations

                      Requests                                 Responses

   Operation          SD     SU     CJ     GJA    HJ,    SD    All
   Attributes         (O)    (O)    (R)    (R)    RJ,    (O)   Opera-
                                                  RJ           tions
                                                  (O+)

   limit

   message                          O             O      O

   job-hold-until                                 R

   my-jobs

   requested-                              R
     attributes

   which-jobs

   Legend:

   SD:  Send-Document
   SU:  Send-URI
   CJ:  Cancel-Job
   GJA:  Get-Job-Attributes
   HJ, RJ, RJ:  Hold-Job, Release-Job, Restart-Job
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).
   +  indicates that this is not an IPP/1.0 feature, but is only a part
      of IPP/1.1 and future versions of IPP.
   *  "job-id" is REQUIRED only if used together with "printer-uri" to
      identify the target job; otherwise, "job-uri" is REQUIRED.
   ** "document-access-error" applies to the Send-URI operation only

Top      ToC       Page 16 
              Table 5 - Printer operation response attributes

Printer Operations

                  Response

   Operation       PJ (R)  VJ (R) PU (O)  CJ (O)  GPA     GJ (R) PP,
   Attributes      SD (O)         SU (O)          (R)            RP, PP
                                                                 (O+)

   job-uri         R              R       R

   job-id          R              R       R

   job-state       R              R       R

   job-state-      R+             R+      R+
     reasons

   number-of-      O              O       O
     intervening-
     jobs

   document-                      O
     access-
     error+

   Legend:

   PJ, SJ:  Print-Job, Send-Document
   VJ:  Validate-Job
   PU, SU:  Print-URI, Send-URI
   CJ:  Create-Job
   GPA:  Get-Printer-Attributes
   GJ:  Get-Jobs
   PP, RP, PP:  Pause-Printer, Resume-Printer, Purge-Printer
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).

3.1.2  Suggested Operation Processing Steps for IPP Objects

   This section suggests the steps and error checks that an IPP object
   MAY perform when processing requests and returning responses.  An IPP
   object MAY perform some or all of the error checks.  However, some

Top      ToC       Page 17 
   implementations MAY choose to be more forgiving than the error checks
   shown here, in order to be able to accept requests from non-
   conforming clients.  Not performing all of these error checks is a
   so-called "forgiving" implementation.  On the other hand, clients
   that successfully submit requests to IPP objects that do perform all
   the error checks will be more likely to be able to interoperate with
   other IPP object implementations.  Thus an implementer of an IPP
   object needs to decide whether to be a "forgiving" or a "strict"
   implementation.  Therefore, the error status codes returned may
   differ between implementations.  Consequentially, client SHOULD NOT
   expect exactly the error code processing described in this section.

   When an IPP object receives a request, the IPP object either accepts
   or rejects the request. In order to determine whether or not to
   accept or reject the request, the IPP object SHOULD execute the
   following steps.  The order of the steps may be rearranged and/or
   combined, including making one or multiple passes over the request.

   A client MUST supply requests that would pass all of the error checks
   indicated here in order to be a conforming client.  Therefore, a
   client SHOULD supply requests that are conforming, in order to avoid
   being rejected by some IPP object implementations and/or risking
   different semantics by different implementations of forgiving
   implementations.  For example, a forgiving implementation that
   accepts multiple occurrences of the same attribute, rather than
   rejecting the request might use the first occurrences, while another
   might use the last occurrence.  Thus such a non-conforming client
   would get different results from the two forgiving implementations.

   In the following, processing continues step by step until a "RETURNS
   the xxx status code ..." statement is encountered.  Error returns are
   indicated by the verb: "REJECTS".  Since clients have difficulty
   getting the status code before sending all of the document data in a
   Print-Job request, clients SHOULD use the Validate-Job operation
   before sending large documents to be printed, in order to validate
   whether the IPP Printer will accept the job or not.

   It is assumed that security authentication and authorization has
   already taken place at a lower layer.



(page 17 continued on part 2)

Next RFC Part