Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3196

Internet Printing Protocol/1.1: Implementor's Guide

Pages: 96
Informational
Errata
Obsoletes:  2639
Part 1 of 5 – Pages 1 to 17
None   None   Next

Top   ToC   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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   RFC3196 - 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 Section