GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3196

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

Hastings, et al. Informational [Page 1] RFC 3196 Internet Printing Protocol/1.1 November 2001

 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

Hastings, et al. Informational [Page 2] RFC 3196 Internet Printing Protocol/1.1 November 2001

 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

Hastings, et al. Informational [Page 3] RFC 3196 Internet Printing Protocol/1.1 November 2001

 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]

Hastings, et al. Informational [Page 4] RFC 3196 Internet Printing Protocol/1.1 November 2001

    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.

Hastings, et al. Informational [Page 5] RFC 3196 Internet Printing Protocol/1.1 November 2001

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

Hastings, et al. Informational [Page 6] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 7] RFC 3196 Internet Printing Protocol/1.1 November 2001

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*

Hastings, et al. Informational [Page 8] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 9] RFC 3196 Internet Printing Protocol/1.1 November 2001

   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

Hastings, et al. Informational [Page 10] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 11] RFC 3196 Internet Printing Protocol/1.1 November 2001

 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

Hastings, et al. Informational [Page 12] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 13] RFC 3196 Internet Printing Protocol/1.1 November 2001

 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

Hastings, et al. Informational [Page 14] RFC 3196 Internet Printing Protocol/1.1 November 2001

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

Hastings, et al. Informational [Page 15] RFC 3196 Internet Printing Protocol/1.1 November 2001

            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

Hastings, et al. Informational [Page 16] RFC 3196 Internet Printing Protocol/1.1 November 2001

 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.

3.1.2.1 Suggested Operation Processing Steps for all Operations

 This section is intended to apply to all operations.  The next
 section contains the additional steps for the Print-Job, Validate-
 Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
 that create jobs, adds documents, and validates jobs.

Hastings, et al. Informational [Page 17] RFC 3196 Internet Printing Protocol/1.1 November 2001

 IIG Sect #         Flow                 IPP error status codes
 ----------         ----                 ----------------------
                      |
                      v          err
 3.1.2.1.1   <Validate version>  --> server-error-version-not-
                                     supported
                    ok|
                      v          err
 3.1.2.1.2  <Validate operation> --> server-error-operation-not-
                                     supported
                    ok|
                      v          err
 3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
 3.1.2.1.4.2    <of attributes>
                    ok|
                      v          err
 3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
             <of operation attr>
                    ok|
                      v          err
 3.1.2.1.5  <Validate values of> --> client-error-bad-request
             <operation attrs>       client-error-request-value-
                                     too-long
           <(length, tag, range,>
               <multi-value)>
                    ok|
                      v          err
 3.1.2.1.5    <Validate values>  --> client-error-bad-request
           <with supported values>   client-error-charset-not-
                                     supported
                    ok|              client-error-attributes-or-
                                     values-
                      |                           not-supported
                      v          err
 3.1.2.1.6 <Validate optionally> --> client-error-bad-request
              <operation attr>       client-error-natural-language-
                                     not-supported
                      |              client-error-request-value-
                                     too-long
                      |              client-error-attributes-or-
                                     values-not-supported

3.1.2.1.1 Validate version number

 Every request and every response contains the "version-number"
 attribute.  The value of this attribute is the major and minor
 version number of the syntax and semantics that the client and IPP
 object is using, respectively.  The "version-number" attribute

Hastings, et al. Informational [Page 18] RFC 3196 Internet Printing Protocol/1.1 November 2001

 remains in a fixed position across all future versions so that all
 clients and IPP object that support future versions can determine
 which version is being used.  The IPP object checks to see if the
 major version number supplied in the request is supported.  If not,
 the Printer object REJECTS the request and RETURNS the 'server-
 error-version-not-supported' status code in the response.  The IPP
 object returns in the "version-number" response attribute the major
 and minor version for the error response.  Thus the client can learn
 at least one major and minor version that the IPP object supports.
 The IPP object is encouraged to return the closest version number to
 the one supplied by the client.
 The checking of the minor version number is implementation dependent,
 however if the client-supplied minor version is explicitly supported,
 the IPP object MUST respond using that identical minor version
 number.  If the major version number matches, but the minor version
 number does not, the Printer SHOULD accept and attempt to process the
 request, or MAY reject the request and return the 'server-error-
 version-not-supported' status code.  In all cases, the Printer MUST
 return the nearest version number that it supports.  For example,
 suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
 The following responses are conforming:
             Table 6 - Examples of validating IPP version
    Client supplies   Printer Accept Request?   Printer returns
    1.0               yes (SHOULD)              1.1
    1.0               no (SHOULD NOT)           1.1
    1.1               yes (MUST)                1.1
    1.2               yes (MUST)                1.2
    1.3               yes (SHOULD)              1.2
    1.3               no (SHOULD NOT)           1.2
 It is advantageous for Printers to support both IPP/1.1 and IPP/1.0,
 so that they can interoperate with either client implementations.
 Some implementations may allow an Administrator to explicitly disable
 support for one or the other by setting the "ipp-versions-supported"
 Printer description attribute.

Hastings, et al. Informational [Page 19] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Likewise, it is advantageous for clients to support both versions to
 allow interoperability with new and legacy Printers.

3.1.2.1.2 Validate operation identifier

 The Printer object checks to see if the "operation-id" attribute
 supplied by the client is supported as indicated in the Printer
 object's "operations-supported" attribute.  If not, the Printer
 REJECTS the request and returns the 'server-error-operation-not-
 supported' status code in the response.

3.1.2.1.3 Validate the request identifier

 The Printer object SHOULD NOT check to see if the "request-id"
 attribute supplied by the client is in range: between 1 and 2**31 - 1
 (inclusive), but copies all 32 bits.
 Note: The "version-number", "operation-id", and the "request-id"
 parameters are in fixed octet positions in the IPP/1.1 encoding.  The
 "version-number" parameter will be the same fixed octet position in
 all versions of the protocol.  These fields are validated before
 proceeding with the rest of the validation.

3.1.2.1.4 Validate attribute group and attribute presence and order

 The order of the following validation steps depends on
 implementation.

3.1.2.1.4.1 Validate the presence and order of attribute groups

 Client requests and IPP object responses contain attribute groups
 that Section 3 requires to be present and in a specified order.  An
 IPP object verifies that the attribute groups are present and in the
 correct order in requests supplied by clients (attribute groups
 without an * in the following tables).
 If an IPP object receives a request with (1) required attribute
 groups missing, or (2) the attributes groups are out of order, or (3)
 the groups are repeated, the IPP object REJECTS the request and
 RETURNS the 'client-error-bad-request' status code.  For example, it
 is an error for the Job Template Attributes group to occur before the
 Operation Attributes group, for the Operation Attributes group to be
 omitted, or for an attribute group to occur more than once, except in
 the Get-Jobs response.
 Since this kind of attribute group error is most likely to be an
 error detected by a client developer rather than by a customer, the
 IPP object NEED NOT return an indication of which attribute group was

Hastings, et al. Informational [Page 20] RFC 3196 Internet Printing Protocol/1.1 November 2001

 in error in either the Unsupported Attributes group or the Status
 Message.  Also, the IPP object NEED NOT find all attribute group
 errors before returning this error.

3.1.2.1.4.2 Ignore unknown attribute groups in the expected position

 Future attribute groups may be added to the specification at the end
 of requests just before the Document Content and at the end of
 response, except for the Get-Jobs response, where it maybe there or
 before the first job attributes returned.  If an IPP object receives
 an unknown attribute group in these positions, it ignores the entire
 group, rather than returning an error, since that group may be a new
 group in a later minor version of the protocol that can be ignored.
 (If the new attribute group cannot be ignored without confusing the
 client, the major version number would have been increased in the
 protocol document and in the request).  If the unknown group occurs
 in a different position, the IPP object REJECTS the request and
 RETURNS the 'client-error-bad-request' status code.
 Clients also ignore unknown attribute groups returned in a response.
 Note:  By validating that requests are in the proper form, IPP
 objects force clients to use the proper form which, in turn,
 increases the chances that customers will be able to use such clients
 from multiple vendors with IPP objects from other vendors.

3.1.2.1.4.3 Validate the presence of a single occurrence of required

            Operation attributes
 Client requests and IPP object responses contain Operation attributes
 that [RFC2911] Section 3 requires to be present.  Attributes within a
 group may be in any order, except for the ordering of target,
 charset, and natural languages attributes.  These attributes MUST be
 first, and MUST be supplied in the following order: charset, natural
 language, and then target.  An IPP object verifies that the
 attributes that Section 4 requires to be supplied by the client have
 been supplied in the request (attributes without an * in the
 following tables).  An asterisk (*) indicates groups and Operation
 attributes that the client may omit in a request or an IPP object may
 omit in a response.
 If an IPP object receives a request with required attributes missing
 or repeated from a group or in the wrong position, the behavior of
 the IPP object is IMPLEMENTATION DEPENDENT.  Some of the possible
 implementations are:
    REJECTS the request and RETURNS the 'client-error-bad-request'
    status code

Hastings, et al. Informational [Page 21] RFC 3196 Internet Printing Protocol/1.1 November 2001

    accepts the request and uses the first occurrence of the attribute
    no matter where it is
    accepts the request and uses the last occurrence of the attribute
    no matter where it is
    accept the request and assume some default value for the missing
    attribute
 Therefore, client MUST send conforming requests, if they want to
 receive the same behavior from all IPP object implementations.  For
 example, it is an error for the "attributes-charset" or "attributes-
 natural-language" attribute to be omitted in any operation request,
 or for an Operation attribute to be supplied in a Job Template group
 or a Job Template attribute to be supplied in an Operation Attribute
 group in a create request.  It is also an error to supply the
 "attributes-charset" attribute twice.
 Since these kinds of attribute errors are most likely to be detected
 by a client developer rather than by a customer, the IPP object NEED
 NOT return an indication of which attribute was in error in either
 the Unsupported Attributes group or the Status Message.  Also, the
 IPP object NEED NOT find all attribute errors before returning this
 error.
 The following tables list all the attributes for all the operations
 by attribute group in each request and each response.  The order of
 the groups is the order that the client supplies the groups as
 specified in [RFC2911] Section 3.  The order of the attributes within
 a group is arbitrary, except as noted for some of the special
 operation attributes (charset, natural language, and target).  The
 tables below use the following notation:
    R     indicates a REQUIRED attribute or operation that an IPP
          object MUST support
    O     indicates an OPTIONAL attribute or operation that an IPP
          object NEED NOT support
    *     indicates that a client MAY omit the attribute in a request
          and that an IPP object MAY omit the attribute in a response.
          The absence of an * means that a client MUST supply the
          attribute in a request and an IPP object MUST supply the
          attribute in a response.
    +     indicates that this is not a IPP/1.0 operation, but is only
          a part of IPP/1.1 and future versions of IPP.

Hastings, et al. Informational [Page 22] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Operation Requests
 The tables below show the attributes in their proper attribute groups
 for operation requests:
 Note: All operation requests contain "version-number", "operation-
 id", and "request-id" parameters.
 Print-Job Request (R):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        printer-uri (R)
        requesting-user-name (R*)
        job-name (R*)
        ipp-attribute-fidelity (R*)
        document-name (R*)
        document-format (R*)
        document-natural-language (O*)
        compression (R*)
        job-k-octets (O*)
        job-impressions (O*)
        job-media-sheets (O*)
   Group 2: Job Template Attributes (R*)
        <Job Template attributes> (O*)
             (see [RFC2911] Section 4.2)
   Group 3: Document Content (R)
        <document content>
 Validate-Job Request (R):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        printer-uri (R)
        requesting-user-name (R*)
        job-name (R*)
        ipp-attribute-fidelity (R*)
        document-name (R*)
        document-format (R*)
        document-natural-language (O*)
        compression (R*)
        job-k-octets (O*)
        job-impressions (O*)
        job-media-sheets (O*)
   Group 2: Job Template Attributes (R*)
        <Job Template attributes> (O*)
             (see [RFC2911] Section 4.2)

Hastings, et al. Informational [Page 23] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Print-URI Request (O):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        printer-uri (R)
        document-uri (R)
        requesting-user-name (R*)
        job-name (R*)
        ipp-attribute-fidelity (R*)
        document-name (R*)
        document-format (R*)
        document-natural-language (O*)
        compression (R*)
        job-k-octets (O*)
        job-impressions (O*)
        job-media-sheets (O*)
   Group 2: Job Template Attributes (R*)
        <Job Template attributes> (O*) (see
             (see [RFC2911] Section 4.2)
 Create-Job Request (O):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        printer-uri (R)
        requesting-user-name (R*)
        job-name (R*)
        ipp-attribute-fidelity (R*)
        job-k-octets (O*)
        job-impressions (O*)
        job-media-sheets (O*)
   Group 2: Job Template Attributes (R*)
        <Job Template attributes> (O*) (see
             (see [RFC2911] Section 4.2)
 Get-Printer-Attributes Request (R):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        printer-uri (R)
        requesting-user-name (R*)
        requested-attributes (R*)
        document-format (R*)
 Get-Jobs Request (R):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)

Hastings, et al. Informational [Page 24] RFC 3196 Internet Printing Protocol/1.1 November 2001

        printer-uri (R)
        requesting-user-name (R*)
        limit (R*)
        requested-attributes (R*)
        which-jobs (R*)
        my-jobs (R*)
 Send-Document Request (O):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        (printer-uri & job-id) | job-uri (R)
        last-document (R)
        requesting-user-name (R*)
        document-name (R*)
        document-format (R*)
        document-natural-language (O*)
        compression (R*)
   Group 2: Document Content (R*)
        <document content>
 Send-URI Request (O):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        (printer-uri & job-id) | job-uri (R)
        last-document (R)
        document-uri (R)
        requesting-user-name (R*)
        document-name (R*)
        document-format (R*)
        document-natural-language (O*)
        compression (R*)
 Cancel-Job Request (R):
 Release-Job Request (O+):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        (printer-uri & job-id) | job-uri (R)
        requesting-user-name (R*)
        message (O*)

Hastings, et al. Informational [Page 25] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Get-Job-Attributes Request (R):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        (printer-uri & job-id) | job-uri (R)
        requesting-user-name (R*)
        requested-attributes (R*)
 Pause-Printer Request (O+):
 Resume-Printer Request (O+):
 Purge-Printer Request (O+):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        printer-uri (R)
        requesting-user-name (R*)
 Hold-Job Request (O+):
 Restart-Job Request (O+):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        (printer-uri & job-id) | job-uri (R)
        requesting-user-name (R*)
        job-hold-until (R*)
        message (O*)
 Operation Responses
 The tables below show the response attributes in their proper
 attribute groups for responses.
 Note: All operation responses contain "version-number", "status-
 code", and "request-id" parameters.
 Print-Job Response (R):
 Create-Job Response (O):
 Send-Document Response (O):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        status-message (O*)
        detailed-status-message (O*)
   Group 2: Unsupported Attributes (R*) (see Note 3)
    n    <unsupported attributes> (R*)
   Group 3: Job Object Attributes(R*) (see Note 2)
        job-uri (R)
        job-id (R)

Hastings, et al. Informational [Page 26] RFC 3196 Internet Printing Protocol/1.1 November 2001

        job-state (R)
        job-state-reasons (O* | R+)
        job-state-message (O*)
        number-of-intervening-jobs (O*)
 Validate-Job Response (R):
 Cancel-Job Response (R):
 Hold-Job Response (O+):
 Release-Job Response (O+):
 Restart-Job Response (O+):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        status-message (O*)
        detailed-status-message (O*)
   Group 2: Unsupported Attributes (R*) (see Note 3)
        <unsupported attributes> (R*)
 Print-URI Response (O):
 Send-URI Response (O):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        status-message (O*)
        detailed-status-message (O*)
        document-access-error (O*)
   Group 2: Unsupported Attributes (R*) (see Note 3)
        <unsupported attributes> (R*)
   Group 3: Job Object Attributes(R*) (see Note 2)
        job-uri (R)
        job-id (R)
        job-state (R)
        job-state-reasons (O* | R+)
        job-state-message (O*)
        number-of-intervening-jobs (O*)
 Get-Printer-Attributes Response (R):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        status-message (O*)
        detailed-status-message (O*)
   Group 2: Unsupported Attributes (R*) (see Note 4)
        <unsupported attributes> (R*)
   Group 3: Printer Object Attributes(R*) (see Note 2)
        <requested attributes> (R*)

Hastings, et al. Informational [Page 27] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Get-Jobs Response (R):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        status-message (O*)
        detailed-status-message (O*)
   Group 2: Unsupported Attributes (R*) (see Note 4)
        <unsupported attributes> (R*)
   Group 3: Job Object Attributes(R*) (see Note 2, 5)
        <requested attributes> (R*)
 Get-Job-Attributes Response (R):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        status-message (O*)
        detailed-status-message (O*)
   Group 2: Unsupported Attributes (R*) (see Note 4)
        <unsupported attributes> (R*)
   Group 3: Job Object Attributes(R*) (see Note 2)
        <requested attributes> (R*)
 Pause-Printer Response (O+):
 Resume-Printer Response (O+):
 Purge-Printer Response (O+):
   Group 1: Operation Attributes (R)
        attributes-charset (R)
        attributes-natural-language (R)
        status-message (O*)
        detailed-status-message (O*)
   Group 2: Unsupported Attributes (R*) (see Note 4)
        <unsupported attributes> (R*)
 Note 2 - the Job Object Attributes and Printer Object Attributes are
 returned only if the IPP object returns one of the success status
 codes.
 Note 3 - the Unsupported Attributes Group is present only if the
 client included some Operation and/or Job Template attributes or
 values that the Printer doesn't support whether a success or an error
 return.
 Note 4 - the Unsupported Attributes Group is present only if the
 client included some Operation attributes that the Printer doesn't
 support whether a success or an error return.

Hastings, et al. Informational [Page 28] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Note 5:  for the Get-Jobs operation the response contains a separate
 Job Object Attributes group 3 to N containing requested-attributes
 for each job object in the response.

3.1.2.1.5 Validate the values of the REQUIRED Operation attributes

 An IPP object validates the values supplied by the client of the
 REQUIRED Operation attribute that the IPP object MUST support.  The
 next section specifies the validation of the values of the OPTIONAL
 Operation attributes that IPP objects MAY support.
 The IPP object performs the following syntactic validation checks of
 each Operation attribute value:
    a) that the length of each Operation attribute value is correct
       for the attribute syntax tag supplied by the client according
       to [RFC2911] Section 4.1,
    b) that the attribute syntax tag is correct for that Operation
       attribute according to [RFC2911] Section 3,
    c) that the value is in the range specified for that Operation
       attribute according to [RFC2911] Section 3,
    d) that multiple values are supplied by the client only for
       operation attributes that are multi-valued, i.e., that are
       1setOf X according to [RFC2911] Section 3.
 If any of these checks fail, the IPP object REJECTS the request and
 RETURNS the 'client-error-bad-request' or the 'client-error-request-
 value-too-long' status code.  Since such an error is most likely to
 be an error detected by a client developer, rather than by an end-
 user, the IPP object NEED NOT return an indication of which attribute
 had the error in either the Unsupported Attributes Group or the
 Status Message.  The description for each of these syntactic checks
 is explicitly expressed in the first IF statement in the following
 table.
 In addition, the IPP object checks each Operation attribute value
 against some Printer object attribute or some hard-coded value if
 there is no "xxx-supported" Printer object attribute defined.  If its
 value is not among those supported or is not in the range supported,
 then the IPP object REJECTS the request and RETURNS the error status
 code indicated in the table by the second IF statement.  If the value
 of the Printer object's "xxx-supported" attribute is 'no-value'
 (because the system administrator hasn't configured a value), the
 check always fails.

Hastings, et al. Informational [Page 29] RFC 3196 Internet Printing Protocol/1.1 November 2001

  1. ———————————————-
 attributes-charset (charset)
    IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
    error-bad-request'.
    IF the value length is greater than 63 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT in the Printer object's "charset-supported" attribute,
    REJECT/RETURN "client-error-charset-not-supported".
 attributes-natural-language(naturalLanguage)
    IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
    'client-error-bad-request'.
    IF the value length is greater than 63 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    ACCEPT the request even if not a member of the set in the Printer
    object's "generated-natural-language-supported" attribute.  If the
    supplied value is not a member of the Printer object's
    "generated-natural-language-supported" attribute, use the Printer
    object's "natural-language- configured" value.
 requesting-user-name
    IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
    request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF the IPP object can obtain a better-authenticated name, use it
    instead.
 job-name(name)
    IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
    request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT supplied by the client, the Printer object creates a name
    from the document-name or document-uri.

Hastings, et al. Informational [Page 30] RFC 3196 Internet Printing Protocol/1.1 November 2001

 document-name (name)
    IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
    request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
 ipp-attribute-fidelity (boolean)
    IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
    REJECT/RETURN 'client-error-bad-request'.
    IF the value length is NOT equal to 1 octet, REJECT/RETURN
    'client-error-request-value-too-long'
    IF NOT supplied by the client, the IPP object assumes the value
    'false'.
 document-format (mimeMediaType)
    IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
    'client-error-bad-request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT in the Printer object's "document-format-supported"
    attribute, REJECT/RETURN 'client-error-document-format-not-
    supported'
    IF NOT supplied by the client, the IPP object assumes the value of
    the Printer object's "document-format-default" attribute.
 document-uri (uri)
    IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
    error-bad-request'.
    IF the value length is greater than 1023 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
    request'.
    If the client-supplied URI scheme is not supported, i.e., the
    value is not in the Printer object's referenced-uri-scheme-
    supported" attribute, the Printer object MUST reject the request

Hastings, et al. Informational [Page 31] RFC 3196 Internet Printing Protocol/1.1 November 2001

    and return the 'client-error-uri-scheme-not-supported' status
    code. The Printer object MAY check to see if the document exists
    and is accessible.  If the document is not found or is not
    accessible, REJECT/RETURN 'client-error-not found'.
 last-document (boolean)
    IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
    REJECT/RETURN 'client-error-bad-request'.
    IF the value length is NOT equal to 1 octet, REJECT/RETURN
    'client-error-request-value-too-long'
 job-id (integer(1:MAX))
    IF NOT an single 'integer' value equal to 4 octets AND in the
    range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
    IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
    error-not-found' or 'client-error-gone' status code, if keep track
    of recently deleted jobs.
 requested-attributes (1setOf keyword)
    IF NOT one or more 'keyword' values, REJECT/RETURN 'client-
    error-bad-request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    Ignore unsupported values, which are the keyword names of
    unsupported attributes.  Don't bother to copy such requested
    (unsupported) attributes to the Unsupported Attribute response
    group since the response will not return them.
 which-jobs (type2 keyword)
    IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
    request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
    the unsupported value to the Unsupported Attributes response group
    and REJECT/RETURN 'client-error-attributes-or-values-not-
    supported'.

Hastings, et al. Informational [Page 32] RFC 3196 Internet Printing Protocol/1.1 November 2001

    Note: a Printer still supports the 'completed' value even if it
    keeps no completed/canceled/aborted jobs:  by returning no jobs
    when so queried.
    IF NOT supplied by the client, the IPP object assumes the 'not-
    completed' value.
 my-jobs (boolean)
    IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
    REJECT/RETURN 'client-error-bad-request'.
    IF the value length is NOT equal to 1 octet, REJECT/RETURN
    'client-error-request-value-too-long'
    IF NOT supplied by the client, the IPP object assumes the 'false'
    value.
 limit (integer(1:MAX))
    IF NOT a single 'integer' value equal to 4 octets AND in the range
    1 to MAX, REJECT/RETURN 'client-error-bad-request'.
    IF NOT supplied by the client, the IPP object returns all jobs, no
    matter how many.
  1. ———————————————-

3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes

 OPTIONAL Operation attributes are those that an IPP object MAY
 support.  An IPP object validates the values of the OPTIONAL
 attributes supplied by the client.  The IPP object performs the same
 syntactic validation checks for each OPTIONAL attribute value as in
 Section 3.1.2.1.5.  As in Section 3.1.2.1.5, if any fail, the IPP
 object REJECTS the request and RETURNS the 'client-error-bad-request'
 or the 'client-error-request-value-too-long' status code.
 In addition, the IPP object checks each Operation attribute value
 against some Printer attribute or some hard-coded value if there is
 no "xxx-supported" Printer attribute defined.  If its value is not
 among those supported or is not in the range supported, then the IPP
 object REJECTS the request and RETURNS the error status code
 indicated in the table.  If the value of the Printer object's "xxx-
 supported" attribute is 'no-value' (because the system administrator
 hasn't configured a value), the check always fails.

Hastings, et al. Informational [Page 33] RFC 3196 Internet Printing Protocol/1.1 November 2001

 If the IPP object doesn't recognize/support an attribute, the IPP
 object treats the attribute as an unknown or unsupported attribute
 (see the last row in the table below).
  1. ———————————————-
 document-natural-language (naturalLanguage)
    IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
    'client-error-bad-request'.
    IF the value length is greater than 63 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT a value that the Printer object supports in document
    formats, (no corresponding "xxx-supported" Printer attribute),
    REJECT/RETURN 'client-error-natural-language-not-supported'.
 compression (type3 keyword)
    IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
    request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT in the Printer object's "compression-supported" attribute,
    REJECT/RETURN 'client-error-compression-not-supported'.
    Note to IPP/1.0 implementers:  Support for the "compression"
    attribute was optional in IPP/1.0 and was changed to REQUIRED in
    IPP/1.1.  However, an IPP/1.0 object SHOULD at least check for the
    "compression" attribute being present and reject the create
    request, if they don't support "compression".  Not checking is a
    bug, since the data will be unintelligible.
 job-k-octets (integer(0:MAX))
    IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
    'client-error-bad-request'.
    IF NOT in the range of the Printer object's "job-k-octets-
    supported" attribute, copy the attribute and the unsupported value
    to the Unsupported Attributes response group and REJECT/RETURN
    'client-error-attributes-or-values-not-supported'.

Hastings, et al. Informational [Page 34] RFC 3196 Internet Printing Protocol/1.1 November 2001

 job-impressions (integer(0:MAX))
    IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
    'client-error-bad-request'.
    IF NOT in the range of the Printer object's "job-impressions-
    supported" attribute, copy the attribute and the unsupported value
    to the Unsupported Attributes response group and REJECT/RETURN
    'client-error-attributes-or-values-not-supported'.
 job-media-sheets (integer(0:MAX))
    IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
    'client-error-bad-request'.
    IF NOT in the range of the Printer object's "job-media-sheets-
    supported" attribute, copy the attribute and the unsupported value
    to the Unsupported Attributes response group and REJECT/RETURN
    'client-error-attributes-or-values-not-supported'.
 message (text(127))
    IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
    request'.
    IF the value length is greater than 127 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
 unknown or unsupported attribute
    IF the attribute syntax supplied by the client is supported but
    the length is not legal for that attribute syntax, REJECT/RETURN
    'client-error-request-value-too-long'.
    ELSE copy the attribute and value to the Unsupported Attributes
    response group and change the attribute value to the "out-of-band"
    'unsupported' value, but otherwise ignore the attribute.
 Note: Future Operation attributes may be added to the protocol
 specification that may occur anywhere in the specified group.  When
 the operation is otherwise successful, the IPP object returns the
 'successful-ok-ignored-or-substituted-attributes' status code.
 Ignoring unsupported Operation attributes in all operations is
 analogous to the handling of unsupported Job Template attributes in
 the create and Validate-Job operations when the client supplies the
 "ipp-attribute-fidelity" Operation attribute with the 'false' value.
 This last rule is so that we can add OPTIONAL Operation attributes to
 future versions of IPP so that older clients can inter-work with new

Hastings, et al. Informational [Page 35] RFC 3196 Internet Printing Protocol/1.1 November 2001

 IPP objects and newer clients can inter-work with older IPP objects.
 (If the new attribute cannot be ignored without performing
 unexpectedly, the major version number would have been increased in
 the protocol document and in the request).  This rule for Operation
 attributes is independent of the value of the "ipp-attribute-
 fidelity" attribute.  For example, if an IPP object doesn't support
 the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-
 k-octets" as an unknown attribute and only checks the length for the
 'integer' attribute syntax supplied by the client.  If it is not four
 octets, the IPP object REJECTS the request and RETURNS the 'client-
 error-bad-request' status code, else the IPP object copies the
 attribute to the Unsupported Attribute response group, setting the
 value to the "out-of-band" 'unsupported' value, but otherwise ignores
 the attribute.

Hastings, et al. Informational [Page 36] RFC 3196 Internet Printing Protocol/1.1 November 2001

3.1.2.2 Suggested Additional Processing Steps for Operations that

      Create/Validate Jobs and Add Documents
 This section in combination with the previous section recommends the
 processing steps for the Print-Job, Validate-Job, Print-URI, Create-
 Job, Send-Document, and Send-URI operations that IPP objects SHOULD
 use.  These are the operations that create jobs, validate a Print-Job
 request, and add documents to a job.
 IIG Sect #         Flow                 IPP error status codes
 ----------         ----                 ----------------------
                      |
                      v             No
 3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
                <supplied?>                           |
                   Yes|                               |
                      |  ipp-attribute-fidelity = no  |
                      |<------------------------------+
                      v          No
 3.1.2.2.2       <Printer is>    --> server-error-not-accepting-jobs
              <accepting jobs?>
                   Yes|
                      v          err
 3.1.2.3    <Validate values of> --> client-error-bad-request
         <Job template attributes>   client-error-request-value-too-
                                     long
          <(length, tag, range,>
               <multi-value)>
                    ok|
                      v          err
 3.1.2.3  <Validate values with> --> client-error-bad-request
           <supported values>        client-error-attributes-or-
                      |              values-not-supported
                      v          err
 3.1.2.3.1   <Any conflicting>   --> client-error-conflicting-
                                     attributes
        <Job Template attr values>   client-error-attributes-or-
                                     values-not-supported
                         v

3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied

 The Printer object checks to see if the client supplied an "ipp-
 attribute-fidelity" Operation attribute.  If the attribute is not
 supplied by the client, the IPP object assumes that the value is
 'false'.

Hastings, et al. Informational [Page 37] RFC 3196 Internet Printing Protocol/1.1 November 2001

3.1.2.2.2 Check that the Printer object is accepting jobs

 If the value of the Printer objects "printer-is-accepting-jobs" is
 'false', the Printer object REJECTS the request and RETURNS the
 'server-error-not-accepting-jobs' status code.

3.1.2.2.3 Validate the values of the Job Template attributes

 An IPP object validates the values of all Job Template attribute
 supplied by the client.  The IPP object performs the analogous
 syntactic validation checks of each Job Template attribute value that
 it performs for Operation attributes (see Section 3.1.2.1.5.):
    a) that the length of each value is correct for the attribute
       syntax tag supplied by the client according to [RFC2911]
       Section 4.1.
    b) that the attribute syntax tag is correct for that attribute
       according to [RFC2911] Sections 4.2 to 4.4.
    c) that multiple values are supplied only for multi-valued
       attributes, i.e., that are 1setOf  X according to [RFC2911]
       Sections 4.2 to 4.4.
 As in Section 3.1.2.1.5, if any of these syntactic checks fail, the
 IPP object REJECTS the request and RETURNS the 'client-error-bad-
 request' or 'client-error-request-value-too-long' status code as
 appropriate, independent of the value of the "ipp-attribute-
 fidelity".  Since such an error is most likely to be an error
 detected by a client developer, rather than by an end-user, the IPP
 object NEED NOT return an indication of which attribute had the error
 in either the Unsupported Attributes Group or the Status Message.
 The description for each of these syntactic checks is explicitly
 expressed in the first IF statement in the following table.
 Each Job Template attribute MUST occur no more than once.  If an IPP
 Printer receives a create request with multiple occurrences of a Job
 Template attribute, it MAY:
    1. reject the operation and return the 'client-error-bad-request'
       error status code
    2. accept the operation and use the first occurrence of the
       attribute
    3. accept the operation and use the last occurrence of the
       attribute

Hastings, et al. Informational [Page 38] RFC 3196 Internet Printing Protocol/1.1 November 2001

 depending on implementation.  Therefore, clients MUST NOT supply
 multiple occurrences of the same Job Template attribute in the Job
 Attributes group in the request.

3.1.2.3 Algorithm for job validation

 The process of validating a Job-Template attribute "xxx" against a
 Printer attribute "xxx-supported" can use the following validation
 algorithm (see section 3.2.1.2 in [RFC2911]).
 To validate the value U of Job-Template attribute "xxx" against the
 value V of Printer "xxx-supported", perform the following algorithm:
 1. If U is multi-valued, validate each value X of U by performing the
    algorithm in Table 7 with each value X. Each validation is
    separate from the standpoint of returning unsupported values.
    Example:  If U is "finishings" that the client supplies with
    'staple', 'bind' values, then X takes on the successive values:
    'staple', then 'bind'
 2. If V is multi-valued, validate X against each Z of V by performing
    the algorithm in Table 7 with each value Z.  If a value Z
    validates, the validation for the attribute value X succeeds. If
    it fails, the algorithm is applied to the next value Z of V. If
    there are no more values Z of V, validation fails. Example"  If V
    is "sides-supported" with values: 'one- sided', 'two-sided-long',
    and 'two-sided-short', then Z takes on the successive values:
    'one-sided', 'two-sided-long', and 'two-sided-short'.  If the
    client supplies "sides" with 'two-sided- long', the first
    comparison fails ('one-sided' is not equal to 'two-sided-long'),
    the second comparison succeeds ('two-sided-long' is equal to
    'two-sided-long"), and the third comparison ('two-sided-short'
    with 'two-sided-long') is not even performed.
 3. If both U and V are single-valued, let X be U and Z be V and use
    the validation rules in Table 7.

Hastings, et al. Informational [Page 39] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Table 7 - Rules for validating single values X against Z
 Attribute syntax   attribute syntax validated if:
 of X               of Z
 integer            rangeOfInteger   X is within the range of Z
 uri                uriScheme        the uri scheme in X is equal to
                                     Z
 any                boolean          the value of Z is TRUE
 any                any              X and Z are of the same type
                                     and are equal.
 If the value of the Printer object's "xxx-supported" attribute is
 'no-value' (because the system administrator hasn't configured a
 value), the check always fails.  If the check fails, the IPP object
 copies the attribute to the Unsupported Attributes response group
 with its unsupported value.  If the attribute contains more than one
 value, each value is checked and each unsupported value is separately
 copied, while supported values are not copied.  If an IPP object
 doesn't recognize/support a Job Template attribute, i.e., there is no
 corresponding Printer object "xxx-supported" attribute, the IPP
 object treats the attribute as an unknown or unsupported attribute
 (see the last row in the table below).
 If some Job Template attributes are supported for some document
 formats and not for others or the values are different for different
 document formats, the IPP object SHOULD take that into account in
 this validation using the value of the "document-format" supplied by
 the client (or defaulted to the value of the Printer's "document-
 format-default" attribute, if not supplied by the client).  For
 example, if "number-up" is supported for the 'text/plain' document
 format, but not for the 'application/postscript' document format, the
 check SHOULD (though it NEED NOT) depend on the value of the
 "document-format" operation attribute.  See "document-format" in
 [RFC2911] section 3.2.1.1 and 3.2.5.1.
 Note: whether the request is accepted or rejected is determined by
 the value of the "ipp-attribute-fidelity" attribute in a subsequent
 step, so that all Job Template attribute supplied are examined and
 all unsupported attributes and/or values are copied to the
 Unsupported Attributes response group.
  1. ———————————————-

Hastings, et al. Informational [Page 40] RFC 3196 Internet Printing Protocol/1.1 November 2001

 job-priority (integer(1:100))
    IF NOT a single 'integer' value with a length equal to 4 octets,
    REJECT/RETURN 'client-error-bad-request'.
    IF NOT supplied by the client, use the value of the Printer
    object's "job-priority-default" attribute at job submission time.
    IF NOT in the range 1 to 100, inclusive, copy the attribute and
    the unsupported value to the Unsupported Attributes response
    group.
    Map the value to the nearest supported value in the range 1:100 as
    specified by the number of discrete values indicated by the value
    of the Printer's "job-priority-supported" attribute.  See the
    formula in [RFC2911] Section 4.2.1.
 job-hold-until (type3 keyword | name)
    IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
    error-bad-request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT supplied by the client, use the value of the Printer
    object's "job-hold-until" attribute at job submission time.
    IF NOT in the Printer object's "job-hold-until-supported"
    attribute, copy the attribute and the unsupported value to the
    Unsupported Attributes response group.
 job-sheets (type3 keyword | name)
    IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
    error-bad-request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT in the Printer object's "job-sheets-supported" attribute,
    copy the attribute and the unsupported value to the Unsupported
    Attributes response group.
 multiple-document-handling (type2 keyword)
    IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
    request'.

Hastings, et al. Informational [Page 41] RFC 3196 Internet Printing Protocol/1.1 November 2001

    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT in the Printer object's "multiple-document-handling-
    supported" attribute, copy the attribute and the unsupported value
    to the Unsupported Attributes response group.
 copies (integer(1:MAX))
    IF NOT a single 'integer' value with a length equal to 4 octets,
    REJECT/RETURN 'client-error-bad-request'.
    IF NOT in range of the Printer object's "copies-supported"
    attribute
    copy the attribute and the unsupported value to the Unsupported
    Attributes response group.
 finishings (1setOf type2 enum)
    IF NOT an 'enum' value(s) each with a length equal to 4 octets,
    REJECT/RETURN 'client-error-bad-request'.
    IF NOT in the Printer object's "finishings-supported" attribute,
    copy the attribute and the unsupported value(s), but not any
    supported values, to the Unsupported Attributes response group.
 page-ranges (1setOf  rangeOfInteger(1:MAX))
    IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
    octets, REJECT/RETURN 'client-error-bad-request'.
    IF first value is greater than second value in any range, the
    ranges are not in ascending order, or ranges overlap,
    REJECT/RETURN 'client-error-bad-request'.
    IF the value of the Printer object's "page-ranges-supported"
    attribute is 'false', copy the attribute to the Unsupported
    Attributes response group and set the value to the "out-of-band"
    'unsupported' value.
 sides (type2 keyword)
    IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
    request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.

Hastings, et al. Informational [Page 42] RFC 3196 Internet Printing Protocol/1.1 November 2001

    IF NOT in the Printer object's "sides-supported" attribute, copy
    the attribute and the unsupported value to the Unsupported
    Attributes response group.
 number-up (integer(1:MAX))
    IF NOT a single 'integer' value with a length equal to 4 octets,
    REJECT/RETURN 'client-error-bad-request'.
    IF NOT a value or in the range of one of the values of the Printer
    object's "number-up-supported" attribute, copy the attribute and
    value to the Unsupported Attribute response group.
 orientation-requested (type2 enum)
    IF NOT a single 'enum' value with a length equal to 4 octets,
    REJECT/RETURN 'client-error-bad-request'.
    IF NOT in the Printer object's "orientation-requested-supported"
    attribute, copy the attribute and the unsupported value to the
    Unsupported Attributes response group.
 media (type3 keyword | name)
    IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
    error-bad-request'.
    IF the value length is greater than 255 octets, REJECT/RETURN
    'client-error-request-value-too-long'.
    IF NOT in the Printer object's "media-supported" attribute, copy
    the attribute and the unsupported value to the Unsupported
    Attributes response group.
 printer-resolution (resolution)
    IF NOT a single 'resolution' value with a length equal to 9
    octets, REJECT/RETURN 'client-error-bad-request'.
    IF NOT in the Printer object's "printer-resolution-supported"
    attribute, copy the attribute and the unsupported value to the
    Unsupported Attributes response group.
 print-quality (type2 enum)
    IF NOT a single 'enum' value with a length equal to 4 octets,
    REJECT/RETURN 'client-error-bad-request'.

Hastings, et al. Informational [Page 43] RFC 3196 Internet Printing Protocol/1.1 November 2001

    IF NOT in the Printer object's "print-quality-supported"
    attribute, copy the attribute and the unsupported value to the
    Unsupported Attributes response group.
    unknown or unsupported attribute (i.e., there is no corresponding
    Printer object "xxx-supported" attribute)
    IF the attribute syntax supplied by the client is supported but
    the length is not legal for that attribute syntax,
    REJECT/RETURN 'client-error-bad-request' if the length of the
    attribute syntax is fixed or 'client-error-request-value-too-long'
    if the length of the attribute syntax is variable.
    ELSE copy the attribute and value to the Unsupported Attributes
    response group and change the attribute value to the "out-of-band"
    'unsupported' value.  Any remaining Job Template Attributes are
    either unknown or unsupported Job Template attributes and are
    validated algorithmically according to their attribute syntax for
    proper length (see below).
  1. ———————————————-
    If the attribute syntax is supported AND the length check fails,
    the IPP object REJECTS the request and RETURNS the 'client-error-
    bad-request' if the length of the attribute syntax is fixed or the
    'client-error-request-value-too-long' status code if the length of
    the attribute syntax is variable. Otherwise, the IPP object copies
    the unsupported Job Template attribute to the Unsupported
    Attributes response group and changes the attribute value to the
    "out-of-band" 'unsupported' value.  The following table shows the
    length checks for all attribute syntaxes.  In the following table:
    "<=" means less than or equal, "=" means equal to:

Hastings, et al. Informational [Page 44] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Name                    Octet length check for read-write attributes
 ----------              ---------------------------------------------
 'textWithLanguage          <= 1023 AND 'naturalLanguage' <= 63
 'textWithoutLanguage'      <= 1023
 'nameWithLanguage'         <= 255 AND 'naturalLanguage'  <= 63
 'nameWithoutLanguage'      <= 255
 'keyword'                  <= 255
 'enum'                     = 4
 'uri'                      <= 1023
 'uriScheme'                <= 63
 'charset'                  <= 63
 'naturalLanguage'          <= 63
 'mimeMediaType'            <= 255
 'octetString'              <= 1023
 'boolean'                  = 1
 'integer'                  = 4
 'rangeOfInteger'           = 8
 'dateTime'                 = 11
 'resolution'               = 9
 '1setOf X'
 Note:  It's possible for a Printer to receive a zero length keyword
 in a request.  Since this is a keyword, its value needs to be
 compared with the supported values.  Assuming that the printer
 doesn't have any values in its corresponding "xxx-supported"
 attribute that are keywords of zero length, the comparison will fail.
 Then the request will be accepted or rejected depending on the value
 of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
 No special handling is required for

3.1.2.3.1 Check for conflicting Job Template attributes values

 Once all the Operation and Job Template attributes have been checked
 individually, the Printer object SHOULD check for any conflicting
 values among all the supported values supplied by the client.  For
 example, a Printer object might be able to staple and to print on
 transparencies, however due to physical stapling constraints, the
 Printer object might not be able to staple transparencies.  The IPP
 object copies the supported attributes and their conflicting
 attribute values to the Unsupported Attributes response group.  The
 Printer object only copies over those attributes that the Printer
 object either ignores or substitutes in order to resolve the
 conflict, and it returns the original values which were supplied by
 the client.  For example suppose the client supplies "finishings"
 equals 'staple' and "media" equals 'transparency', but the Printer
 object does not support stapling transparencies.  If the Printer
 chooses to ignore the stapling request in order to resolve the

Hastings, et al. Informational [Page 45] RFC 3196 Internet Printing Protocol/1.1 November 2001

 conflict, the Printer objects returns "finishings" equal to 'staple'
 in the Unsupported Attributes response group.  If any attributes are
 multi-valued, only the conflicting values of the attributes are
 copied.
 Note: The decisions made to resolve the conflict (if there is a
 choice) is implementation dependent.

3.1.2.3.2 Decide whether to REJECT the request

 If there were any unsupported Job Template attributes or
 unsupported/conflicting Job Template attribute values and the client
 supplied the "ipp-attribute-fidelity" attribute with the 'true'
 value, the Printer object REJECTS the request and return the status
 code:
    1.'client-error-conflicting-attributes' status code, if there were
       any conflicts between attributes supplied by the client.
    2.'client-error-attributes-or-values-not-supported' status code,
       otherwise.
 Note:  Unsupported Operation attributes or values that are returned
 do not affect the status returned in this step.  If the unsupported
 Operation attribute was a serious error, the above already rejected
 the request in a previous step.  If control gets to this step with
 unsupported Operation attributes being returned, they are not serious
 errors.
 In general, the final results of Job processing are unknown at Job
 submission time.  The client has to rely on notifications or polling
 to find out what happens at Job processing time.  However, there are
 cases in which some Printers can determine at Job submission time
 that Job processing is going to fail.  As an optimization, we'd like
 to have the Printer reject the Job in these cases.
 There are three types of "processing" errors that might be detectable
 at Job submission time:
 1.  'client-error-document-format-not-supported' :  For the Print-
 Job, Send-Document, Print-URI, and Send-URI operations, if  all these
 conditions are true:
  1. the Printer supports auto-sensing,
  2. the request "document-format" operation attribute is

'application/octet-stream',

  1. the Printer receives document data before responding,
  2. the Printer auto-senses the document format before responding,

Hastings, et al. Informational [Page 46] RFC 3196 Internet Printing Protocol/1.1 November 2001

  1. the sensed document format is not supported by the Printer
 then the  Printer should respond with 'client-error-document-format-
 not-supported' status.
 2.  'client-error-compression-error':  For the Print-Job, Send-
 Document, Print-URI, and Send-URI operations, if  all these
 conditions are true:
  1. the client supplies a supported value for the "compression"

operation attribute in the request

  1. the Printer receives document data before responding,
  2. the Printer attempts to decompress the document data before

responding,

  1. the document data cannot be decompressed using the algorithm

specified by the "compression" operation attribute

 then the Printer should respond with 'client-error-compression-error'
 status.
 3.  'client-error-document-access-error':  For the Print-URI, and
 Send-URI operations, if the Printer attempts and fails to pull the
 referenced document data before responding, it should respond with
 'client-error-document-access-error' status.
 Some Printers are not able to detect these errors until Job
 processing time.  In that case, the errors are recorded in the
 corresponding job-state and job-state reason attributes.  (There is
 no standard way for a client to determine whether a Printer can
 detect these errors at Job submission time.)  For example, if auto-
 sensing happens AFTER the job is accepted (as opposed to auto-sensing
 at submit time before returning the response), the implementation
 aborts the job, puts the job in the 'aborted' state and sets the
 'unsupported-document-format' value in the job's "job-state-reasons".
 A client should always provide a valid "document-format" operation
 attribute whenever practical.  In the absence of other information, a
 client itself may sniff the document data to determine document
 format.
 Auto sensing at Job submission time may be more difficult for the
 Printer when combined with compression.  For auto-sensed Jobs, a
 client may be better off  deferring compression to the transfer
 protocol layer, e.g.; by using the HTTP Content-Encoding header.

Hastings, et al. Informational [Page 47] RFC 3196 Internet Printing Protocol/1.1 November 2001

3.1.2.3.3 For the Validate-Job operation, RETURN one of the success

          status codes
 If the requested operation is the Validate-Job operation, the Printer
 object returns:
    1. the "successful-ok" status code, if there are no unsupported or
       conflicting Job Template attributes or values.
    2. the "successful-ok-conflicting-attributes, if there are any
       conflicting Job Template attribute or values.
    3. the "successful-ok-ignored-or-substituted-attributes, if there
       are only unsupported Job Template attributes or values.
 Note:  Unsupported Operation attributes or values that are returned
 do not affect the status returned in this step.  If the unsupported
 Operation attribute was a serious error, the above already rejected
 the request in a previous step.  If control gets to this step with
 unsupported Operation attributes being returned, they are not serious
 errors.

3.1.2.3.4 Create the Job object with attributes to support

 If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
 by the client), the Printer object:
    1. creates a Job object, assigns a unique value to the job's
       "job-uri" and "job-id" attributes, and initializes all of the
       job's other supported Job Description attributes.
    2. removes all unsupported attributes from the Job object.
    3. for each unsupported value, removes either the unsupported
       value or substitutes the unsupported attribute value with some
       supported value.  If an attribute has no values after removing
       unsupported values from it, the attribute is removed from the
       Job object (so that the normal default behavior at job
       processing time will take place for that attribute).
    4. for each conflicting value, removes either the conflicting
       value or substitutes the conflicting attribute value with some
       other supported value.  If an attribute has no values after
       removing conflicting values from it, the attribute is removed
       from the Job object (so that the normal default behavior at job
       processing time will take place for that attribute).
 If there were no attributes or values flagged as unsupported, or the
 value of 'ipp-attribute-fidelity" was 'false', the Printer object is
 able to accept the create request and create a new Job object.  If
 the "ipp-attribute-fidelity" attribute is set to 'true', the Job
 Template attributes that populate the new Job object are necessarily
 all the Job Template attributes supplied in the create request.  If

Hastings, et al. Informational [Page 48] RFC 3196 Internet Printing Protocol/1.1 November 2001

 the "ipp-attribute-fidelity" attribute is set to 'false', the Job
 Template attributes that populate the new Job object are all the
 client supplied Job Template attributes that are supported or that
 have value substitution.  Thus, some of the requested Job Template
 attributes will not appear in the Job object because the Printer
 object did not support those attributes.  The attributes that
 populate the Job object are persistently stored with the Job object
 for that Job.  A Get-Job-Attributes operation on that Job object will
 return only those attributes that are persistently stored with the
 Job object.
 Note: All Job Template attributes that are persistently stored with
 the Job object are intended to be "override values"; that is, they
 that take precedence over whatever other embedded instructions might
 be in the document data itself.  However, it is not possible for all
 Printer objects to realize the semantics of "override".  End users
 may query the Printer's "pdl-override-supported" attribute to
 determine if the Printer either attempts or does not attempt to
 override document data instructions with IPP attributes.
 There are some cases, where a Printer supports a Job Template
 attribute and has an associated default value set for that attribute.
 In the case where a client does not supply the corresponding
 attribute, the Printer does not use its default values to populate
 Job attributes when creating the new Job object; only Job Template
 attributes actually in the create request are used to populate the
 Job object.  The Printer's default values are only used later at Job
 processing time if no other IPP attribute or instruction embedded in
 the document data is present.
 Note: If the default values associated with Job Template attributes
 that the client did not supply were to be used to populate the Job
 object, then these values would become "override values" rather than
 defaults.  If the Printer supports the 'attempted' value of the
 "pdl-override-supported" attribute, then these override values could
 replace values specified within the document data.  This is not the
 intent of the default value mechanism.  A default value for an
 attribute is used only if the create request did not specify that
 attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
 being 'false') and no value was provided within the content of the
 document data.
 If the client does not supply a value for some Job Template
 attribute, and the Printer does not support that attribute, as far as
 IPP is concerned, the result of processing that Job (with respect to
 the missing attribute) is undefined.

Hastings, et al. Informational [Page 49] RFC 3196 Internet Printing Protocol/1.1 November 2001

3.1.2.3.5 Return one of the success status codes

 Once the Job object has been created, the Printer object accepts the
 request and returns to the client:
    1. the 'successful-ok' status code, if there are no unsupported or
       conflicting Job Template attributes or values.
    2. the 'successful-ok-conflicting-attributes' status code, if
       there are any conflicting Job Template attribute or values.
    3. the 'successful-ok-ignored-or-substituted-attributes' status
       code, if there are only unsupported Job Template attributes or
       values.
 Note:  Unsupported Operation attributes or values that are returned
 do not affect the status returned in this step.  If the unsupported
 Operation attribute was a serious error, the above already rejected
 the request in a previous step.  If control gets to this step with
 unsupported Operation attributes being returned, they are not serious
 errors.
 The Printer object also returns Job status attributes that indicate
 the initial state of the Job ('pending', 'pending-held',
 'processing', etc.), etc.  See Print-Job Response, [RFC2911] section
 3.2.1.2.

3.1.2.3.6 Accept appended Document Content

 The Printer object accepts the appended Document Content data and
 either starts it printing, or spools it for later processing.

3.1.2.3.7 Scheduling and Starting to Process the Job

 The Printer object uses its own configuration and implementation
 specific algorithms for scheduling the Job in the correct processing
 order.  Once the Printer object begins processing the Job, the
 Printer changes the Job's state to 'processing'.  If the Printer
 object supports PDL override (the "pdl-override-supported" attribute
 set to 'attempted'), the implementation does its best to see that IPP
 attributes take precedence over embedded instructions in the document
 data.

3.1.2.3.8 Completing the Job

 The Printer object continues to process the Job until it can move the
 Job into the 'completed' state.  If an Cancel-Job operation is
 received, the implementation eventually moves the Job into the
 'canceled' state.  If the system encounters errors during processing
 that do not allow it to progress the Job into a completed state, the

Hastings, et al. Informational [Page 50] RFC 3196 Internet Printing Protocol/1.1 November 2001

 implementation halts all processing, cleans up any resources, and
 moves the Job into the 'aborted' state.

3.1.2.3.9 Destroying the Job after completion

 Once the Job moves to the 'completed', 'aborted', or 'canceled'
 state, it is an implementation decision as to when to destroy the Job
 object and release all associated resources.  Once the Job has been
 destroyed, the Printer would return either the "client-error-not-
 found" or "client-error-gone" status codes for operations directed at
 that Job.
 Note:  the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
 value for a sufficiently long time after a job has been destroyed, so
 that stale references kept by clients are less likely to access the
 wrong (newer) job.

3.1.2.3.10 Interaction with "ipp-attribute-fidelity"

 Some Printer object implementations may support "ipp-attribute-
 fidelity" set to 'true' and "pdl-override-supported" set to
 'attempted' and yet still not be able to realize exactly what the
 client specifies in the create request.  This is due to legacy
 decisions and assumptions that have been made about the role of job
 instructions embedded within the document data and external job
 instructions that accompany the document data and how to handle
 conflicts between such instructions.  The inability to be 100%
 precise about how a given implementation will behave is also
 compounded by the fact that the two special attributes, "ipp-
 attribute-fidelity" and "pdl-"override-supported", apply to the whole
 job rather than specific values for each attribute. For example, some
 implementations may be able to override almost all Job Template
 attributes except for "number-up".  Character Sets, natural
 languages, and internationalization
 This section discusses character set support, natural language
 support and internationalization.

3.1.2.3.11 Character set code conversion support

 IPP clients and IPP objects are REQUIRED to support UTF-8.  They MAY
 support additional charsets.  It is RECOMMENDED that an IPP object
 also support US-ASCII, since many clients support US-ASCII, and
 indicate that UTF-8 and US-ASCII are supported by populating the
 Printer's "charset-supported" with 'utf-8' and 'us-ascii' values.  An
 IPP object is required to code covert with as little loss as possible
 between the charsets that it supports, as indicated in the Printer's
 "charsets-supported" attribute.

Hastings, et al. Informational [Page 51] RFC 3196 Internet Printing Protocol/1.1 November 2001

 How should the server handle the situation where the "attributes-
 charset" of the response itself is "us-ascii", but one or more
 attributes in that response is in the "utf-8" format?
 Example: Consider a case where a client sends a Print-Job request
 with "utf-8" as the value of "attributes-charset" and with the "job-
 name" attribute supplied.  Later another client submits a Get-Job-
 Attribute or Get-Jobs request.  This second request contains the
 "attributes-charset" with value "us-ascii" and "requested-attributes"
 attribute with exactly one value "job-name".
 According to the RFC2911 document (section 3.1.4.2), the value of the
 "attributes-charset" for the response of the second request must be
 "us-ascii" since that is the charset specified in the request.  The
 "job-name" value, however, is in "utf-8" format.  Should the request
 be rejected even though both "utf-8" and "us-ascii" charsets are
 supported by the server? or should the "job-name" value be converted
 to "us-ascii" and return "successful-ok-conflicting-attributes"
 (0x0002) as the status code?
 Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
 ascii, the second paragraph of section 3.1.4.2 applies so that the
 IPP object MUST accept the request, perform code set conversion
 between these two charsets with "the highest fidelity possible" and
 return 'successful-ok', rather than a warning 'successful-ok-
 conflicting-attributes, or an error.  The printer will do the best it
 can to convert between each of the character sets that it supports --
 even if that means providing a string of question marks because none
 of the characters are representable in US ASCII.  If it can't perform
 such conversion, it MUST NOT advertise us-ascii as a value of its
 "attributes-charset-supported" and MUST reject any request that
 requests 'us-ascii'.
 One IPP object implementation strategy is to convert all request text
 and name values to a Unicode internal representation.  This is 16-bit
 and virtually universal.  Then convert to the specified operation
 attributes-charset on output.
 Also it would be smarter for a client to ask for 'utf-8', rather than
 'us-ascii' and throw away characters that it doesn't understand,
 rather than depending on the code conversion of the IPP object.

3.1.2.3.12 What charset to return when an unsupported charset is

          requested (Issue 1.19)?
 Section 3.1.4.1 Request Operation attributes was clarified in
 November 1998 as follows:

Hastings, et al. Informational [Page 52] RFC 3196 Internet Printing Protocol/1.1 November 2001

 All clients and IPP objects MUST support the 'utf-8' charset
 [RFC2044] and MAY support additional charsets provided that they are
 registered with IANA [IANA-CS].  If the Printer object does not
 support the client supplied charset value, the Printer object MUST
 reject the request, set the "attributes-charset" to 'utf-8' in the
 response, and return the 'client-error-charset-not-supported' status
 code and any 'text' or 'name' attributes using the 'utf-8' charset.
 Since the client and IPP object MUST support UTF-8, returning any
 text or name attributes in UTF-8 when the client requests a charset
 that is not supported should allow the client to display the text or
 name.
 Since such an error is a client error, rather than a user error, the
 client should check the status code first so that it can avoid
 displaying any other returned 'text' and 'name' attributes that are
 not in the charset requested.
 Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-
 supported (0x040D) was clarified in November 1998 as follows:
 For any operation, if the IPP Printer does not support the charset
 supplied by the client in the "attributes-charset" operation
 attribute, the Printer MUST reject the operation and return this
 status and any 'text' or 'name' attributes using the 'utf-8' charset
 (see Section 3.1.4.1).

3.1.2.3.13 Natural Language Override (NLO)

 The 'text' and 'name' attributes each have two forms.  One has an
 implicit natural language, and the other has an explicit natural
 language.  The 'textWithoutLanguage' and 'textWithLanguage' are the
 two 'text' forms.  The 'nameWithoutLanguage" and 'nameWithLanguage
 are the two 'name' forms.  If a receiver (IPP object or IPP client)
 supports an attribute with attribute syntax 'text', it MUST support
 both forms in a request and a response.  A sender (IPP client or IPP
 object) MAY send either form for any such attribute.  When a sender
 sends a WithoutLanguage form, the implicit natural language is
 specified in the "attributes-natural-language" operation attribute,
 which all senders MUST include in every request and response.
 When a sender sends a WithLanguage form, it MAY be different from the
 implicit natural language supplied by the sender or it MAY be the
 same.  The receiver MUST treat either form equivalently.
 There is an implementation decision for senders, whether to always
 send the WithLanguage forms or use the WithoutLanguage form when the
 attribute's natural language is the same as the request or response.

Hastings, et al. Informational [Page 53] RFC 3196 Internet Printing Protocol/1.1 November 2001

 The former approach makes the sender implementation simpler.  The
 latter approach is more efficient on the wire and allows inter-
 working with non-conforming receivers that fail to support the
 WithLanguage forms.  As each approach have advantages, the choice is
 completely up to the implementer of the sender.
 Furthermore, when a client receives a 'text' or 'name' job attribute
 that it had previously supplied, that client MUST NOT expect to see
 the attribute in the same form, i.e., in the same WithoutLanguage or
 WithLanguage form as the client supplied when it created the job.
 The IPP object is free to transform the attribute from the
 WithLanguage form to the WithoutLanguage form and vice versa, as long
 as the natural language is preserved.  However, in order to meet this
 latter requirement, it is usually simpler for the IPP object
 implementation to store the natural language explicitly with the
 attribute value, i.e., to store using an internal representation that
 resembles the WithLanguage form.
 The IPP Printer MUST copy the natural language of a job, i.e., the
 value of the "attributes-natural-language" operation attribute
 supplied by the client in the create operation, to the Job object as
 a Job Description attribute, so that a client is able to query it.
 In returning a Get-Job-Attributes response, the IPP object MAY return
 one of three natural language values in the responses "attributes-
 natural-language" operation attribute: (1) that requested by the
 requester, (2) the natural language of the job, or (3) the configured
 natural language of the IPP Printer, if the requested language is not
 supported by the IPP Printer.
 This "attributes-natural-language" Job Description attribute is
 useful for an IPP object implementation that prints start sheets in
 the language of the user who submitted the job.  This same Job
 Description attribute is useful to a multi-lingual operator who has
 to communicate with different job submitters in different natural
 languages.  This same Job Description attribute is expected to be
 used in the future to generate notification messages in the natural
 language of the job submitter.
 Early drafts of [RFC2911] contained a job-level natural language
 override (NLO) for the Get-Jobs response.  A job-level (NLO) is an
 (unrequested) Job Attribute which then specified the implicit natural
 language for any other WithoutLanguage job attributes returned in the
 response for that job.  Interoperability testing of early
 implementations showed that no one was implementing the job-level NLO
 in Get-Job responses.  So the job-level NLO was eliminated from the
 Get-Jobs response.  This simplification makes all requests and
 responses consistent in that the implicit natural language for any

Hastings, et al. Informational [Page 54] RFC 3196 Internet Printing Protocol/1.1 November 2001

 WithoutLanguage 'text' or 'name' form is always supplied in the
 request's or response's "attributes-natural-language" operation
 attribute.

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-

Hastings, et al. Informational [Page 55] RFC 3196 Internet Printing Protocol/1.1 November 2001

    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.

Hastings, et al. Informational [Page 56] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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.

Hastings, et al. Informational [Page 57] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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.

Hastings, et al. Informational [Page 58] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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.

Hastings, et al. Informational [Page 59] RFC 3196 Internet Printing Protocol/1.1 November 2001

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

Hastings, et al. Informational [Page 60] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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.

Hastings, et al. Informational [Page 61] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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.

Hastings, et al. Informational [Page 62] RFC 3196 Internet Printing Protocol/1.1 November 2001

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

Hastings, et al. Informational [Page 63] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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

Hastings, et al. Informational [Page 64] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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:

Hastings, et al. Informational [Page 65] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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.

Hastings, et al. Informational [Page 66] RFC 3196 Internet Printing Protocol/1.1 November 2001

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

Hastings, et al. Informational [Page 67] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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.

Hastings, et al. Informational [Page 68] RFC 3196 Internet Printing Protocol/1.1 November 2001

       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.

Hastings, et al. Informational [Page 69] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 70] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 71] RFC 3196 Internet Printing Protocol/1.1 November 2001

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

Hastings, et al. Informational [Page 72] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 73] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 74] RFC 3196 Internet Printing Protocol/1.1 November 2001

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

Hastings, et al. Informational [Page 75] RFC 3196 Internet Printing Protocol/1.1 November 2001

      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

Hastings, et al. Informational [Page 76] RFC 3196 Internet Printing Protocol/1.1 November 2001

 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.

Hastings, et al. Informational [Page 77] RFC 3196 Internet Printing Protocol/1.1 November 2001

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.

Hastings, et al. Informational [Page 78] RFC 3196 Internet Printing Protocol/1.1 November 2001

4.5 Empty Jobs

 The IPP object model does not prohibit a job that contains no
 documents.  Such a job may be created in a number of ways including a
 'create-job' followed by an 'add-document' that contains no data and
 has the 'last-document' flag set.
 An empty job is processed just as any other job.  The operation that
 "closes" an empty job is not rejected because the job is empty.  If
 no other conditions exist, other than the job is empty, the response
 to the operation will indicate success.  After the job is scheduled
 and processed, the job state SHALL be 'completed'.
 There will be some variation in the value(s) of the "job-state-
 reasons" attribute.  It is required that if no conditions, other than
 the job being empty, exist the "job-state-reasons" SHALL include the
 'completed-successfully'.  If other conditions existed, the
 'completed-with-warnings' or 'completed-with-errors' values may be
 used.

5 Directory Considerations

5.1 General Directory Schema Considerations

 The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object
 attributes for directory schemas.  See [RFC2911] APPENDIX E: Generic
 Directory Schema.
 The SLP printer template is defined in the "Definition of the Printer
 Abstract Service Type v2.0" document [svrloc-printer].  The LDAP
 printer template is defined in the "Internet Printing Protocol (IPP):
 LDAP Schema for Printer Services" document [ldap-printer].  Both
 documents systematically add "printer-" to any attribute that doesn't
 already start with "printer-" in order to keep the printer directory
 attributes distinct from other directory attributes.  Also, instead
 of using "printer-uri-supported", "uri-authentication-supported", and
 "uri-security-supported", they use a "printer-xri-supported"
 attribute with special syntax to contain all of the same information
 in a single attribute.

5.2 IPP Printer with a DNS name

 If the IPP printer has a DNS name should there be at least two values
 for the printer-uri-supported attribute.  One URL with the fully
 qualified DNS name the other with the IP address in the URL?

Hastings, et al. Informational [Page 79] RFC 3196 Internet Printing Protocol/1.1 November 2001

 The printer may contain one or the other or both.  It's up to the
 administrator to configure this attribute.

6 Security Considerations

 The security considerations given in [RFC2911] Section 8 "Security
 Considerations" all apply to this document.  In addition, the
 following sub-sections describes security consideration that have
 arisen as a result of implementation testing.

6.1 Querying jobs with IPP that were submitted using other job

   submission protocols (Issue 1.32)
 The following clarification was added to [RFC2911] section 8.5:
    8.5 Queries on jobs submitted using non-IPP protocols If the
    device that an IPP Printer is representing is able to accept jobs
    using other job submission protocols in addition to IPP, it is
    RECOMMEND that such an implementation at least allow such
    "foreign" jobs to be queried using Get-Jobs returning "job-id" and
    "job-uri" as 'unknown'.  Such an implementation NEED NOT support
    all of the same IPP job attributes as for IPP jobs.  The IPP
    object returns the 'unknown' out-of-band value for any requested
    attribute of a foreign job that is supported for IPP jobs, but not
    for foreign jobs.
    It is further RECOMMENDED, that the IPP Printer generate "job-id"
    and "job-uri" values for such "foreign jobs", if possible, so that
    they may be targets of other IPP operations, such as Get-Job-
    Attributes and Cancel-Job.  Such an implementation also needs to
    deal with the problem of authentication of such foreign jobs.  One
    approach would be to treat all such foreign jobs as belonging to
    users other than the user of the IPP client.  Another approach
    would be for the foreign job to belong to 'anonymous'.  Only if
    the IPP client has been authenticated as an operator or
    administrator of the IPP Printer object, could the foreign jobs be
    queried by an IPP request.  Alternatively, if the security policy
    were to allow users to query other users' jobs, then the foreign
    jobs would also be visible to an end-user IPP client using Get-
    Jobs and Get-Job- Attributes.
    Thus IPP MAY be implemented as a "universal" protocol that
    provides access to jobs submitted with any job submission
    protocol.  As IPP becomes widely implemented, providing a more
    universal access makes sense.

Hastings, et al. Informational [Page 80] RFC 3196 Internet Printing Protocol/1.1 November 2001

7 Encoding and Transport

 This section discusses various aspects of IPP/1.1 Encoding and
 Transport [RFC2910].
 A server is not required to send a response until after it has
 received the client's entire request.  Hence, a client must not
 expect a response until after it has sent the entire request.
 However, we recommend that the server return a response as soon as
 possible if an error is detected while the client is still sending
 the data, rather than waiting until all of the data is received.
 Therefore, we also recommend that a client listen for an error
 response that an IPP server MAY send before it receives all the data.
 In this case a client, if chunking the data, can send a premature
 zero-length chunk to end the request before sending all the data (and
 so the client can keep the connection open for other requests, rather
 than closing it).  If the request is blocked for some reason, a
 client MAY determine the reason by opening another connection to
 query the server using Get-Printer-Attributes.
 IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793]
 to throttle clients when Printers are busy.  Therefore, it is
 perfectly normal for an IPP client transmitting a Job to be blocked
 for a really long time.  Accordingly, socket timeouts must be
 avoided.  Some socket implementations have a timeout option, which
 specifies how long a write operation on a socket can be blocked
 before it times out and the blocking ends.  A client should set this
 option for infinite timeout when transmitting Job submissions.
 Some IPP client applications might be able to perform other useful
 work while a Job transmission is blocked.  For example, the client
 may have other jobs that it could transmit to other Printers
 simultaneously.  A client may have a GUI, which must remain
 responsive to the user while the Job transmission is blocked.  These
 clients should be designed to spawn a thread to handle the Job
 transmission at its own pace, leaving the main application free to do
 other work.  Alternatively, single-threaded applications could use
 non-blocking I/O.
 Some Printer conditions, such as jam or lack of paper, could cause a
 client to be blocked indefinitely.  Clients may open additional
 connections to the Printer to Get-Printer-Attributes, determine the
 state of the device, alert a user if the printer is stopped, and let
 a user decide whether to abort the job transmission or not.
 In the following sections, there are tables of all HTTP headers,
 which describe their use in an IPP client or server.  The following
 is an explanation of each column in these tables.

Hastings, et al. Informational [Page 81] RFC 3196 Internet Printing Protocol/1.1 November 2001

  1. the "header" column contains the name of a header
  2. the "request/client" column indicates whether a client sends the

header.

  1. the "request/ server" column indicates whether a server supports

the header when received.

  1. the "response/ server" column indicates whether a server sends

the header.

  1. the "response /client" column indicates whether a client

supports the header when received.

  1. the "values and conditions" column specifies the allowed header

values and the conditions for the header to be present in a

     request/response.
 The table for "request headers" does not have columns for responses,
 and the table for "response headers" does not have columns for
 requests.
 The following is an explanation of the values in the "request/client"
 and "response/ server" columns.
  1. must: the client or server MUST send the header,
  2. must-if: the client or server MUST send the header when the

condition described in the "values and conditions" column is

     met,
   - may: the client or server MAY send the header
   - not: the client or server SHOULD NOT send the header. It is not
     relevant to an IPP implementation.
 The following is an explanation of the values in the
 "response/client" and "request/ server" columns.
  1. must: the client or server MUST support the header,
  2. may: the client or server MAY support the header
  3. not: the client or server SHOULD NOT support the header. It is

not relevant to an IPP implementation.

Hastings, et al. Informational [Page 82] RFC 3196 Internet Printing Protocol/1.1 November 2001

7.1 General Headers

 The following is a table for the general headers.
 General-    Request         Response       Values and Conditions
 Header
             Client  Server  Server Client
 Cache-              not     must   not     "no-cache" only
   Control   must
 Connection  must-   must    must-  must    "close" only.  Both
               if              if             client and server
                                              SHOULD keep a
                                              connection for the
                                              duration of a sequence
                                              of operations.  The
                                              client and server MUST
                                              include this header
                                              for the last operation
                                              in such a sequence.
 Date        may     may     must   may     per RFC 1123 [RFC1123]
                                              from RFC 2616
                                              [RFC2616]
 Pragma      must    not     must   not     "no-cache" only
 Transfer-   must-   must    must-  must    "chunked" only.  Header
   Encoding    if              if             MUST be present if
                                              Content-Length is
                                              absent.
 Upgrade     not     not     not    not
 Via         not     not     not    not

Hastings, et al. Informational [Page 83] RFC 3196 Internet Printing Protocol/1.1 November 2001

7.2 Request Headers

 The following is a table for the request headers.
 Request-       Client   Server Request Values and Conditions
 Header
 Accept         may      must   "application/ipp" only.  This
                                  value is the default if the
                                  client omits it
 Accept-        not      not     Charset information is within the
   Charset                        application/ipp entity
 Accept-        may      must   empty and per RFC 2616 [RFC2616]
   Encoding                       and IANA registry for content-
                                  codings
 Accept-        not      not    language information is within the
   Language                       application/ipp entity
 Authorization  must-    must   per RFC 2616.  A client MUST send
                  if              this header when it receives a
                                  401 "Unauthorized" response and
                                  does not receive a "Proxy-
                                  Authenticate" header.
 From           not      not    per RFC 2616.  Because RFC
                                  recommends sending this header
                                  only with the user's approval,
                                  it is not very useful
 Host           must     must   per RFC 2616
 If-Match       not      not
 If-Modified-   not      not
   Since
 If-None-Match  not      not
 If-Range       not      not
 If-            not      not
   Unmodified-
   Since

Hastings, et al. Informational [Page 84] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Request-       Client   Server Request Values and Conditions
 Header
 Max-Forwards   not      not
 Proxy-         must-    not    per RFC 2616.  A client MUST send
   Authorizati    if              this header when it receives a
   on                             401 "Unauthorized" response and
                                  a "Proxy-Authenticate" header.
 Range          not      not
 Referrer       not      not
 User-Agent     not      not

Hastings, et al. Informational [Page 85] RFC 3196 Internet Printing Protocol/1.1 November 2001

7.3 Response Headers

 The following is a table for the request headers.
 Response-       Server  Client Response Values and Conditions
 Header
 Accept-Ranges   not     not
 Age             not     not
 Location        must-   may    per RFC 2616.  When URI needs
                   if             redirection.
 Proxy-                  must   per RFC 2616
   Authenticat
   e             not
 Public          may     may    per RFC 2616
 Retry-After     may     may    per RFC 2616
 Server          not     not
 Vary            not     not
 Warning         may     may    per RFC 2616
 WWW-            must-   must   per RFC 2616.  When a server needs
   Authenticate    if             to authenticate a client.

Hastings, et al. Informational [Page 86] RFC 3196 Internet Printing Protocol/1.1 November 2001

7.4 Entity Headers

 The following is a table for the entity headers.
 Entity-Header   Request        Response        Values and
                                                Conditions
                 Client  Server Server  Client
 Allow           not     not    not     not
 Content-Base    not     not    not     not
 Content-        may     must   must    must    per RFC 2616 and
   Encoding                                       IANA registry for
                                                  content codings.
 Content-        not     not    not     not     Application/ipp
   Language                                       handles language
 Content-        must-   must   must-   must    the length of the
   Length          if             if              message-body per
                                                  RFC 2616.  Header
                                                  MUST be present
                                                  if Transfer-
                                                  Encoding is
                                                  absent..
 Content-        not     not    not     not
   Location
 Content-MD5     may     may    may     may     per RFC 2616
 Content-Range   not     not    not     not
 Content-Type    must    must   must    must    "application/ipp"
                                                  only
 ETag            not     not    not     not
 Expires         not     not    not     not
 Last-Modified   not     not    not     not

Hastings, et al. Informational [Page 87] RFC 3196 Internet Printing Protocol/1.1 November 2001

7.5 Optional support for HTTP/1.0

 IPP implementations consist of an HTTP layer and an IPP layer.  In
 the following discussion, the term "client" refers to the HTTP client
 layer and the term "server" refers to the HTTP server layer.  The
 Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST
 be supported by all clients and all servers.  However, a client
 and/or a server implementation may choose to also support HTTP 1.0.
 This option means that a server may choose to communicate with a
 (non-conforming) client that only supports HTTP 1.0.  In such cases
 the server should not use any HTTP 1.1 specific parameters or
 features and should respond using HTTP version number 1.0.
 This option also means that a client may choose to communicate with a
 (non-conforming) server that only supports HTTP 1.0.  In such cases,
 if the server responds with an HTTP 'unsupported version number' to
 an HTTP 1.1 request, the client should retry using HTTP version
 number 1.0.

7.6 HTTP/1.1 Chunking

7.6.1 Disabling IPP Server Response Chunking

 Clients MUST anticipate that the HTTP/1.1 server may chunk responses
 and MUST accept them in responses.  However, a (non-conforming) HTTP
 client that is unable to accept chunked responses may attempt to
 request an HTTP 1.1 server not to use chunking in its response to an
 operation by using the following HTTP header:
    TE: identity
 This mechanism should not be used by a server to disable a client
 from chunking a request, since chunking of document data is an
 important feature for clients to send long documents.

7.6.2 Warning About the Support of Chunked Requests

 This section describes some problems with the use of chunked requests
 and HTTP/1.1 servers.
 The HTTP/1.1 standard [RFC2616] requires that conforming servers
 support chunked requests for any method.  However, in spite of this
 requirement, some HTTP/1.1 implementations support chunked responses
 in the GET method, but do not support chunked POST method requests.
 Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
 servlets [Servlet] require that the client supply a Content-Length.
 These implementations might reject a chunked POST method and return a

Hastings, et al. Informational [Page 88] RFC 3196 Internet Printing Protocol/1.1 November 2001

 411 status code (Length Required), might attempt to buffer the
 request and run out of room returning a 413 status code (Request
 Entity Too Large), or might successfully accept the chunked request.
 Because of this lack of conformance of HTTP servers to the HTTP/1.1
 standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP
 Printer object implementation support chunked requests and that
 conforming clients accept chunked responses.  Therefore, IPP object
 implementers are warned to seek HTTP server implementations that
 support chunked POST requests in order to conform to the IPP standard
 and/or use implementation techniques that support chunked POST
 requests.

8 References

 [CGI]             CGI/1.1 (http://www.w3.org/CGI/).
 [IANA-CS]         IANA Registry of Coded Character Sets:
                   http://www.iana.org/assignments/character-sets
 [ldap-printer]    Fleming, P., Jones, K., Lewis, H. and I. McDonald,
                   "Internet Printing Protocol (IPP): LDAP Schema for
                   Printer Services", Work in Progress.
 [RFC793]          Postel, J., "Transmission Control Protocol", STD 7,
                   RFC 793, September 1981.
 [RFC1123]         Braden, R., "Requirements for Internet Hosts -
                   Application and Support", RFC 1123, October, 1989.
 [RFC2026]         Bradner, S., "The Internet Standards Process --
                   Revision 3", BCP 9, RFC 2026, October 1996.
 [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119 , March 1997.
 [RFC2396]         Berners-Lee, T., Fielding, R. and L. Masinter,
                   "Uniform Resource Identifiers (URI): Generic
                   Syntax", RFC 2396, August 1998.
 [RFC2565]         DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
                   and P. Powell, "Internet Printing Protocol/1.0:
                   Model and Semantics", RFC 2566, April 1999.

Hastings, et al. Informational [Page 89] RFC 3196 Internet Printing Protocol/1.1 November 2001

 [RFC2566]         Herriot, R., Butler, S., Moore, P. and R. Turner,
                   "Internet Printing Protocol/1.0: Encoding and
                   Transport", RFC 2565, April 1999.
 [RFC2567]         Wright, D., "Design Goals for an Internet Printing
                   Protocol", RFC 2567, April 1999.
 [RFC2568]         Zilles, S., "Rationale for the Structure and Model
                   and Protocol for the Internet Printing Protocol",
                   RFC 2568, April 1999.
 [RFC2569]         Herriot, R., Hastings, T., Jacobs, N. and J.
                   Martin, "Mapping between LPD and IPP Protocols",
                   RFC 2569, April 1999.
 [RFC2616]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                   Masinter, L., Leach, P. and T. Berners-Lee,
                   "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
                   June 1999.
 [RFC2910]         Herriot, R., Butler, S., Moore, P. and R. Turner,
                   "Internet Printing Protocol/1.0: Encoding and
                   Transport", RFC 2910, September, 2000.
 [RFC2911]         DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
                   and P. Powell, "Internet Printing Protocol/1.0:
                   Model and Semantics", RFC 2911, September, 2000.
 [Servlet]         Servlet Specification Version 2.1
                   (http://java.sun.com/products/servlet/2.1/
                   index.html).
 [svrloc-printer]  St. Pierre, P., Isaacson, S., McDonald, I.,
                   "Definition of the Printer Abstract Service Type
                   v2.0", http://www.isi.edu/in-
                   notes/iana/assignments/svrloc-
                   templates/printer.2.0.en (IANA Registered, May 27,
                   2000).
 [SSL]             Netscape, The SSL Protocol, Version 3, (Text
                   version 3.02), November 1996.

Hastings, et al. Informational [Page 90] RFC 3196 Internet Printing Protocol/1.1 November 2001

9. Authors' Addresses

 Thomas N. Hastings
 Xerox Corporation
 701 Aviation Blvd.
 El Segundo, CA 90245
 EMail: hastings@cp10.es.xerox.com
 Carl-Uno Manros
 Independent Consultant
 1601 N. Sepulveda Blvd. #505
 Manhattan Beach, CA 90266
 Email: carl@manros.com
 Carl Kugler
 Mail Stop 003G
 IBM Printing Systems Co
 6300 Diagonal Hwy
 Boulder CO 80301
 EMail: Kugler@us.ibm.com
 Henrik Holst
 i-data Printing Systems
 Vadstrupvej 35-43
 2880 Bagsvaerd, Denmark
 EMail: hh@I-data.com
 Peter Zehler
 Xerox Corporation
 800 Philips Road
 Webster, NY 14580
 EMail: PZehler@crt.xerox.com

Hastings, et al. Informational [Page 91] RFC 3196 Internet Printing Protocol/1.1 November 2001

 IPP Web Page:  http://www.pwg.org/ipp/
 IPP Mailing List:  ipp@pwg.org
 To subscribe to the ipp mailing list, send the following email:
    1) send it to majordomo@pwg.org
    2) leave the subject line blank
    3) put the following two lines in the message body:
       subscribe ipp
       end
 Implementers of this specification document are encouraged to join
 the IPP Mailing List in order to participate in any discussions of
 clarification issues and review of registration proposals for
 additional attributes and values.  In order to reduce spam the
 mailing list rejects mail from non-subscribers, so you must subscribe
 to the mailing list in order to send a question or comment to the
 mailing list.
 Other Participants:
 Chuck Adams - Tektronix            Shivaun Albright - HP
 Stefan Andersson - Axis            Jeff Barnett - IBM
 Ron Bergman - Hitachi Koki         Dennis Carney - IBM
 Imaging Systems
 Keith Carter - IBM                 Angelo Caruso - Xerox
 Rajesh Chawla - TR Computing       Nancy Chen - Okidata
 Solutions
 Josh Cohen - Microsoft             Jeff Copeland - QMS
 Andy Davidson - Tektronix          Roger deBry - IBM
 Maulik Desai - Auco                Mabry Dozier - QMS
 Lee Farrell - Canon Information    Satoshi Fujitami - Ricoh
 Systems
 Steve Gebert - IBM                 Sue Gleeson - Digital
 Charles Gordon - Osicom            Brian Grimshaw - Apple
 Jerry Hadsell - IBM                Richard Hart - Digital

Hastings, et al. Informational [Page 92] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Tom Hastings - Xerox               Henrik Holst - I-data
 Stephen Holmstead                  Zhi-Hong Huang - Zenographics
 Scott Isaacson - Novell            Babek Jahromi - Microsoft
 Swen Johnson - Xerox               David Kellerman - Northlake
                                    Software
 Robert Kline - TrueSpectra         Charles Kong - Panasonic
 Carl Kugler - IBM                  Dave Kuntz - Hewlett-Packard
 Takami Kurono - Brother            Rick Landau - Digital
 Scott Lawrence - Agranot Systems   Greg LeClair - Epson
 Dwight Lewis - Lexmark             Harry Lewis - IBM
 Tony Liao - Vivid Image            Roy Lomicka - Digital
 Pete Loya - HP                     Ray Lutz - Cognisys
 Mike MacKay - Novell, Inc.         David Manchala - Xerox
 Carl-Uno Manros - Xerox            Jay Martin - Underscore
 Stan McConnell - Xerox             Larry Masinter - Xerox
 Sandra Matts - Hewlett Packard     Peter Michalek - Shinesoft
 Ira McDonald - High North Inc.     Mike Moldovan - G3 Nova
 Tetsuya Morita - Ricoh             Yuichi Niwa - Ricoh
 Pat Nogay - IBM                    Ron Norton - Printronics
 Hugo Parra, Novell                 Bob Pentecost - Hewlett-Packard
 Patrick Powell - Astart            Jeff Rackowitz - Intermec
 Technologies
 Eric Random - Peerless             Rob Rhoads - Intel
 Xavier Riley - Xerox               Gary Roberts - Ricoh
 David Roach - Unisys               Stuart Rowley - Kyocera

Hastings, et al. Informational [Page 93] RFC 3196 Internet Printing Protocol/1.1 November 2001

 Yuji Sasaki - Japan Computer       Richard Schneider - Epson
 Industry
 Kris Schoff - HP                   Katsuaki Sekiguchi - Canon
 Bob Setterbo - Adobe               Gail Songer - Peerless
 Hideki Tanaka - Canon              Devon Taylor - Novell, Inc.
 Mike Timperman - Lexmark           Atsushi Uchino - Epson
 Shigeru Ueda - Canon               Bob Von Andel - Allegro Software
 William Wagner - NetSilicon/DPI    Jim Walker - DAZEL
 Chris Wellens - Interworking Labs  Trevor Wells - Hewlett Packard
 Craig Whittle - Sharp Labs         Rob Whittle - Novell, Inc.
 Jasper Wong - Xionics              Don Wright - Lexmark
 Michael Wu - Heidelberg Digital    Rick Yardumian - Xerox
 Michael Yeung - Toshiba            Lloyd Young - Lexmark
 Atsushi Yuki - Kyocera             Peter Zehler - Xerox
 William Zhang- Canon Information   Frank Zhao - Panasonic
 Systems
 Steve Zilles - Adobe               Rob Zirnstein - Canon
                                    Information Systems

10. Description of the Base IPP Documents

 In addition to this document, the base set of IPP documents includes:
    Design Goals for an Internet Printing Protocol [RFC2567]
    Rationale for the Structure and Model and Protocol for the
    Internet
    Printing Protocol [RFC2568]
    Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
    Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
    Mapping between LPD and IPP Protocols [RFC2569]
 The "Design Goals for an Internet Printing Protocol" document takes a
 broad look at distributed printing functionality, and it enumerates
 real-life scenarios that help to clarify the features that need to be

Hastings, et al. Informational [Page 94] RFC 3196 Internet Printing Protocol/1.1 November 2001

 included in a printing protocol for the Internet.  It identifies
 requirements for three types of users: end users, operators, and
 administrators.  It calls out a subset of end user requirements that
 are satisfied in IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator
 operations have been added to IPP/1.1 [RFC2911, RFC2910].
 The "Rationale for the Structure and Model and Protocol for the
 Internet Printing Protocol" document describes IPP from a high level
 view, defines a roadmap for the various documents that form the suite
 of IPP specification documents, and gives background and rationale
 for the IETF IPP working group's major decisions.
 The "Internet Printing Protocol/1.1: Model and Semantics" document
 describes a simplified model with abstract objects, their attributes,
 and their operations.  The model introduces a Printer and a Job.  The
 Job supports multiple documents per Job.  The model document also
 addresses how security, internationalization, and directory issues
 are addressed.
 The "Internet Printing Protocol/1.1: Encoding and Transport" document
 is a formal mapping of the abstract operations and attributes defined
 in the model document onto HTTP/1.1 [RFC2616].  It also defines the
 encoding rules for a new Internet MIME media type called
 "application/ipp".  This document also defines the rules for
 transporting a message body over HTTP whose Content-Type is
 "application/ipp".  This document defines the 'ipp' scheme for
 identifying IPP printers and jobs.
 The "Mapping between LPD and IPP Protocols" document gives some
 advice to implementers of gateways between IPP and LPD (Line Printer
 Daemon) implementations.

Hastings, et al. Informational [Page 95] RFC 3196 Internet Printing Protocol/1.1 November 2001

11 Full Copyright Statement

 Copyright (C) The Internet Society (2001).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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

Hastings, et al. Informational [Page 96]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3196.txt · Last modified: 2001/12/04 17:28 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki