7 Network Working Group T. Hastings
8 Request for Comments: 3196 C. Manros
9 Obsoletes: 2639 P. Zehler
10 Category: Informational Xerox Corporation
12 IBM Printing Systems Co
14 i-data Printing Systems
18 Internet Printing Protocol/1.1: Implementor's Guide
22 This memo provides information for the Internet community. It does
23 not specify an Internet standard of any kind. Distribution of this
28 Copyright (C) The Internet Society (2001). All Rights Reserved.
32 This document is one of a set of documents, which together describe
33 all aspects of a new Internet Printing Protocol (IPP).
37 1 Introduction................................................... 4
38 1.1 Conformance language........................................ 5
39 1.2 Other terminology........................................... 6
40 1.3 Issues Raised from Interoperability Testing Events.......... 6
41 2 IPP Objects.................................................... 6
42 3 IPP Operations................................................. 7
43 3.1 Common Semantics............................................ 7
44 3.1.1 Summary of Operation Attributes............................ 8
45 3.1.2 Suggested Operation Processing Steps for IPP Objects....... 16
46 3.1.2.1 Suggested Operation Processing Steps for all Operations. 17
47 3.1.2.1.1 Validate version number............................... 18
48 3.1.2.1.2 Validate operation identifier......................... 20
49 3.1.2.1.3 Validate the request identifier....................... 20
50 3.1.2.1.4 Validate attribute group and attribute presence and
51 order................................................. 20
52 3.1.2.1.4.1 Validate the presence and order of attribute groups. 20
53 3.1.2.1.4.2 Ignore unknown attribute groups in the expected
54 position............................................ 21
58 Hastings, et al. Informational [Page 1]
60 RFC 3196 Internet Printing Protocol/1.1 November 2001
63 3.1.2.1.4.3 Validate the presence of a single occurrence of
64 required Operation attributes....................... 21
65 3.1.2.1.5 Validate the values of the REQUIRED Operation
66 attributes............................................ 29
67 3.1.2.1.6 Validate the values of the OPTIONAL Operation
68 attributes............................................ 33
69 3.1.2.2 Suggested Additional Processing Steps for Operations
70 that Create/Validate Jobs and Add Documents............. 37
71 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...... 37
72 3.1.2.2.2 Check that the Printer object is accepting jobs....... 38
73 3.1.2.2.3 Validate the values of the Job Template attributes.... 38
74 3.1.2.3 Algorithm for job validation............................ 39
75 3.1.2.3.1 Check for conflicting Job Template attributes values.. 45
76 3.1.2.3.2 Decide whether to REJECT the request.................. 46
77 3.1.2.3.3 For the Validate-Job operation, RETURN one of the
78 success status codes.................................. 48
79 3.1.2.3.4 Create the Job object with attributes to support...... 48
80 3.1.2.3.5 Return one of the success status codes................ 50
81 3.1.2.3.6 Accept appended Document Content...................... 50
82 3.1.2.3.7 Scheduling and Starting to Process the Job............ 50
83 3.1.2.3.8 Completing the Job.................................... 50
84 3.1.2.3.9 Destroying the Job after completion................... 51
85 3.1.2.3.10 Interaction with "ipp-attribute-fidelity"............. 51
86 3.1.2.3.11 Character set code conversion support................. 51
87 3.1.2.3.12 What charset to return when an unsupported charset is
88 requested (Issue 1.19)?....... ....................... 52
89 3.1.2.3.13 Natural Language Override (NLO)....................... 53
90 3.1.3 Status codes returned by operation......................... 55
91 3.1.3.1 Printer Operations...................................... 55
92 3.1.3.1.1 Print-Job............................................. 55
93 3.1.3.1.2 Print-URI............................................. 58
94 3.1.3.1.3 Validate-Job.......................................... 58
95 3.1.3.1.4 Create-Job............................................ 58
96 3.1.3.1.5 Get-Printer-Attributes................................ 59
97 3.1.3.1.6 Get-Jobs.............................................. 60
98 3.1.3.1.7 Pause-Printer......................................... 61
99 3.1.3.1.8 Resume-Printer........................................ 62
100 3.1.3.1.8.1 What about Printers unable to change state due to
101 an error condition?................................. 63
102 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?... 63
103 3.1.3.1.9 Purge-Printer......................................... 63
104 3.1.3.2 Job Operations.......................................... 64
105 3.1.3.2.1 Send-Document......................................... 64
106 3.1.3.2.2 Send-URI.............................................. 65
107 3.1.3.2.3 Cancel-Job............................................ 65
108 3.1.3.2.4 Get-Job-Attributes.................................... 67
109 3.1.3.2.5 Hold-Job.............................................. 68
110 3.1.3.2.6 Release-Job........................................... 69
114 Hastings, et al. Informational [Page 2]
116 RFC 3196 Internet Printing Protocol/1.1 November 2001
119 3.1.3.2.7 Restart-Job........................................... 69
120 3.1.3.2.7.1 Can documents be added to a restarted job?.......... 69
121 3.1.4 Returning unsupported attributes in Get-Xxxx responses
122 (Issue 1.18)............................................... 70
123 3.1.5 Sending empty attribute groups............................. 70
124 3.2 Printer Operations.......................................... 71
125 3.2.1 Print-Job operation........................................ 71
126 3.2.1.1 Flow controlling the data portion of a Print-Job
127 request (Issue 1.22).................................... 71
128 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30).. 71
129 3.2.2 Get-Printer-Attributes operation........................... 72
130 3.2.3 Get-Jobs operation......................................... 72
131 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name'
132 (Issue 1.39)?.......................................... 72
133 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs
134 operation?.............................................. 73
135 3.2.4 Create-Job operation....................................... 73
136 3.3 Job Operations.............................................. 74
137 3.3.1 Validate-Job............................................... 74
138 3.3.2 Restart-Job................................................ 74
139 4 Object Attributes.............................................. 74
140 4.1 Attribute Syntax's.......................................... 74
141 4.1.1 The 'none' value for empty sets (Issue 1.37)............... 74
142 4.1.2 Multi-valued attributes (Issue 1.31)....................... 75
143 4.1.3 Case Sensitivity in URIs (issue 1.6)....................... 75
144 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
145 4.2 Job Template Attributes..................................... 76
146 4.2.1 multiple-document-handling(type2 keyword).................. 76
147 4.2.1.1 Support of multiple document jobs....................... 76
148 4.3 Job Description Attributes.................................. 76
149 4.3.1 Getting the date and time of day........................... 76
150 4.4 Printer Description Attributes.............................. 77
151 4.4.1 queued-job-count (integer(0:MAX)).......................... 77
152 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
153 4.4.1.2 Is "queued-job-count" a good measure of how busy a
154 printer is (Issue 1.15)?................................ 77
155 4.4.2 printer-current-time (dateTime)............................ 78
156 4.4.3 Printer-uri................................................ 78
157 4.5 Empty Jobs.................................................. 79
158 5 Directory Considerations....................................... 79
159 5.1 General Directory Schema Considerations..................... 79
160 5.2 IPP Printer with a DNS name................................. 79
161 6 Security Considerations........................................ 80
162 6.1 Querying jobs with IPP that were submitted using other job
163 submission protocols (Issue 1.32)........................... 80
164 7 Encoding and Transport......................................... 81
165 7.1 General Headers............................................. 83
166 7.2 Request Headers............................................ 84
170 Hastings, et al. Informational [Page 3]
172 RFC 3196 Internet Printing Protocol/1.1 November 2001
175 7.3 Response Headers............................................ 86
176 7.4 Entity Headers............................................. 87
177 7.5 Optional support for HTTP/1.0............................... 88
178 7.6 HTTP/1.1 Chunking........................................... 88
179 7.6.1 Disabling IPP Server Response Chunking..................... 88
180 7.6.2 Warning About the Support of Chunked Requests.............. 88
181 8 References..................................................... 89
182 9 Authors' Addresses............................................. 91
183 10 Description of the Base IPP Documents.......................... 94
184 11 Full Copyright Statement....................................... 96
188 Table 1 - Summary of Printer operation attributes that sender MUST
189 supply ................................................. 8
190 Table 2 - Summary of Printer operation attributes that sender MAY
191 supply ................................................. 10
192 Table 3 - Summary of Job operation attributes that sender MUST
193 supply.................................................. 12
194 Table 4 - Summary of Job operation attributes that sender MAY
195 supply.................................................. 14
196 Table 5 - Printer operation response attributes................... 16
197 Table 6 - Examples of validating IPP version...................... 19
198 Table 7 - Rules for validating single values X against Z.......... 40
202 IPP is an application level protocol that can be used for distributed
203 printing using Internet tools and technologies. This document
204 contains information that supplements the IPP Model and Semantics
205 [RFC2911] and the IPP Transport and Encoding [RFC2910] documents. It
206 is intended to help implementers understand IPP/1.1, as well as
207 IPP/1.0 [RFC2565, RFC2566], and some of the considerations that may
208 assist them in the design of their client and/or IPP object
209 implementation. For example, a typical order of processing requests
210 is given, including error checking. Motivation for some of the
211 specification decisions is also included.
213 This document obsoletes RFC 2639 which was the Implementor's Guide
214 for IPP/1.0. The IPP Implementor's Guide (IIG) (this document)
215 contains information that supplements the IPP Model and Semantics
216 [RFC2911] and the IPP Transport and Encoding [RFC2910] documents.
217 This document is just one of a suite of documents that fully define
218 IPP. The base set of IPP documents includes:
220 Design Goals for an Internet Printing Protocol [RFC2567]
221 Rationale for the Structure and Model and Protocol for the
222 Internet Printing Protocol [RFC2568]
226 Hastings, et al. Informational [Page 4]
228 RFC 3196 Internet Printing Protocol/1.1 November 2001
231 Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
232 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
233 Internet Printing Protocol/1.1: Implementor's Guide (this
235 Mapping between LPD and IPP Protocols [RFC2569]
237 See section 10 for a description of these base IPP documents. Anyone
238 reading these documents for the first time is strongly encouraged to
239 read the IPP documents in the above order.
241 As such the information in this document is not part of the formal
242 specification of IPP/1.1. Instead information is presented to help
243 implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565,
244 RFC2566], including some of the motivation for decisions taken by the
245 committee in developing the specification. Some of the
246 implementation considerations are intended to help implementers
247 design their client and/or IPP object implementations. If there are
248 any contradictions between this document and [RFC2911] or [RFC2910],
249 those documents take precedence over this document.
251 Platform-specific implementation considerations will be included in
252 this guide as they become known.
254 Note: In order to help the reader of the IIG and the IPP Model and
255 Semantics document, the sections in this document parallel the
256 corresponding sections in the Model document and are numbered the
257 same for ease of cross reference. The sections that correspond to
258 the IPP Transport and Encoding are correspondingly offset.
260 1.1 Conformance language
262 Usually, this document does not contain the terminology MUST, MUST
263 NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
264 However, when those terms do appear in this document, their intent is
265 to repeat what the [RFC2911] and [RFC2910] documents require and
266 allow, rather than specifying additional conformance requirements.
267 These terms are defined in section 12 on conformance terminology in
268 [RFC2911], most of which is taken from RFC 2119 [RFC2119].
270 Implementers should read section 12 (APPENDIX A) in [RFC2911] in
271 order to understand these capitalized words. The words MUST, MUST
272 NOT, and REQUIRED indicate what implementations are required to
273 support in a client or IPP object in order to be conformant to
274 [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is
275 merely allowed as an implementer option. The verbs SHOULD and SHOULD
276 NOT indicate suggested behavior, but which is not required or
277 disallowed, respectively, in order to conform to the specification.
282 Hastings, et al. Informational [Page 5]
284 RFC 3196 Internet Printing Protocol/1.1 November 2001
287 1.2 Other terminology
289 This document uses other terms, such as "attributes", "operation",
290 and "Printer" as defined in [RFC2911] section 12. In addition, the
291 term "sender" refers to the client that sends a request or an IPP
292 object that returns a response. The term "receiver" refers to the
293 IPP object that receives a request and to a client that receives a
296 1.3 Issues Raised from Interoperability Testing Events
298 The IPP WG has conducted three open Interoperability Testing Events.
299 The first one was held in September 1998, the second one was held in
300 March 1999, and the third one was held in October 2000. See the
303 ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
305 The issues raised from the first Interoperability Testing Event are
306 numbered 1.n in this document and have been incorporated into
307 "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and
308 Transport" [RFC2565] documents. However, some of the discussion is
309 left here in the Implementor's Guide to help understanding.
311 The issues raised from the second Interoperability Testing Event are
312 numbered 2.n in this document have been incorporated into "IPP/1.1
313 Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and
314 Transport" [RFC2910] documents. However, some of the discussion is
315 left here in the Implementor's Guide to help understanding.
317 The issues raised from the third Interoperability Testing Event are
318 numbered 3.n in this document and are described in:
320 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
323 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
326 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
338 Hastings, et al. Informational [Page 6]
340 RFC 3196 Internet Printing Protocol/1.1 November 2001
345 The term "client" in IPP is intended to mean any client that issues
346 IPP operation requests and accepts IPP operation responses, whether
347 it be a desktop or a server. In other words, the term "client" does
348 not just mean end-user clients, such as those associated with
351 The term "IPP Printer" in IPP is intended to mean an object that
352 accepts IPP operation requests and returns IPP operation responses,
353 whether implemented in a server or a device. An IPP Printer object
354 MAY, if implemented in a server, turn around and forward received
355 jobs (and other requests) to other devices and print
356 servers/services, either using IPP or some other protocol.
360 This section corresponds to Section 3 "IPP Operations" in the
361 IPP/1.1 Model and Semantics document [RFC2911].
365 This section discusses semantics common to all operations.
394 Hastings, et al. Informational [Page 7]
396 RFC 3196 Internet Printing Protocol/1.1 November 2001
399 3.1.1 Summary of Operation Attributes
401 Table 1 - Summary of Printer operation attributes that sender MUST
407 Operation PJ, PU CJ GPA GJ PP, All
408 Attributes VJ (O) (O) (R) (R) RP, Operations
412 Operation parameters--REQUIRED to be supplied by the sender:
414 operation-id R R R R R R
418 request-id R R R R R R R
420 version-number R R R R R R R
422 Operation attributes--REQUIRED to be supplied by the sender:
424 attributes- R R R R R R R
427 attributes- R R R R R R R
450 Hastings, et al. Informational [Page 8]
452 RFC 3196 Internet Printing Protocol/1.1 November 2001
459 Operation PJ, PU CJ GPA GJ PP, All
460 Attributes VJ (O) (O) (R) (R) RP, Operations
465 printer-uri R R R R R R
467 Operation attributes--RECOMMENDED to be supplied by the
472 requesting-user- R R R R R R
477 PJ, VJ: Print-Job, Validate-Job
480 GPA: Get-Printer-Attributes
482 PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
483 R indicates a REQUIRED operation that MUST be supported by the IPP
484 object (Printer or Job). For attributes, R indicates that the
485 attribute MUST be supported by the IPP object that supports the
486 associated operation.
487 O indicates an OPTIONAL operation or attribute that MAY be supported
488 by the IPP object (Printer or Job).
489 + indicates that this is not an IPP/1.0 feature, but is only a part
490 of IPP/1.1 and future versions of IPP.
506 Hastings, et al. Informational [Page 9]
508 RFC 3196 Internet Printing Protocol/1.1 November 2001
511 Table 2 - Summary of Printer operation attributes that sender MAY
518 Operation Attributes PJ, PU CJ GPA GJ PP, All
519 VJ (O) (O) (R) (R) RP, Opera
523 Operation attributes--OPTIONAL to be supplied by the sender:
535 document-format R R R
539 document-natural- O O
545 job-impressions O O O
549 job-media-sheets O O O
562 Hastings, et al. Informational [Page 10]
564 RFC 3196 Internet Printing Protocol/1.1 November 2001
571 Operation Attributes PJ, PU CJ GPA GJ PP, All
572 VJ (O) (O) (R) (R) RP, Opera
582 requested-attributes R R
588 PJ, VJ: Print-Job, Validate-Job
591 GPA: Get-Printer-Attributes
593 PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
594 R indicates a REQUIRED operation that MUST be supported by the IPP
595 object (Printer or Job). For attributes, R indicates that the
596 attribute MUST be supported by the IPP object that supports the
597 associated operation.
598 O indicates an OPTIONAL operation or attribute that MAY be supported
599 by the IPP object (Printer or Job).
600 + indicates that this is not an IPP/1.0 feature, but is only a part
601 of IPP/1.1 and future versions of IPP.
602 * "job-id" is REQUIRED only if used together with "printer-uri" to
603 identify the target job; otherwise, "job-uri" is REQUIRED.
604 ** "document-access-error" applies to the Print-URI response only.
618 Hastings, et al. Informational [Page 11]
620 RFC 3196 Internet Printing Protocol/1.1 November 2001
623 Table 3 - Summary of Job operation attributes that sender MUST supply
628 Operation SD SU CJ GJA HJ All
629 Attributes (O) (O) (R) (R) RJ, RJ Opera-
632 Operation parameters--REQUIRED to be supplied by the sender:
634 operation-id R R R R R
638 request-id R R R R R R
640 version-number R R R R R R
642 Operation attributes--REQUIRED to be supplied by the sender:
644 attributes-charset R R R R R R
646 attributes-natural- R R R R R R
657 printer-uri R R R R R
659 Operation attributes--RECOMMENDED to be supplied by the sender:
674 Hastings, et al. Informational [Page 12]
676 RFC 3196 Internet Printing Protocol/1.1 November 2001
683 Operation SD SU CJ GJA HJ All
684 Attributes (O) (O) (R) (R) RJ, RJ Opera-
687 requesting-user- R R R R R
695 GJA: Get-Job-Attributes
696 HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job
697 R indicates a REQUIRED operation that MUST be supported by the IPP
698 object (Printer or Job). For attributes, R indicates that the
699 attribute MUST be supported by the IPP object that supports the
700 associated operation.
701 O indicates an OPTIONAL operation or attribute that MAY be supported
702 by the IPP object (Printer or Job).
703 + indicates that this is not an IPP/1.0 feature, but is only a part
704 of IPP/1.1 and future versions of IPP.
705 * "job-id" is REQUIRED only if used together with "printer-uri" to
706 identify the target job; otherwise, "job-uri" is REQUIRED.
730 Hastings, et al. Informational [Page 13]
732 RFC 3196 Internet Printing Protocol/1.1 November 2001
735 Table 4 - Summary of Job operation attributes that sender MAY supply
741 Operation SD SU CJ GJA HJ, SD All
742 Attributes (O) (O) (R) (R) RJ, (O) Opera-
746 Operation attributes--OPTIONAL to be supplied by the sender:
762 document-natural- O O
786 Hastings, et al. Informational [Page 14]
788 RFC 3196 Internet Printing Protocol/1.1 November 2001
795 Operation SD SU CJ GJA HJ, SD All
796 Attributes (O) (O) (R) (R) RJ, (O) Opera-
818 GJA: Get-Job-Attributes
819 HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job
820 R indicates a REQUIRED operation that MUST be supported by the IPP
821 object (Printer or Job). For attributes, R indicates that the
822 attribute MUST be supported by the IPP object that supports the
823 associated operation.
824 O indicates an OPTIONAL operation or attribute that MAY be supported
825 by the IPP object (Printer or Job).
826 + indicates that this is not an IPP/1.0 feature, but is only a part
827 of IPP/1.1 and future versions of IPP.
828 * "job-id" is REQUIRED only if used together with "printer-uri" to
829 identify the target job; otherwise, "job-uri" is REQUIRED.
830 ** "document-access-error" applies to the Send-URI operation only
842 Hastings, et al. Informational [Page 15]
844 RFC 3196 Internet Printing Protocol/1.1 November 2001
847 Table 5 - Printer operation response attributes
853 Operation PJ (R) VJ (R) PU (O) CJ (O) GPA GJ (R) PP,
854 Attributes SD (O) SU (O) (R) RP, PP
876 PJ, SJ: Print-Job, Send-Document
878 PU, SU: Print-URI, Send-URI
880 GPA: Get-Printer-Attributes
882 PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
883 R indicates a REQUIRED operation that MUST be supported by the IPP
884 object (Printer or Job). For attributes, R indicates that the
885 attribute MUST be supported by the IPP object that supports the
886 associated operation.
887 O indicates an OPTIONAL operation or attribute that MAY be supported
888 by the IPP object (Printer or Job).
890 3.1.2 Suggested Operation Processing Steps for IPP Objects
892 This section suggests the steps and error checks that an IPP object
893 MAY perform when processing requests and returning responses. An IPP
894 object MAY perform some or all of the error checks. However, some
898 Hastings, et al. Informational [Page 16]
900 RFC 3196 Internet Printing Protocol/1.1 November 2001
903 implementations MAY choose to be more forgiving than the error checks
904 shown here, in order to be able to accept requests from non-
905 conforming clients. Not performing all of these error checks is a
906 so-called "forgiving" implementation. On the other hand, clients
907 that successfully submit requests to IPP objects that do perform all
908 the error checks will be more likely to be able to interoperate with
909 other IPP object implementations. Thus an implementer of an IPP
910 object needs to decide whether to be a "forgiving" or a "strict"
911 implementation. Therefore, the error status codes returned may
912 differ between implementations. Consequentially, client SHOULD NOT
913 expect exactly the error code processing described in this section.
915 When an IPP object receives a request, the IPP object either accepts
916 or rejects the request. In order to determine whether or not to
917 accept or reject the request, the IPP object SHOULD execute the
918 following steps. The order of the steps may be rearranged and/or
919 combined, including making one or multiple passes over the request.
921 A client MUST supply requests that would pass all of the error checks
922 indicated here in order to be a conforming client. Therefore, a
923 client SHOULD supply requests that are conforming, in order to avoid
924 being rejected by some IPP object implementations and/or risking
925 different semantics by different implementations of forgiving
926 implementations. For example, a forgiving implementation that
927 accepts multiple occurrences of the same attribute, rather than
928 rejecting the request might use the first occurrences, while another
929 might use the last occurrence. Thus such a non-conforming client
930 would get different results from the two forgiving implementations.
932 In the following, processing continues step by step until a "RETURNS
933 the xxx status code ..." statement is encountered. Error returns are
934 indicated by the verb: "REJECTS". Since clients have difficulty
935 getting the status code before sending all of the document data in a
936 Print-Job request, clients SHOULD use the Validate-Job operation
937 before sending large documents to be printed, in order to validate
938 whether the IPP Printer will accept the job or not.
940 It is assumed that security authentication and authorization has
941 already taken place at a lower layer.
943 3.1.2.1 Suggested Operation Processing Steps for all Operations
945 This section is intended to apply to all operations. The next
946 section contains the additional steps for the Print-Job, Validate-
947 Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
948 that create jobs, adds documents, and validates jobs.
954 Hastings, et al. Informational [Page 17]
956 RFC 3196 Internet Printing Protocol/1.1 November 2001
959 IIG Sect # Flow IPP error status codes
960 ---------- ---- ----------------------
963 3.1.2.1.1 <Validate version> --> server-error-version-not-
967 3.1.2.1.2 <Validate operation> --> server-error-operation-not-
971 3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
972 3.1.2.1.4.2 <of attributes>
975 3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
979 3.1.2.1.5 <Validate values of> --> client-error-bad-request
980 <operation attrs> client-error-request-value-
982 <(length, tag, range,>
986 3.1.2.1.5 <Validate values> --> client-error-bad-request
987 <with supported values> client-error-charset-not-
989 ok| client-error-attributes-or-
993 3.1.2.1.6 <Validate optionally> --> client-error-bad-request
994 <operation attr> client-error-natural-language-
996 | client-error-request-value-
998 | client-error-attributes-or-
1001 3.1.2.1.1 Validate version number
1003 Every request and every response contains the "version-number"
1004 attribute. The value of this attribute is the major and minor
1005 version number of the syntax and semantics that the client and IPP
1006 object is using, respectively. The "version-number" attribute
1010 Hastings, et al. Informational [Page 18]
1012 RFC 3196 Internet Printing Protocol/1.1 November 2001
1015 remains in a fixed position across all future versions so that all
1016 clients and IPP object that support future versions can determine
1017 which version is being used. The IPP object checks to see if the
1018 major version number supplied in the request is supported. If not,
1019 the Printer object REJECTS the request and RETURNS the 'server-
1020 error-version-not-supported' status code in the response. The IPP
1021 object returns in the "version-number" response attribute the major
1022 and minor version for the error response. Thus the client can learn
1023 at least one major and minor version that the IPP object supports.
1024 The IPP object is encouraged to return the closest version number to
1025 the one supplied by the client.
1027 The checking of the minor version number is implementation dependent,
1028 however if the client-supplied minor version is explicitly supported,
1029 the IPP object MUST respond using that identical minor version
1030 number. If the major version number matches, but the minor version
1031 number does not, the Printer SHOULD accept and attempt to process the
1032 request, or MAY reject the request and return the 'server-error-
1033 version-not-supported' status code. In all cases, the Printer MUST
1034 return the nearest version number that it supports. For example,
1035 suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
1036 The following responses are conforming:
1038 Table 6 - Examples of validating IPP version
1040 Client supplies Printer Accept Request? Printer returns
1043 1.0 yes (SHOULD) 1.1
1045 1.0 no (SHOULD NOT) 1.1
1051 1.3 yes (SHOULD) 1.2
1053 1.3 no (SHOULD NOT) 1.2
1055 It is advantageous for Printers to support both IPP/1.1 and IPP/1.0,
1056 so that they can interoperate with either client implementations.
1057 Some implementations may allow an Administrator to explicitly disable
1058 support for one or the other by setting the "ipp-versions-supported"
1059 Printer description attribute.
1066 Hastings, et al. Informational [Page 19]
1068 RFC 3196 Internet Printing Protocol/1.1 November 2001
1071 Likewise, it is advantageous for clients to support both versions to
1072 allow interoperability with new and legacy Printers.
1074 3.1.2.1.2 Validate operation identifier
1076 The Printer object checks to see if the "operation-id" attribute
1077 supplied by the client is supported as indicated in the Printer
1078 object's "operations-supported" attribute. If not, the Printer
1079 REJECTS the request and returns the 'server-error-operation-not-
1080 supported' status code in the response.
1082 3.1.2.1.3 Validate the request identifier
1084 The Printer object SHOULD NOT check to see if the "request-id"
1085 attribute supplied by the client is in range: between 1 and 2**31 - 1
1086 (inclusive), but copies all 32 bits.
1088 Note: The "version-number", "operation-id", and the "request-id"
1089 parameters are in fixed octet positions in the IPP/1.1 encoding. The
1090 "version-number" parameter will be the same fixed octet position in
1091 all versions of the protocol. These fields are validated before
1092 proceeding with the rest of the validation.
1094 3.1.2.1.4 Validate attribute group and attribute presence and order
1096 The order of the following validation steps depends on
1099 3.1.2.1.4.1 Validate the presence and order of attribute groups
1101 Client requests and IPP object responses contain attribute groups
1102 that Section 3 requires to be present and in a specified order. An
1103 IPP object verifies that the attribute groups are present and in the
1104 correct order in requests supplied by clients (attribute groups
1105 without an * in the following tables).
1107 If an IPP object receives a request with (1) required attribute
1108 groups missing, or (2) the attributes groups are out of order, or (3)
1109 the groups are repeated, the IPP object REJECTS the request and
1110 RETURNS the 'client-error-bad-request' status code. For example, it
1111 is an error for the Job Template Attributes group to occur before the
1112 Operation Attributes group, for the Operation Attributes group to be
1113 omitted, or for an attribute group to occur more than once, except in
1114 the Get-Jobs response.
1116 Since this kind of attribute group error is most likely to be an
1117 error detected by a client developer rather than by a customer, the
1118 IPP object NEED NOT return an indication of which attribute group was
1122 Hastings, et al. Informational [Page 20]
1124 RFC 3196 Internet Printing Protocol/1.1 November 2001
1127 in error in either the Unsupported Attributes group or the Status
1128 Message. Also, the IPP object NEED NOT find all attribute group
1129 errors before returning this error.
1131 3.1.2.1.4.2 Ignore unknown attribute groups in the expected position
1133 Future attribute groups may be added to the specification at the end
1134 of requests just before the Document Content and at the end of
1135 response, except for the Get-Jobs response, where it maybe there or
1136 before the first job attributes returned. If an IPP object receives
1137 an unknown attribute group in these positions, it ignores the entire
1138 group, rather than returning an error, since that group may be a new
1139 group in a later minor version of the protocol that can be ignored.
1140 (If the new attribute group cannot be ignored without confusing the
1141 client, the major version number would have been increased in the
1142 protocol document and in the request). If the unknown group occurs
1143 in a different position, the IPP object REJECTS the request and
1144 RETURNS the 'client-error-bad-request' status code.
1146 Clients also ignore unknown attribute groups returned in a response.
1148 Note: By validating that requests are in the proper form, IPP
1149 objects force clients to use the proper form which, in turn,
1150 increases the chances that customers will be able to use such clients
1151 from multiple vendors with IPP objects from other vendors.
1153 3.1.2.1.4.3 Validate the presence of a single occurrence of required
1154 Operation attributes
1156 Client requests and IPP object responses contain Operation attributes
1157 that [RFC2911] Section 3 requires to be present. Attributes within a
1158 group may be in any order, except for the ordering of target,
1159 charset, and natural languages attributes. These attributes MUST be
1160 first, and MUST be supplied in the following order: charset, natural
1161 language, and then target. An IPP object verifies that the
1162 attributes that Section 4 requires to be supplied by the client have
1163 been supplied in the request (attributes without an * in the
1164 following tables). An asterisk (*) indicates groups and Operation
1165 attributes that the client may omit in a request or an IPP object may
1168 If an IPP object receives a request with required attributes missing
1169 or repeated from a group or in the wrong position, the behavior of
1170 the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible
1171 implementations are:
1173 REJECTS the request and RETURNS the 'client-error-bad-request'
1178 Hastings, et al. Informational [Page 21]
1180 RFC 3196 Internet Printing Protocol/1.1 November 2001
1183 accepts the request and uses the first occurrence of the attribute
1184 no matter where it is
1186 accepts the request and uses the last occurrence of the attribute
1187 no matter where it is
1189 accept the request and assume some default value for the missing
1192 Therefore, client MUST send conforming requests, if they want to
1193 receive the same behavior from all IPP object implementations. For
1194 example, it is an error for the "attributes-charset" or "attributes-
1195 natural-language" attribute to be omitted in any operation request,
1196 or for an Operation attribute to be supplied in a Job Template group
1197 or a Job Template attribute to be supplied in an Operation Attribute
1198 group in a create request. It is also an error to supply the
1199 "attributes-charset" attribute twice.
1201 Since these kinds of attribute errors are most likely to be detected
1202 by a client developer rather than by a customer, the IPP object NEED
1203 NOT return an indication of which attribute was in error in either
1204 the Unsupported Attributes group or the Status Message. Also, the
1205 IPP object NEED NOT find all attribute errors before returning this
1208 The following tables list all the attributes for all the operations
1209 by attribute group in each request and each response. The order of
1210 the groups is the order that the client supplies the groups as
1211 specified in [RFC2911] Section 3. The order of the attributes within
1212 a group is arbitrary, except as noted for some of the special
1213 operation attributes (charset, natural language, and target). The
1214 tables below use the following notation:
1216 R indicates a REQUIRED attribute or operation that an IPP
1218 O indicates an OPTIONAL attribute or operation that an IPP
1219 object NEED NOT support
1220 * indicates that a client MAY omit the attribute in a request
1221 and that an IPP object MAY omit the attribute in a response.
1222 The absence of an * means that a client MUST supply the
1223 attribute in a request and an IPP object MUST supply the
1224 attribute in a response.
1225 + indicates that this is not a IPP/1.0 operation, but is only
1226 a part of IPP/1.1 and future versions of IPP.
1234 Hastings, et al. Informational [Page 22]
1236 RFC 3196 Internet Printing Protocol/1.1 November 2001
1241 The tables below show the attributes in their proper attribute groups
1242 for operation requests:
1244 Note: All operation requests contain "version-number", "operation-
1245 id", and "request-id" parameters.
1247 Print-Job Request (R):
1248 Group 1: Operation Attributes (R)
1249 attributes-charset (R)
1250 attributes-natural-language (R)
1252 requesting-user-name (R*)
1254 ipp-attribute-fidelity (R*)
1256 document-format (R*)
1257 document-natural-language (O*)
1260 job-impressions (O*)
1261 job-media-sheets (O*)
1262 Group 2: Job Template Attributes (R*)
1263 <Job Template attributes> (O*)
1264 (see [RFC2911] Section 4.2)
1265 Group 3: Document Content (R)
1268 Validate-Job Request (R):
1269 Group 1: Operation Attributes (R)
1270 attributes-charset (R)
1271 attributes-natural-language (R)
1273 requesting-user-name (R*)
1275 ipp-attribute-fidelity (R*)
1277 document-format (R*)
1278 document-natural-language (O*)
1281 job-impressions (O*)
1282 job-media-sheets (O*)
1283 Group 2: Job Template Attributes (R*)
1284 <Job Template attributes> (O*)
1285 (see [RFC2911] Section 4.2)
1290 Hastings, et al. Informational [Page 23]
1292 RFC 3196 Internet Printing Protocol/1.1 November 2001
1295 Print-URI Request (O):
1296 Group 1: Operation Attributes (R)
1297 attributes-charset (R)
1298 attributes-natural-language (R)
1301 requesting-user-name (R*)
1303 ipp-attribute-fidelity (R*)
1305 document-format (R*)
1306 document-natural-language (O*)
1309 job-impressions (O*)
1310 job-media-sheets (O*)
1311 Group 2: Job Template Attributes (R*)
1312 <Job Template attributes> (O*) (see
1313 (see [RFC2911] Section 4.2)
1315 Create-Job Request (O):
1316 Group 1: Operation Attributes (R)
1317 attributes-charset (R)
1318 attributes-natural-language (R)
1320 requesting-user-name (R*)
1322 ipp-attribute-fidelity (R*)
1324 job-impressions (O*)
1325 job-media-sheets (O*)
1326 Group 2: Job Template Attributes (R*)
1327 <Job Template attributes> (O*) (see
1328 (see [RFC2911] Section 4.2)
1330 Get-Printer-Attributes Request (R):
1331 Group 1: Operation Attributes (R)
1332 attributes-charset (R)
1333 attributes-natural-language (R)
1335 requesting-user-name (R*)
1336 requested-attributes (R*)
1337 document-format (R*)
1339 Get-Jobs Request (R):
1340 Group 1: Operation Attributes (R)
1341 attributes-charset (R)
1342 attributes-natural-language (R)
1346 Hastings, et al. Informational [Page 24]
1348 RFC 3196 Internet Printing Protocol/1.1 November 2001
1352 requesting-user-name (R*)
1354 requested-attributes (R*)
1358 Send-Document Request (O):
1359 Group 1: Operation Attributes (R)
1360 attributes-charset (R)
1361 attributes-natural-language (R)
1362 (printer-uri & job-id) | job-uri (R)
1364 requesting-user-name (R*)
1366 document-format (R*)
1367 document-natural-language (O*)
1369 Group 2: Document Content (R*)
1372 Send-URI Request (O):
1373 Group 1: Operation Attributes (R)
1374 attributes-charset (R)
1375 attributes-natural-language (R)
1376 (printer-uri & job-id) | job-uri (R)
1379 requesting-user-name (R*)
1381 document-format (R*)
1382 document-natural-language (O*)
1385 Cancel-Job Request (R):
1386 Release-Job Request (O+):
1387 Group 1: Operation Attributes (R)
1388 attributes-charset (R)
1389 attributes-natural-language (R)
1390 (printer-uri & job-id) | job-uri (R)
1391 requesting-user-name (R*)
1402 Hastings, et al. Informational [Page 25]
1404 RFC 3196 Internet Printing Protocol/1.1 November 2001
1407 Get-Job-Attributes Request (R):
1408 Group 1: Operation Attributes (R)
1409 attributes-charset (R)
1410 attributes-natural-language (R)
1411 (printer-uri & job-id) | job-uri (R)
1412 requesting-user-name (R*)
1413 requested-attributes (R*)
1415 Pause-Printer Request (O+):
1416 Resume-Printer Request (O+):
1417 Purge-Printer Request (O+):
1418 Group 1: Operation Attributes (R)
1419 attributes-charset (R)
1420 attributes-natural-language (R)
1422 requesting-user-name (R*)
1424 Hold-Job Request (O+):
1425 Restart-Job Request (O+):
1426 Group 1: Operation Attributes (R)
1427 attributes-charset (R)
1428 attributes-natural-language (R)
1429 (printer-uri & job-id) | job-uri (R)
1430 requesting-user-name (R*)
1436 The tables below show the response attributes in their proper
1437 attribute groups for responses.
1439 Note: All operation responses contain "version-number", "status-
1440 code", and "request-id" parameters.
1442 Print-Job Response (R):
1443 Create-Job Response (O):
1444 Send-Document Response (O):
1445 Group 1: Operation Attributes (R)
1446 attributes-charset (R)
1447 attributes-natural-language (R)
1449 detailed-status-message (O*)
1450 Group 2: Unsupported Attributes (R*) (see Note 3)
1451 n <unsupported attributes> (R*)
1452 Group 3: Job Object Attributes(R*) (see Note 2)
1458 Hastings, et al. Informational [Page 26]
1460 RFC 3196 Internet Printing Protocol/1.1 November 2001
1464 job-state-reasons (O* | R+)
1465 job-state-message (O*)
1466 number-of-intervening-jobs (O*)
1468 Validate-Job Response (R):
1469 Cancel-Job Response (R):
1470 Hold-Job Response (O+):
1471 Release-Job Response (O+):
1472 Restart-Job Response (O+):
1473 Group 1: Operation Attributes (R)
1474 attributes-charset (R)
1475 attributes-natural-language (R)
1477 detailed-status-message (O*)
1478 Group 2: Unsupported Attributes (R*) (see Note 3)
1479 <unsupported attributes> (R*)
1481 Print-URI Response (O):
1482 Send-URI Response (O):
1483 Group 1: Operation Attributes (R)
1484 attributes-charset (R)
1485 attributes-natural-language (R)
1487 detailed-status-message (O*)
1488 document-access-error (O*)
1489 Group 2: Unsupported Attributes (R*) (see Note 3)
1490 <unsupported attributes> (R*)
1491 Group 3: Job Object Attributes(R*) (see Note 2)
1495 job-state-reasons (O* | R+)
1496 job-state-message (O*)
1497 number-of-intervening-jobs (O*)
1499 Get-Printer-Attributes Response (R):
1500 Group 1: Operation Attributes (R)
1501 attributes-charset (R)
1502 attributes-natural-language (R)
1504 detailed-status-message (O*)
1505 Group 2: Unsupported Attributes (R*) (see Note 4)
1506 <unsupported attributes> (R*)
1507 Group 3: Printer Object Attributes(R*) (see Note 2)
1508 <requested attributes> (R*)
1514 Hastings, et al. Informational [Page 27]
1516 RFC 3196 Internet Printing Protocol/1.1 November 2001
1519 Get-Jobs Response (R):
1520 Group 1: Operation Attributes (R)
1521 attributes-charset (R)
1522 attributes-natural-language (R)
1524 detailed-status-message (O*)
1525 Group 2: Unsupported Attributes (R*) (see Note 4)
1526 <unsupported attributes> (R*)
1527 Group 3: Job Object Attributes(R*) (see Note 2, 5)
1528 <requested attributes> (R*)
1530 Get-Job-Attributes Response (R):
1531 Group 1: Operation Attributes (R)
1532 attributes-charset (R)
1533 attributes-natural-language (R)
1535 detailed-status-message (O*)
1536 Group 2: Unsupported Attributes (R*) (see Note 4)
1537 <unsupported attributes> (R*)
1538 Group 3: Job Object Attributes(R*) (see Note 2)
1539 <requested attributes> (R*)
1541 Pause-Printer Response (O+):
1542 Resume-Printer Response (O+):
1543 Purge-Printer Response (O+):
1544 Group 1: Operation Attributes (R)
1545 attributes-charset (R)
1546 attributes-natural-language (R)
1548 detailed-status-message (O*)
1549 Group 2: Unsupported Attributes (R*) (see Note 4)
1550 <unsupported attributes> (R*)
1552 Note 2 - the Job Object Attributes and Printer Object Attributes are
1553 returned only if the IPP object returns one of the success status
1556 Note 3 - the Unsupported Attributes Group is present only if the
1557 client included some Operation and/or Job Template attributes or
1558 values that the Printer doesn't support whether a success or an error
1561 Note 4 - the Unsupported Attributes Group is present only if the
1562 client included some Operation attributes that the Printer doesn't
1563 support whether a success or an error return.
1570 Hastings, et al. Informational [Page 28]
1572 RFC 3196 Internet Printing Protocol/1.1 November 2001
1575 Note 5: for the Get-Jobs operation the response contains a separate
1576 Job Object Attributes group 3 to N containing requested-attributes
1577 for each job object in the response.
1579 3.1.2.1.5 Validate the values of the REQUIRED Operation attributes
1581 An IPP object validates the values supplied by the client of the
1582 REQUIRED Operation attribute that the IPP object MUST support. The
1583 next section specifies the validation of the values of the OPTIONAL
1584 Operation attributes that IPP objects MAY support.
1586 The IPP object performs the following syntactic validation checks of
1587 each Operation attribute value:
1589 a) that the length of each Operation attribute value is correct
1590 for the attribute syntax tag supplied by the client according
1591 to [RFC2911] Section 4.1,
1593 b) that the attribute syntax tag is correct for that Operation
1594 attribute according to [RFC2911] Section 3,
1596 c) that the value is in the range specified for that Operation
1597 attribute according to [RFC2911] Section 3,
1599 d) that multiple values are supplied by the client only for
1600 operation attributes that are multi-valued, i.e., that are
1601 1setOf X according to [RFC2911] Section 3.
1603 If any of these checks fail, the IPP object REJECTS the request and
1604 RETURNS the 'client-error-bad-request' or the 'client-error-request-
1605 value-too-long' status code. Since such an error is most likely to
1606 be an error detected by a client developer, rather than by an end-
1607 user, the IPP object NEED NOT return an indication of which attribute
1608 had the error in either the Unsupported Attributes Group or the
1609 Status Message. The description for each of these syntactic checks
1610 is explicitly expressed in the first IF statement in the following
1613 In addition, the IPP object checks each Operation attribute value
1614 against some Printer object attribute or some hard-coded value if
1615 there is no "xxx-supported" Printer object attribute defined. If its
1616 value is not among those supported or is not in the range supported,
1617 then the IPP object REJECTS the request and RETURNS the error status
1618 code indicated in the table by the second IF statement. If the value
1619 of the Printer object's "xxx-supported" attribute is 'no-value'
1620 (because the system administrator hasn't configured a value), the
1626 Hastings, et al. Informational [Page 29]
1628 RFC 3196 Internet Printing Protocol/1.1 November 2001
1631 -----------------------------------------------
1633 attributes-charset (charset)
1635 IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
1638 IF the value length is greater than 63 octets, REJECT/RETURN
1639 'client-error-request-value-too-long'.
1641 IF NOT in the Printer object's "charset-supported" attribute,
1642 REJECT/RETURN "client-error-charset-not-supported".
1644 attributes-natural-language(naturalLanguage)
1646 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
1647 'client-error-bad-request'.
1649 IF the value length is greater than 63 octets, REJECT/RETURN
1650 'client-error-request-value-too-long'.
1652 ACCEPT the request even if not a member of the set in the Printer
1653 object's "generated-natural-language-supported" attribute. If the
1654 supplied value is not a member of the Printer object's
1655 "generated-natural-language-supported" attribute, use the Printer
1656 object's "natural-language- configured" value.
1658 requesting-user-name
1660 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1663 IF the value length is greater than 255 octets, REJECT/RETURN
1664 'client-error-request-value-too-long'.
1666 IF the IPP object can obtain a better-authenticated name, use it
1671 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1674 IF the value length is greater than 255 octets, REJECT/RETURN
1675 'client-error-request-value-too-long'.
1677 IF NOT supplied by the client, the Printer object creates a name
1678 from the document-name or document-uri.
1682 Hastings, et al. Informational [Page 30]
1684 RFC 3196 Internet Printing Protocol/1.1 November 2001
1687 document-name (name)
1689 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1692 IF the value length is greater than 255 octets, REJECT/RETURN
1693 'client-error-request-value-too-long'.
1695 ipp-attribute-fidelity (boolean)
1697 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1698 REJECT/RETURN 'client-error-bad-request'.
1700 IF the value length is NOT equal to 1 octet, REJECT/RETURN
1701 'client-error-request-value-too-long'
1703 IF NOT supplied by the client, the IPP object assumes the value
1706 document-format (mimeMediaType)
1708 IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
1709 'client-error-bad-request'.
1711 IF the value length is greater than 255 octets, REJECT/RETURN
1712 'client-error-request-value-too-long'.
1714 IF NOT in the Printer object's "document-format-supported"
1715 attribute, REJECT/RETURN 'client-error-document-format-not-
1718 IF NOT supplied by the client, the IPP object assumes the value of
1719 the Printer object's "document-format-default" attribute.
1723 IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
1726 IF the value length is greater than 1023 octets, REJECT/RETURN
1727 'client-error-request-value-too-long'.
1729 IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
1732 If the client-supplied URI scheme is not supported, i.e., the
1733 value is not in the Printer object's referenced-uri-scheme-
1734 supported" attribute, the Printer object MUST reject the request
1738 Hastings, et al. Informational [Page 31]
1740 RFC 3196 Internet Printing Protocol/1.1 November 2001
1743 and return the 'client-error-uri-scheme-not-supported' status
1744 code. The Printer object MAY check to see if the document exists
1745 and is accessible. If the document is not found or is not
1746 accessible, REJECT/RETURN 'client-error-not found'.
1748 last-document (boolean)
1750 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1751 REJECT/RETURN 'client-error-bad-request'.
1753 IF the value length is NOT equal to 1 octet, REJECT/RETURN
1754 'client-error-request-value-too-long'
1756 job-id (integer(1:MAX))
1758 IF NOT an single 'integer' value equal to 4 octets AND in the
1759 range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
1761 IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
1762 error-not-found' or 'client-error-gone' status code, if keep track
1763 of recently deleted jobs.
1765 requested-attributes (1setOf keyword)
1767 IF NOT one or more 'keyword' values, REJECT/RETURN 'client-
1770 IF the value length is greater than 255 octets, REJECT/RETURN
1771 'client-error-request-value-too-long'.
1773 Ignore unsupported values, which are the keyword names of
1774 unsupported attributes. Don't bother to copy such requested
1775 (unsupported) attributes to the Unsupported Attribute response
1776 group since the response will not return them.
1778 which-jobs (type2 keyword)
1780 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
1783 IF the value length is greater than 255 octets, REJECT/RETURN
1784 'client-error-request-value-too-long'.
1786 IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
1787 the unsupported value to the Unsupported Attributes response group
1788 and REJECT/RETURN 'client-error-attributes-or-values-not-
1794 Hastings, et al. Informational [Page 32]
1796 RFC 3196 Internet Printing Protocol/1.1 November 2001
1799 Note: a Printer still supports the 'completed' value even if it
1800 keeps no completed/canceled/aborted jobs: by returning no jobs
1803 IF NOT supplied by the client, the IPP object assumes the 'not-
1808 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1809 REJECT/RETURN 'client-error-bad-request'.
1811 IF the value length is NOT equal to 1 octet, REJECT/RETURN
1812 'client-error-request-value-too-long'
1814 IF NOT supplied by the client, the IPP object assumes the 'false'
1817 limit (integer(1:MAX))
1819 IF NOT a single 'integer' value equal to 4 octets AND in the range
1820 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
1822 IF NOT supplied by the client, the IPP object returns all jobs, no
1825 -----------------------------------------------
1827 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes
1829 OPTIONAL Operation attributes are those that an IPP object MAY
1830 support. An IPP object validates the values of the OPTIONAL
1831 attributes supplied by the client. The IPP object performs the same
1832 syntactic validation checks for each OPTIONAL attribute value as in
1833 Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP
1834 object REJECTS the request and RETURNS the 'client-error-bad-request'
1835 or the 'client-error-request-value-too-long' status code.
1837 In addition, the IPP object checks each Operation attribute value
1838 against some Printer attribute or some hard-coded value if there is
1839 no "xxx-supported" Printer attribute defined. If its value is not
1840 among those supported or is not in the range supported, then the IPP
1841 object REJECTS the request and RETURNS the error status code
1842 indicated in the table. If the value of the Printer object's "xxx-
1843 supported" attribute is 'no-value' (because the system administrator
1844 hasn't configured a value), the check always fails.
1850 Hastings, et al. Informational [Page 33]
1852 RFC 3196 Internet Printing Protocol/1.1 November 2001
1855 If the IPP object doesn't recognize/support an attribute, the IPP
1856 object treats the attribute as an unknown or unsupported attribute
1857 (see the last row in the table below).
1859 -----------------------------------------------
1861 document-natural-language (naturalLanguage)
1863 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
1864 'client-error-bad-request'.
1866 IF the value length is greater than 63 octets, REJECT/RETURN
1867 'client-error-request-value-too-long'.
1869 IF NOT a value that the Printer object supports in document
1870 formats, (no corresponding "xxx-supported" Printer attribute),
1871 REJECT/RETURN 'client-error-natural-language-not-supported'.
1873 compression (type3 keyword)
1875 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
1878 IF the value length is greater than 255 octets, REJECT/RETURN
1879 'client-error-request-value-too-long'.
1881 IF NOT in the Printer object's "compression-supported" attribute,
1882 REJECT/RETURN 'client-error-compression-not-supported'.
1884 Note to IPP/1.0 implementers: Support for the "compression"
1885 attribute was optional in IPP/1.0 and was changed to REQUIRED in
1886 IPP/1.1. However, an IPP/1.0 object SHOULD at least check for the
1887 "compression" attribute being present and reject the create
1888 request, if they don't support "compression". Not checking is a
1889 bug, since the data will be unintelligible.
1891 job-k-octets (integer(0:MAX))
1893 IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
1894 'client-error-bad-request'.
1896 IF NOT in the range of the Printer object's "job-k-octets-
1897 supported" attribute, copy the attribute and the unsupported value
1898 to the Unsupported Attributes response group and REJECT/RETURN
1899 'client-error-attributes-or-values-not-supported'.
1906 Hastings, et al. Informational [Page 34]
1908 RFC 3196 Internet Printing Protocol/1.1 November 2001
1911 job-impressions (integer(0:MAX))
1913 IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
1914 'client-error-bad-request'.
1916 IF NOT in the range of the Printer object's "job-impressions-
1917 supported" attribute, copy the attribute and the unsupported value
1918 to the Unsupported Attributes response group and REJECT/RETURN
1919 'client-error-attributes-or-values-not-supported'.
1921 job-media-sheets (integer(0:MAX))
1923 IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
1924 'client-error-bad-request'.
1926 IF NOT in the range of the Printer object's "job-media-sheets-
1927 supported" attribute, copy the attribute and the unsupported value
1928 to the Unsupported Attributes response group and REJECT/RETURN
1929 'client-error-attributes-or-values-not-supported'.
1933 IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
1936 IF the value length is greater than 127 octets, REJECT/RETURN
1937 'client-error-request-value-too-long'.
1939 unknown or unsupported attribute
1941 IF the attribute syntax supplied by the client is supported but
1942 the length is not legal for that attribute syntax, REJECT/RETURN
1943 'client-error-request-value-too-long'.
1945 ELSE copy the attribute and value to the Unsupported Attributes
1946 response group and change the attribute value to the "out-of-band"
1947 'unsupported' value, but otherwise ignore the attribute.
1949 Note: Future Operation attributes may be added to the protocol
1950 specification that may occur anywhere in the specified group. When
1951 the operation is otherwise successful, the IPP object returns the
1952 'successful-ok-ignored-or-substituted-attributes' status code.
1953 Ignoring unsupported Operation attributes in all operations is
1954 analogous to the handling of unsupported Job Template attributes in
1955 the create and Validate-Job operations when the client supplies the
1956 "ipp-attribute-fidelity" Operation attribute with the 'false' value.
1957 This last rule is so that we can add OPTIONAL Operation attributes to
1958 future versions of IPP so that older clients can inter-work with new
1962 Hastings, et al. Informational [Page 35]
1964 RFC 3196 Internet Printing Protocol/1.1 November 2001
1967 IPP objects and newer clients can inter-work with older IPP objects.
1968 (If the new attribute cannot be ignored without performing
1969 unexpectedly, the major version number would have been increased in
1970 the protocol document and in the request). This rule for Operation
1971 attributes is independent of the value of the "ipp-attribute-
1972 fidelity" attribute. For example, if an IPP object doesn't support
1973 the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-
1974 k-octets" as an unknown attribute and only checks the length for the
1975 'integer' attribute syntax supplied by the client. If it is not four
1976 octets, the IPP object REJECTS the request and RETURNS the 'client-
1977 error-bad-request' status code, else the IPP object copies the
1978 attribute to the Unsupported Attribute response group, setting the
1979 value to the "out-of-band" 'unsupported' value, but otherwise ignores
2018 Hastings, et al. Informational [Page 36]
2020 RFC 3196 Internet Printing Protocol/1.1 November 2001
2023 3.1.2.2 Suggested Additional Processing Steps for Operations that
2024 Create/Validate Jobs and Add Documents
2026 This section in combination with the previous section recommends the
2027 processing steps for the Print-Job, Validate-Job, Print-URI, Create-
2028 Job, Send-Document, and Send-URI operations that IPP objects SHOULD
2029 use. These are the operations that create jobs, validate a Print-Job
2030 request, and add documents to a job.
2032 IIG Sect # Flow IPP error status codes
2033 ---------- ---- ----------------------
2036 3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
2039 | ipp-attribute-fidelity = no |
2040 |<------------------------------+
2042 3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
2046 3.1.2.3 <Validate values of> --> client-error-bad-request
2047 <Job template attributes> client-error-request-value-too-
2049 <(length, tag, range,>
2053 3.1.2.3 <Validate values with> --> client-error-bad-request
2054 <supported values> client-error-attributes-or-
2055 | values-not-supported
2057 3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
2059 <Job Template attr values> client-error-attributes-or-
2060 values-not-supported
2063 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied
2065 The Printer object checks to see if the client supplied an "ipp-
2066 attribute-fidelity" Operation attribute. If the attribute is not
2067 supplied by the client, the IPP object assumes that the value is
2074 Hastings, et al. Informational [Page 37]
2076 RFC 3196 Internet Printing Protocol/1.1 November 2001
2079 3.1.2.2.2 Check that the Printer object is accepting jobs
2081 If the value of the Printer objects "printer-is-accepting-jobs" is
2082 'false', the Printer object REJECTS the request and RETURNS the
2083 'server-error-not-accepting-jobs' status code.
2085 3.1.2.2.3 Validate the values of the Job Template attributes
2087 An IPP object validates the values of all Job Template attribute
2088 supplied by the client. The IPP object performs the analogous
2089 syntactic validation checks of each Job Template attribute value that
2090 it performs for Operation attributes (see Section 3.1.2.1.5.):
2092 a) that the length of each value is correct for the attribute
2093 syntax tag supplied by the client according to [RFC2911]
2096 b) that the attribute syntax tag is correct for that attribute
2097 according to [RFC2911] Sections 4.2 to 4.4.
2099 c) that multiple values are supplied only for multi-valued
2100 attributes, i.e., that are 1setOf X according to [RFC2911]
2101 Sections 4.2 to 4.4.
2103 As in Section 3.1.2.1.5, if any of these syntactic checks fail, the
2104 IPP object REJECTS the request and RETURNS the 'client-error-bad-
2105 request' or 'client-error-request-value-too-long' status code as
2106 appropriate, independent of the value of the "ipp-attribute-
2107 fidelity". Since such an error is most likely to be an error
2108 detected by a client developer, rather than by an end-user, the IPP
2109 object NEED NOT return an indication of which attribute had the error
2110 in either the Unsupported Attributes Group or the Status Message.
2111 The description for each of these syntactic checks is explicitly
2112 expressed in the first IF statement in the following table.
2114 Each Job Template attribute MUST occur no more than once. If an IPP
2115 Printer receives a create request with multiple occurrences of a Job
2116 Template attribute, it MAY:
2118 1. reject the operation and return the 'client-error-bad-request'
2121 2. accept the operation and use the first occurrence of the
2124 3. accept the operation and use the last occurrence of the
2130 Hastings, et al. Informational [Page 38]
2132 RFC 3196 Internet Printing Protocol/1.1 November 2001
2135 depending on implementation. Therefore, clients MUST NOT supply
2136 multiple occurrences of the same Job Template attribute in the Job
2137 Attributes group in the request.
2139 3.1.2.3 Algorithm for job validation
2141 The process of validating a Job-Template attribute "xxx" against a
2142 Printer attribute "xxx-supported" can use the following validation
2143 algorithm (see section 3.2.1.2 in [RFC2911]).
2145 To validate the value U of Job-Template attribute "xxx" against the
2146 value V of Printer "xxx-supported", perform the following algorithm:
2148 1. If U is multi-valued, validate each value X of U by performing the
2149 algorithm in Table 7 with each value X. Each validation is
2150 separate from the standpoint of returning unsupported values.
2151 Example: If U is "finishings" that the client supplies with
2152 'staple', 'bind' values, then X takes on the successive values:
2153 'staple', then 'bind'
2155 2. If V is multi-valued, validate X against each Z of V by performing
2156 the algorithm in Table 7 with each value Z. If a value Z
2157 validates, the validation for the attribute value X succeeds. If
2158 it fails, the algorithm is applied to the next value Z of V. If
2159 there are no more values Z of V, validation fails. Example" If V
2160 is "sides-supported" with values: 'one- sided', 'two-sided-long',
2161 and 'two-sided-short', then Z takes on the successive values:
2162 'one-sided', 'two-sided-long', and 'two-sided-short'. If the
2163 client supplies "sides" with 'two-sided- long', the first
2164 comparison fails ('one-sided' is not equal to 'two-sided-long'),
2165 the second comparison succeeds ('two-sided-long' is equal to
2166 'two-sided-long"), and the third comparison ('two-sided-short'
2167 with 'two-sided-long') is not even performed.
2169 3. If both U and V are single-valued, let X be U and Z be V and use
2170 the validation rules in Table 7.
2186 Hastings, et al. Informational [Page 39]
2188 RFC 3196 Internet Printing Protocol/1.1 November 2001
2191 Table 7 - Rules for validating single values X against Z
2193 Attribute syntax attribute syntax validated if:
2196 integer rangeOfInteger X is within the range of Z
2198 uri uriScheme the uri scheme in X is equal to
2201 any boolean the value of Z is TRUE
2203 any any X and Z are of the same type
2206 If the value of the Printer object's "xxx-supported" attribute is
2207 'no-value' (because the system administrator hasn't configured a
2208 value), the check always fails. If the check fails, the IPP object
2209 copies the attribute to the Unsupported Attributes response group
2210 with its unsupported value. If the attribute contains more than one
2211 value, each value is checked and each unsupported value is separately
2212 copied, while supported values are not copied. If an IPP object
2213 doesn't recognize/support a Job Template attribute, i.e., there is no
2214 corresponding Printer object "xxx-supported" attribute, the IPP
2215 object treats the attribute as an unknown or unsupported attribute
2216 (see the last row in the table below).
2218 If some Job Template attributes are supported for some document
2219 formats and not for others or the values are different for different
2220 document formats, the IPP object SHOULD take that into account in
2221 this validation using the value of the "document-format" supplied by
2222 the client (or defaulted to the value of the Printer's "document-
2223 format-default" attribute, if not supplied by the client). For
2224 example, if "number-up" is supported for the 'text/plain' document
2225 format, but not for the 'application/postscript' document format, the
2226 check SHOULD (though it NEED NOT) depend on the value of the
2227 "document-format" operation attribute. See "document-format" in
2228 [RFC2911] section 3.2.1.1 and 3.2.5.1.
2230 Note: whether the request is accepted or rejected is determined by
2231 the value of the "ipp-attribute-fidelity" attribute in a subsequent
2232 step, so that all Job Template attribute supplied are examined and
2233 all unsupported attributes and/or values are copied to the
2234 Unsupported Attributes response group.
2236 -----------------------------------------------
2242 Hastings, et al. Informational [Page 40]
2244 RFC 3196 Internet Printing Protocol/1.1 November 2001
2247 job-priority (integer(1:100))
2249 IF NOT a single 'integer' value with a length equal to 4 octets,
2250 REJECT/RETURN 'client-error-bad-request'.
2252 IF NOT supplied by the client, use the value of the Printer
2253 object's "job-priority-default" attribute at job submission time.
2255 IF NOT in the range 1 to 100, inclusive, copy the attribute and
2256 the unsupported value to the Unsupported Attributes response
2259 Map the value to the nearest supported value in the range 1:100 as
2260 specified by the number of discrete values indicated by the value
2261 of the Printer's "job-priority-supported" attribute. See the
2262 formula in [RFC2911] Section 4.2.1.
2264 job-hold-until (type3 keyword | name)
2266 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
2269 IF the value length is greater than 255 octets, REJECT/RETURN
2270 'client-error-request-value-too-long'.
2272 IF NOT supplied by the client, use the value of the Printer
2273 object's "job-hold-until" attribute at job submission time.
2275 IF NOT in the Printer object's "job-hold-until-supported"
2276 attribute, copy the attribute and the unsupported value to the
2277 Unsupported Attributes response group.
2279 job-sheets (type3 keyword | name)
2281 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
2284 IF the value length is greater than 255 octets, REJECT/RETURN
2285 'client-error-request-value-too-long'.
2287 IF NOT in the Printer object's "job-sheets-supported" attribute,
2288 copy the attribute and the unsupported value to the Unsupported
2289 Attributes response group.
2291 multiple-document-handling (type2 keyword)
2293 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
2298 Hastings, et al. Informational [Page 41]
2300 RFC 3196 Internet Printing Protocol/1.1 November 2001
2303 IF the value length is greater than 255 octets, REJECT/RETURN
2304 'client-error-request-value-too-long'.
2306 IF NOT in the Printer object's "multiple-document-handling-
2307 supported" attribute, copy the attribute and the unsupported value
2308 to the Unsupported Attributes response group.
2310 copies (integer(1:MAX))
2312 IF NOT a single 'integer' value with a length equal to 4 octets,
2313 REJECT/RETURN 'client-error-bad-request'.
2315 IF NOT in range of the Printer object's "copies-supported"
2318 copy the attribute and the unsupported value to the Unsupported
2319 Attributes response group.
2321 finishings (1setOf type2 enum)
2323 IF NOT an 'enum' value(s) each with a length equal to 4 octets,
2324 REJECT/RETURN 'client-error-bad-request'.
2326 IF NOT in the Printer object's "finishings-supported" attribute,
2327 copy the attribute and the unsupported value(s), but not any
2328 supported values, to the Unsupported Attributes response group.
2330 page-ranges (1setOf rangeOfInteger(1:MAX))
2332 IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
2333 octets, REJECT/RETURN 'client-error-bad-request'.
2335 IF first value is greater than second value in any range, the
2336 ranges are not in ascending order, or ranges overlap,
2337 REJECT/RETURN 'client-error-bad-request'.
2339 IF the value of the Printer object's "page-ranges-supported"
2340 attribute is 'false', copy the attribute to the Unsupported
2341 Attributes response group and set the value to the "out-of-band"
2342 'unsupported' value.
2344 sides (type2 keyword)
2346 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
2349 IF the value length is greater than 255 octets, REJECT/RETURN
2350 'client-error-request-value-too-long'.
2354 Hastings, et al. Informational [Page 42]
2356 RFC 3196 Internet Printing Protocol/1.1 November 2001
2359 IF NOT in the Printer object's "sides-supported" attribute, copy
2360 the attribute and the unsupported value to the Unsupported
2361 Attributes response group.
2363 number-up (integer(1:MAX))
2365 IF NOT a single 'integer' value with a length equal to 4 octets,
2366 REJECT/RETURN 'client-error-bad-request'.
2368 IF NOT a value or in the range of one of the values of the Printer
2369 object's "number-up-supported" attribute, copy the attribute and
2370 value to the Unsupported Attribute response group.
2372 orientation-requested (type2 enum)
2374 IF NOT a single 'enum' value with a length equal to 4 octets,
2375 REJECT/RETURN 'client-error-bad-request'.
2377 IF NOT in the Printer object's "orientation-requested-supported"
2378 attribute, copy the attribute and the unsupported value to the
2379 Unsupported Attributes response group.
2381 media (type3 keyword | name)
2383 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
2386 IF the value length is greater than 255 octets, REJECT/RETURN
2387 'client-error-request-value-too-long'.
2389 IF NOT in the Printer object's "media-supported" attribute, copy
2390 the attribute and the unsupported value to the Unsupported
2391 Attributes response group.
2393 printer-resolution (resolution)
2395 IF NOT a single 'resolution' value with a length equal to 9
2396 octets, REJECT/RETURN 'client-error-bad-request'.
2398 IF NOT in the Printer object's "printer-resolution-supported"
2399 attribute, copy the attribute and the unsupported value to the
2400 Unsupported Attributes response group.
2402 print-quality (type2 enum)
2404 IF NOT a single 'enum' value with a length equal to 4 octets,
2405 REJECT/RETURN 'client-error-bad-request'.
2410 Hastings, et al. Informational [Page 43]
2412 RFC 3196 Internet Printing Protocol/1.1 November 2001
2415 IF NOT in the Printer object's "print-quality-supported"
2416 attribute, copy the attribute and the unsupported value to the
2417 Unsupported Attributes response group.
2419 unknown or unsupported attribute (i.e., there is no corresponding
2420 Printer object "xxx-supported" attribute)
2422 IF the attribute syntax supplied by the client is supported but
2423 the length is not legal for that attribute syntax,
2425 REJECT/RETURN 'client-error-bad-request' if the length of the
2426 attribute syntax is fixed or 'client-error-request-value-too-long'
2427 if the length of the attribute syntax is variable.
2429 ELSE copy the attribute and value to the Unsupported Attributes
2430 response group and change the attribute value to the "out-of-band"
2431 'unsupported' value. Any remaining Job Template Attributes are
2432 either unknown or unsupported Job Template attributes and are
2433 validated algorithmically according to their attribute syntax for
2434 proper length (see below).
2436 -----------------------------------------------
2438 If the attribute syntax is supported AND the length check fails,
2439 the IPP object REJECTS the request and RETURNS the 'client-error-
2440 bad-request' if the length of the attribute syntax is fixed or the
2441 'client-error-request-value-too-long' status code if the length of
2442 the attribute syntax is variable. Otherwise, the IPP object copies
2443 the unsupported Job Template attribute to the Unsupported
2444 Attributes response group and changes the attribute value to the
2445 "out-of-band" 'unsupported' value. The following table shows the
2446 length checks for all attribute syntaxes. In the following table:
2447 "<=" means less than or equal, "=" means equal to:
2466 Hastings, et al. Informational [Page 44]
2468 RFC 3196 Internet Printing Protocol/1.1 November 2001
2471 Name Octet length check for read-write attributes
2472 ---------- ---------------------------------------------
2474 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
2475 'textWithoutLanguage' <= 1023
2476 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63
2477 'nameWithoutLanguage' <= 255
2483 'naturalLanguage' <= 63
2484 'mimeMediaType' <= 255
2485 'octetString' <= 1023
2488 'rangeOfInteger' = 8
2493 Note: It's possible for a Printer to receive a zero length keyword
2494 in a request. Since this is a keyword, its value needs to be
2495 compared with the supported values. Assuming that the printer
2496 doesn't have any values in its corresponding "xxx-supported"
2497 attribute that are keywords of zero length, the comparison will fail.
2498 Then the request will be accepted or rejected depending on the value
2499 of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
2500 No special handling is required for
2502 3.1.2.3.1 Check for conflicting Job Template attributes values
2504 Once all the Operation and Job Template attributes have been checked
2505 individually, the Printer object SHOULD check for any conflicting
2506 values among all the supported values supplied by the client. For
2507 example, a Printer object might be able to staple and to print on
2508 transparencies, however due to physical stapling constraints, the
2509 Printer object might not be able to staple transparencies. The IPP
2510 object copies the supported attributes and their conflicting
2511 attribute values to the Unsupported Attributes response group. The
2512 Printer object only copies over those attributes that the Printer
2513 object either ignores or substitutes in order to resolve the
2514 conflict, and it returns the original values which were supplied by
2515 the client. For example suppose the client supplies "finishings"
2516 equals 'staple' and "media" equals 'transparency', but the Printer
2517 object does not support stapling transparencies. If the Printer
2518 chooses to ignore the stapling request in order to resolve the
2522 Hastings, et al. Informational [Page 45]
2524 RFC 3196 Internet Printing Protocol/1.1 November 2001
2527 conflict, the Printer objects returns "finishings" equal to 'staple'
2528 in the Unsupported Attributes response group. If any attributes are
2529 multi-valued, only the conflicting values of the attributes are
2532 Note: The decisions made to resolve the conflict (if there is a
2533 choice) is implementation dependent.
2535 3.1.2.3.2 Decide whether to REJECT the request
2537 If there were any unsupported Job Template attributes or
2538 unsupported/conflicting Job Template attribute values and the client
2539 supplied the "ipp-attribute-fidelity" attribute with the 'true'
2540 value, the Printer object REJECTS the request and return the status
2543 1.'client-error-conflicting-attributes' status code, if there were
2544 any conflicts between attributes supplied by the client.
2546 2.'client-error-attributes-or-values-not-supported' status code,
2549 Note: Unsupported Operation attributes or values that are returned
2550 do not affect the status returned in this step. If the unsupported
2551 Operation attribute was a serious error, the above already rejected
2552 the request in a previous step. If control gets to this step with
2553 unsupported Operation attributes being returned, they are not serious
2556 In general, the final results of Job processing are unknown at Job
2557 submission time. The client has to rely on notifications or polling
2558 to find out what happens at Job processing time. However, there are
2559 cases in which some Printers can determine at Job submission time
2560 that Job processing is going to fail. As an optimization, we'd like
2561 to have the Printer reject the Job in these cases.
2563 There are three types of "processing" errors that might be detectable
2564 at Job submission time:
2566 1. 'client-error-document-format-not-supported' : For the Print-
2567 Job, Send-Document, Print-URI, and Send-URI operations, if all these
2568 conditions are true:
2570 - the Printer supports auto-sensing,
2571 - the request "document-format" operation attribute is
2572 'application/octet-stream',
2573 - the Printer receives document data before responding,
2574 - the Printer auto-senses the document format before responding,
2578 Hastings, et al. Informational [Page 46]
2580 RFC 3196 Internet Printing Protocol/1.1 November 2001
2583 - the sensed document format is not supported by the Printer
2585 then the Printer should respond with 'client-error-document-format-
2586 not-supported' status.
2588 2. 'client-error-compression-error': For the Print-Job, Send-
2589 Document, Print-URI, and Send-URI operations, if all these
2590 conditions are true:
2592 - the client supplies a supported value for the "compression"
2593 operation attribute in the request
2594 - the Printer receives document data before responding,
2595 - the Printer attempts to decompress the document data before
2597 - the document data cannot be decompressed using the algorithm
2598 specified by the "compression" operation attribute
2600 then the Printer should respond with 'client-error-compression-error'
2603 3. 'client-error-document-access-error': For the Print-URI, and
2604 Send-URI operations, if the Printer attempts and fails to pull the
2605 referenced document data before responding, it should respond with
2606 'client-error-document-access-error' status.
2608 Some Printers are not able to detect these errors until Job
2609 processing time. In that case, the errors are recorded in the
2610 corresponding job-state and job-state reason attributes. (There is
2611 no standard way for a client to determine whether a Printer can
2612 detect these errors at Job submission time.) For example, if auto-
2613 sensing happens AFTER the job is accepted (as opposed to auto-sensing
2614 at submit time before returning the response), the implementation
2615 aborts the job, puts the job in the 'aborted' state and sets the
2616 'unsupported-document-format' value in the job's "job-state-reasons".
2618 A client should always provide a valid "document-format" operation
2619 attribute whenever practical. In the absence of other information, a
2620 client itself may sniff the document data to determine document
2623 Auto sensing at Job submission time may be more difficult for the
2624 Printer when combined with compression. For auto-sensed Jobs, a
2625 client may be better off deferring compression to the transfer
2626 protocol layer, e.g.; by using the HTTP Content-Encoding header.
2634 Hastings, et al. Informational [Page 47]
2636 RFC 3196 Internet Printing Protocol/1.1 November 2001
2639 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success
2642 If the requested operation is the Validate-Job operation, the Printer
2645 1. the "successful-ok" status code, if there are no unsupported or
2646 conflicting Job Template attributes or values.
2647 2. the "successful-ok-conflicting-attributes, if there are any
2648 conflicting Job Template attribute or values.
2649 3. the "successful-ok-ignored-or-substituted-attributes, if there
2650 are only unsupported Job Template attributes or values.
2652 Note: Unsupported Operation attributes or values that are returned
2653 do not affect the status returned in this step. If the unsupported
2654 Operation attribute was a serious error, the above already rejected
2655 the request in a previous step. If control gets to this step with
2656 unsupported Operation attributes being returned, they are not serious
2659 3.1.2.3.4 Create the Job object with attributes to support
2661 If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
2662 by the client), the Printer object:
2664 1. creates a Job object, assigns a unique value to the job's
2665 "job-uri" and "job-id" attributes, and initializes all of the
2666 job's other supported Job Description attributes.
2667 2. removes all unsupported attributes from the Job object.
2668 3. for each unsupported value, removes either the unsupported
2669 value or substitutes the unsupported attribute value with some
2670 supported value. If an attribute has no values after removing
2671 unsupported values from it, the attribute is removed from the
2672 Job object (so that the normal default behavior at job
2673 processing time will take place for that attribute).
2674 4. for each conflicting value, removes either the conflicting
2675 value or substitutes the conflicting attribute value with some
2676 other supported value. If an attribute has no values after
2677 removing conflicting values from it, the attribute is removed
2678 from the Job object (so that the normal default behavior at job
2679 processing time will take place for that attribute).
2681 If there were no attributes or values flagged as unsupported, or the
2682 value of 'ipp-attribute-fidelity" was 'false', the Printer object is
2683 able to accept the create request and create a new Job object. If
2684 the "ipp-attribute-fidelity" attribute is set to 'true', the Job
2685 Template attributes that populate the new Job object are necessarily
2686 all the Job Template attributes supplied in the create request. If
2690 Hastings, et al. Informational [Page 48]
2692 RFC 3196 Internet Printing Protocol/1.1 November 2001
2695 the "ipp-attribute-fidelity" attribute is set to 'false', the Job
2696 Template attributes that populate the new Job object are all the
2697 client supplied Job Template attributes that are supported or that
2698 have value substitution. Thus, some of the requested Job Template
2699 attributes will not appear in the Job object because the Printer
2700 object did not support those attributes. The attributes that
2701 populate the Job object are persistently stored with the Job object
2702 for that Job. A Get-Job-Attributes operation on that Job object will
2703 return only those attributes that are persistently stored with the
2706 Note: All Job Template attributes that are persistently stored with
2707 the Job object are intended to be "override values"; that is, they
2708 that take precedence over whatever other embedded instructions might
2709 be in the document data itself. However, it is not possible for all
2710 Printer objects to realize the semantics of "override". End users
2711 may query the Printer's "pdl-override-supported" attribute to
2712 determine if the Printer either attempts or does not attempt to
2713 override document data instructions with IPP attributes.
2715 There are some cases, where a Printer supports a Job Template
2716 attribute and has an associated default value set for that attribute.
2717 In the case where a client does not supply the corresponding
2718 attribute, the Printer does not use its default values to populate
2719 Job attributes when creating the new Job object; only Job Template
2720 attributes actually in the create request are used to populate the
2721 Job object. The Printer's default values are only used later at Job
2722 processing time if no other IPP attribute or instruction embedded in
2723 the document data is present.
2725 Note: If the default values associated with Job Template attributes
2726 that the client did not supply were to be used to populate the Job
2727 object, then these values would become "override values" rather than
2728 defaults. If the Printer supports the 'attempted' value of the
2729 "pdl-override-supported" attribute, then these override values could
2730 replace values specified within the document data. This is not the
2731 intent of the default value mechanism. A default value for an
2732 attribute is used only if the create request did not specify that
2733 attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
2734 being 'false') and no value was provided within the content of the
2737 If the client does not supply a value for some Job Template
2738 attribute, and the Printer does not support that attribute, as far as
2739 IPP is concerned, the result of processing that Job (with respect to
2740 the missing attribute) is undefined.
2746 Hastings, et al. Informational [Page 49]
2748 RFC 3196 Internet Printing Protocol/1.1 November 2001
2751 3.1.2.3.5 Return one of the success status codes
2753 Once the Job object has been created, the Printer object accepts the
2754 request and returns to the client:
2756 1. the 'successful-ok' status code, if there are no unsupported or
2757 conflicting Job Template attributes or values.
2758 2. the 'successful-ok-conflicting-attributes' status code, if
2759 there are any conflicting Job Template attribute or values.
2760 3. the 'successful-ok-ignored-or-substituted-attributes' status
2761 code, if there are only unsupported Job Template attributes or
2764 Note: Unsupported Operation attributes or values that are returned
2765 do not affect the status returned in this step. If the unsupported
2766 Operation attribute was a serious error, the above already rejected
2767 the request in a previous step. If control gets to this step with
2768 unsupported Operation attributes being returned, they are not serious
2771 The Printer object also returns Job status attributes that indicate
2772 the initial state of the Job ('pending', 'pending-held',
2773 'processing', etc.), etc. See Print-Job Response, [RFC2911] section
2776 3.1.2.3.6 Accept appended Document Content
2778 The Printer object accepts the appended Document Content data and
2779 either starts it printing, or spools it for later processing.
2781 3.1.2.3.7 Scheduling and Starting to Process the Job
2783 The Printer object uses its own configuration and implementation
2784 specific algorithms for scheduling the Job in the correct processing
2785 order. Once the Printer object begins processing the Job, the
2786 Printer changes the Job's state to 'processing'. If the Printer
2787 object supports PDL override (the "pdl-override-supported" attribute
2788 set to 'attempted'), the implementation does its best to see that IPP
2789 attributes take precedence over embedded instructions in the document
2792 3.1.2.3.8 Completing the Job
2794 The Printer object continues to process the Job until it can move the
2795 Job into the 'completed' state. If an Cancel-Job operation is
2796 received, the implementation eventually moves the Job into the
2797 'canceled' state. If the system encounters errors during processing
2798 that do not allow it to progress the Job into a completed state, the
2802 Hastings, et al. Informational [Page 50]
2804 RFC 3196 Internet Printing Protocol/1.1 November 2001
2807 implementation halts all processing, cleans up any resources, and
2808 moves the Job into the 'aborted' state.
2810 3.1.2.3.9 Destroying the Job after completion
2812 Once the Job moves to the 'completed', 'aborted', or 'canceled'
2813 state, it is an implementation decision as to when to destroy the Job
2814 object and release all associated resources. Once the Job has been
2815 destroyed, the Printer would return either the "client-error-not-
2816 found" or "client-error-gone" status codes for operations directed at
2819 Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
2820 value for a sufficiently long time after a job has been destroyed, so
2821 that stale references kept by clients are less likely to access the
2824 3.1.2.3.10 Interaction with "ipp-attribute-fidelity"
2826 Some Printer object implementations may support "ipp-attribute-
2827 fidelity" set to 'true' and "pdl-override-supported" set to
2828 'attempted' and yet still not be able to realize exactly what the
2829 client specifies in the create request. This is due to legacy
2830 decisions and assumptions that have been made about the role of job
2831 instructions embedded within the document data and external job
2832 instructions that accompany the document data and how to handle
2833 conflicts between such instructions. The inability to be 100%
2834 precise about how a given implementation will behave is also
2835 compounded by the fact that the two special attributes, "ipp-
2836 attribute-fidelity" and "pdl-"override-supported", apply to the whole
2837 job rather than specific values for each attribute. For example, some
2838 implementations may be able to override almost all Job Template
2839 attributes except for "number-up". Character Sets, natural
2840 languages, and internationalization
2842 This section discusses character set support, natural language
2843 support and internationalization.
2845 3.1.2.3.11 Character set code conversion support
2847 IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY
2848 support additional charsets. It is RECOMMENDED that an IPP object
2849 also support US-ASCII, since many clients support US-ASCII, and
2850 indicate that UTF-8 and US-ASCII are supported by populating the
2851 Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An
2852 IPP object is required to code covert with as little loss as possible
2853 between the charsets that it supports, as indicated in the Printer's
2854 "charsets-supported" attribute.
2858 Hastings, et al. Informational [Page 51]
2860 RFC 3196 Internet Printing Protocol/1.1 November 2001
2863 How should the server handle the situation where the "attributes-
2864 charset" of the response itself is "us-ascii", but one or more
2865 attributes in that response is in the "utf-8" format?
2867 Example: Consider a case where a client sends a Print-Job request
2868 with "utf-8" as the value of "attributes-charset" and with the "job-
2869 name" attribute supplied. Later another client submits a Get-Job-
2870 Attribute or Get-Jobs request. This second request contains the
2871 "attributes-charset" with value "us-ascii" and "requested-attributes"
2872 attribute with exactly one value "job-name".
2874 According to the RFC2911 document (section 3.1.4.2), the value of the
2875 "attributes-charset" for the response of the second request must be
2876 "us-ascii" since that is the charset specified in the request. The
2877 "job-name" value, however, is in "utf-8" format. Should the request
2878 be rejected even though both "utf-8" and "us-ascii" charsets are
2879 supported by the server? or should the "job-name" value be converted
2880 to "us-ascii" and return "successful-ok-conflicting-attributes"
2881 (0x0002) as the status code?
2883 Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
2884 ascii, the second paragraph of section 3.1.4.2 applies so that the
2885 IPP object MUST accept the request, perform code set conversion
2886 between these two charsets with "the highest fidelity possible" and
2887 return 'successful-ok', rather than a warning 'successful-ok-
2888 conflicting-attributes, or an error. The printer will do the best it
2889 can to convert between each of the character sets that it supports --
2890 even if that means providing a string of question marks because none
2891 of the characters are representable in US ASCII. If it can't perform
2892 such conversion, it MUST NOT advertise us-ascii as a value of its
2893 "attributes-charset-supported" and MUST reject any request that
2894 requests 'us-ascii'.
2896 One IPP object implementation strategy is to convert all request text
2897 and name values to a Unicode internal representation. This is 16-bit
2898 and virtually universal. Then convert to the specified operation
2899 attributes-charset on output.
2901 Also it would be smarter for a client to ask for 'utf-8', rather than
2902 'us-ascii' and throw away characters that it doesn't understand,
2903 rather than depending on the code conversion of the IPP object.
2905 3.1.2.3.12 What charset to return when an unsupported charset is
2906 requested (Issue 1.19)?
2908 Section 3.1.4.1 Request Operation attributes was clarified in
2909 November 1998 as follows:
2914 Hastings, et al. Informational [Page 52]
2916 RFC 3196 Internet Printing Protocol/1.1 November 2001
2919 All clients and IPP objects MUST support the 'utf-8' charset
2920 [RFC2044] and MAY support additional charsets provided that they are
2921 registered with IANA [IANA-CS]. If the Printer object does not
2922 support the client supplied charset value, the Printer object MUST
2923 reject the request, set the "attributes-charset" to 'utf-8' in the
2924 response, and return the 'client-error-charset-not-supported' status
2925 code and any 'text' or 'name' attributes using the 'utf-8' charset.
2927 Since the client and IPP object MUST support UTF-8, returning any
2928 text or name attributes in UTF-8 when the client requests a charset
2929 that is not supported should allow the client to display the text or
2932 Since such an error is a client error, rather than a user error, the
2933 client should check the status code first so that it can avoid
2934 displaying any other returned 'text' and 'name' attributes that are
2935 not in the charset requested.
2937 Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-
2938 supported (0x040D) was clarified in November 1998 as follows:
2940 For any operation, if the IPP Printer does not support the charset
2941 supplied by the client in the "attributes-charset" operation
2942 attribute, the Printer MUST reject the operation and return this
2943 status and any 'text' or 'name' attributes using the 'utf-8' charset
2944 (see Section 3.1.4.1).
2946 3.1.2.3.13 Natural Language Override (NLO)
2948 The 'text' and 'name' attributes each have two forms. One has an
2949 implicit natural language, and the other has an explicit natural
2950 language. The 'textWithoutLanguage' and 'textWithLanguage' are the
2951 two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage
2952 are the two 'name' forms. If a receiver (IPP object or IPP client)
2953 supports an attribute with attribute syntax 'text', it MUST support
2954 both forms in a request and a response. A sender (IPP client or IPP
2955 object) MAY send either form for any such attribute. When a sender
2956 sends a WithoutLanguage form, the implicit natural language is
2957 specified in the "attributes-natural-language" operation attribute,
2958 which all senders MUST include in every request and response.
2960 When a sender sends a WithLanguage form, it MAY be different from the
2961 implicit natural language supplied by the sender or it MAY be the
2962 same. The receiver MUST treat either form equivalently.
2964 There is an implementation decision for senders, whether to always
2965 send the WithLanguage forms or use the WithoutLanguage form when the
2966 attribute's natural language is the same as the request or response.
2970 Hastings, et al. Informational [Page 53]
2972 RFC 3196 Internet Printing Protocol/1.1 November 2001
2975 The former approach makes the sender implementation simpler. The
2976 latter approach is more efficient on the wire and allows inter-
2977 working with non-conforming receivers that fail to support the
2978 WithLanguage forms. As each approach have advantages, the choice is
2979 completely up to the implementer of the sender.
2981 Furthermore, when a client receives a 'text' or 'name' job attribute
2982 that it had previously supplied, that client MUST NOT expect to see
2983 the attribute in the same form, i.e., in the same WithoutLanguage or
2984 WithLanguage form as the client supplied when it created the job.
2985 The IPP object is free to transform the attribute from the
2986 WithLanguage form to the WithoutLanguage form and vice versa, as long
2987 as the natural language is preserved. However, in order to meet this
2988 latter requirement, it is usually simpler for the IPP object
2989 implementation to store the natural language explicitly with the
2990 attribute value, i.e., to store using an internal representation that
2991 resembles the WithLanguage form.
2993 The IPP Printer MUST copy the natural language of a job, i.e., the
2994 value of the "attributes-natural-language" operation attribute
2995 supplied by the client in the create operation, to the Job object as
2996 a Job Description attribute, so that a client is able to query it.
2997 In returning a Get-Job-Attributes response, the IPP object MAY return
2998 one of three natural language values in the responses "attributes-
2999 natural-language" operation attribute: (1) that requested by the
3000 requester, (2) the natural language of the job, or (3) the configured
3001 natural language of the IPP Printer, if the requested language is not
3002 supported by the IPP Printer.
3004 This "attributes-natural-language" Job Description attribute is
3005 useful for an IPP object implementation that prints start sheets in
3006 the language of the user who submitted the job. This same Job
3007 Description attribute is useful to a multi-lingual operator who has
3008 to communicate with different job submitters in different natural
3009 languages. This same Job Description attribute is expected to be
3010 used in the future to generate notification messages in the natural
3011 language of the job submitter.
3013 Early drafts of [RFC2911] contained a job-level natural language
3014 override (NLO) for the Get-Jobs response. A job-level (NLO) is an
3015 (unrequested) Job Attribute which then specified the implicit natural
3016 language for any other WithoutLanguage job attributes returned in the
3017 response for that job. Interoperability testing of early
3018 implementations showed that no one was implementing the job-level NLO
3019 in Get-Job responses. So the job-level NLO was eliminated from the
3020 Get-Jobs response. This simplification makes all requests and
3021 responses consistent in that the implicit natural language for any
3026 Hastings, et al. Informational [Page 54]
3028 RFC 3196 Internet Printing Protocol/1.1 November 2001
3031 WithoutLanguage 'text' or 'name' form is always supplied in the
3032 request's or response's "attributes-natural-language" operation
3035 3.1.3 Status codes returned by operation
3037 This section corresponds to [RFC2911] section 3.1.6 "Operation
3038 Response Status Codes and Status Messages". This section lists all
3039 status codes once in the first operation (Print-Job). Then it lists
3040 the status codes that are different or specialized for subsequent
3041 operations under each operation.
3043 3.1.3.1 Printer Operations
3047 The Printer object MUST return one of the following "status-code"
3048 values for the indicated reason. Whether all of the document data
3049 has been accepted or not before returning the success or error
3050 response depends on implementation. See Section 13 in [RFC2911] for
3051 a more complete description of each status code.
3053 For the following success status codes, the Job object has been
3054 created and the "job-id", and "job-uri" assigned and returned in the
3057 successful-ok: no request attributes were substituted or ignored.
3059 successful-ok-ignored-or-substituted-attributes: some supplied
3060 (1) attributes were ignored or (2) unsupported attribute syntaxes
3061 or values were substituted with supported values or were ignored.
3062 Unsupported attributes, attribute syntax's, or values MUST be
3063 returned in the Unsupported Attributes group of the response.
3065 successful-ok-conflicting-attributes: some supplied attribute
3066 values conflicted with the values of other supplied attributes and
3067 were either substituted or ignored. Attributes or values which
3068 conflict with other attributes and have been substituted or
3069 ignored MUST be returned in the Unsupported Attributes group of
3070 the response as supplied by the client.
3072 [RFC2911] section 3.1.6 Operation Status Codes and Messages states:
3074 If the Printer object supports the "status-message" operation
3075 attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a
3076 status message for the following error status codes (see section
3077 13 in [RFC2911]): 'client-error-bad-request', 'client-error-
3078 charset-not-supported', 'server-error-internal-error', 'server-
3082 Hastings, et al. Informational [Page 55]
3084 RFC 3196 Internet Printing Protocol/1.1 November 2001
3087 error-operation-not-supported', and 'server-error-version-not-
3088 supported'. In this case, it MUST set the value of the
3089 "attributes-charset" operation attribute to 'utf-8' in the error
3092 For the following error status codes, no job is created and no
3093 "job-id" or "job-uri" is returned:
3095 client-error-bad-request: The request syntax does not conform
3096 to the specification.
3098 client-error-forbidden: The request is being refused for
3099 authorization or authentication reasons. The implementation
3100 security policy is to not reveal whether the failure is one of
3101 authentication or authorization.
3103 client-error-not-authenticated: Either the request requires
3104 authentication information to be supplied or the authentication
3105 information is not sufficient for authorization.
3107 client-error-not-authorized: The requester is not authorized
3108 to perform the request on the target object.
3110 client-error-not-possible: The request cannot be carried out
3111 because of the state of the system. See also 'server-error-
3112 not-accepting-jobs' status code, which MUST take precedence if
3113 the Printer object's "printer-accepting-jobs" attribute is
3116 client-error-timeout: not applicable.
3118 client-error-not-found: the target object does not exist.
3120 client-error-gone: the target object no longer exists and no
3121 forwarding address is known.
3123 client-error-request-entity-too-large: the size of the request
3124 and/or print data exceeds the capacity of the IPP Printer to
3127 client-error-request-value-too-long: the size of request
3128 variable length attribute values, such as 'text' and 'name'
3129 attribute syntax's, exceed the maximum length specified in
3130 [RFC2911] for the attribute and MUST be returned in the
3131 Unsupported Attributes Group.
3138 Hastings, et al. Informational [Page 56]
3140 RFC 3196 Internet Printing Protocol/1.1 November 2001
3143 supplied is not supported. The "document-format" attribute
3144 with the unsupported value MUST be returned in the Unsupported
3145 Attributes Group. This error SHOULD take precedence over any
3146 other 'xxx-not-supported' error, except 'client-error-charset-
3149 client-error-attributes-or-values-not-supported: one or more
3150 supplied attributes, attribute syntax's, or values are not
3151 supported and the client supplied the "ipp-attributes-
3152 fidelity" operation attribute with a 'true' value. They MUST
3153 be returned in the Unsupported Attributes Group as explained
3156 client-error-uri-scheme-not-supported: not applicable.
3158 client-error-charset-not-supported: the charset supplied in
3159 the "attributes-charset" operation attribute is not supported.
3160 The Printer's "configured-charset" MUST be returned in the
3161 response as the value of the "attributes-charset" operation
3162 attribute and used for any 'text' and 'name' attributes
3163 returned in the error response. This error SHOULD take
3164 precedence over any other error, unless the request syntax is
3165 so bad that the client's supplied "attributes-charset" cannot
3168 client-error-conflicting-attributes: one or more supplied
3169 attribute values conflicted with each other and the client
3170 supplied the "ipp-attributes-fidelity" operation attribute with
3171 a 'true' value. They MUST be returned in the Unsupported
3172 Attributes Group as explained below.
3174 server-error-internal-error: an unexpected condition prevents
3175 the request from being fulfilled.
3177 server-error-operation-not-supported: not applicable (since
3178 Print-Job is REQUIRED).
3180 server-error-service-unavailable: the service is temporarily
3183 server-error-version-not-supported: the version in the request
3184 is not supported. The "closest" version number supported MUST
3185 be returned in the response.
3187 server-error-device-error: a device error occurred while
3188 receiving or spooling the request or document data or the IPP
3189 Printer object can only accept one job at a time.
3194 Hastings, et al. Informational [Page 57]
3196 RFC 3196 Internet Printing Protocol/1.1 November 2001
3199 server-error-temporary-error: a temporary error such as a
3200 buffer full write error, a memory overflow, or a disk full
3201 condition occurred while receiving the request and/or the
3204 server-error-not-accepting-jobs: the Printer object's
3205 "printer-is-not-accepting-jobs" attribute is 'false'.
3207 server-error-busy: the Printer is too busy processing jobs to
3208 accept another job at this time.
3210 server-error-job-canceled: the job has been canceled by an
3211 operator or the system while the client was transmitting the
3216 All of the Print-Job status codes described in Section 3.1.3.1.1
3217 Print-Job Response are applicable to Print-URI with the following
3218 specializations and differences. See Section 14 for a more complete
3219 description of each status code.
3221 client-error-uri-scheme-not-supported: the URI scheme supplied
3222 in the "document-uri" operation attribute is not supported and
3223 is returned in the Unsupported Attributes group.
3225 server-error-operation-not-supported: the Print-URI operation
3228 3.1.3.1.3 Validate-Job
3230 All of the Print-Job status codes described in Section 3.1.3.1.1
3231 Print-Job Response are applicable to Validate-Job. See Section 13 in
3232 [RFC2911] for a more complete description of each status code.
3234 3.1.3.1.4 Create-Job
3236 All of the Print-Job status codes described in Section 3.1.3.1.1
3237 Print-Job Response are applicable to Create-Job with the following
3238 specializations and differences. See Section 13 in [RFC2911] for a
3239 more complete description of each status code.
3241 server-error-operation-not-supported: the Create-Job operation
3250 Hastings, et al. Informational [Page 58]
3252 RFC 3196 Internet Printing Protocol/1.1 November 2001
3255 client-error-multiple-document-jobs-not-supported: while the
3256 Create-Job and Send-Document operations are supported, this
3257 implementation doesn't support more than one document with
3260 3.1.3.1.5 Get-Printer-Attributes
3262 All of the Print-Job status codes described in Section
3263 3.1.3.1.1 Print-Job Response are applicable to the Get-
3264 Printer-Attributes operation with the following
3265 specialization's and differences. See Section 13 in [RFC2911]
3266 for a more complete description of each status code.
3268 For the following success status codes, the requested
3269 attributes are returned in Group 3 in the response:
3271 successful-ok: no operation attributes or values were
3272 substituted or ignored (same as Print-Job) and no requested
3273 attributes were unsupported.
3275 successful-ok-ignored-or-substituted-attributes: The
3276 "requested-attributes" operation attribute MAY, but NEED NOT,
3277 be returned with the unsupported values.
3279 successful-ok-conflicting-attributes: same as Print-Job.
3281 For the error status codes, Group 3 is returned containing no
3282 attributes or is not returned at all:
3284 client-error-not-possible: Same as Print-Job, in addition the
3285 Printer object is not accepting any requests.
3287 client-error-request-entity-too-large: same as Print-job,
3288 except that no print data is involved.
3290 client-error-attributes-or-values-not-supported: not
3291 applicable, since unsupported operation attributes and/or
3292 values MUST be ignored and an appropriate success code returned
3295 client-error-conflicting-attributes: same as Print-Job, except
3296 that "ipp-attribute-fidelity" is not involved.
3298 server-error-operation-not-supported: not applicable (since
3299 Get-Printer-Attributes is REQUIRED).
3301 server-error-device-error: same as Print-Job, except that no
3302 document data is involved.
3306 Hastings, et al. Informational [Page 59]
3308 RFC 3196 Internet Printing Protocol/1.1 November 2001
3311 server-error-temporary-error: same as Print-Job, except that
3312 no document data is involved.
3314 server-error-not-accepting-jobs: not applicable.
3316 server-error-busy: same as Print-Job, except the IPP object is
3317 too busy to accept even query requests.
3319 server-error-job-canceled: not applicable.
3323 All of the Print-Job status codes described in Section 3.1.3.1.1
3324 Print-Job Response are applicable to the Get-Jobs operation with the
3325 following specialization's and differences. See Section 13 in
3326 [RFC2911] for a more complete description of each status code.
3328 For the following success status codes, the requested attributes are
3329 returned in Group 3 in the response:
3331 successful-ok: same as Get-Printer-Attributes (see section
3334 successful-ok-ignored-or-substituted-attributes: same as Get-
3335 Printer-Attributes (see section 3.1.3.1.5).
3337 successful-ok-conflicting-attributes: same as Get-Printer-
3338 Attributes (see section 3.1.3.1.5).
3340 For any error status codes, Group 3 is returned containing no
3341 attributes or is not returned at all. The following brief error
3342 status code descriptions contain unique information for use with
3343 Get-Jobs operation. See section 14 for the other error status codes
3344 that apply uniformly to all operations:
3346 client-error-not-possible: Same as Print-Job, in addition the
3347 Printer object is not accepting any requests.
3349 client-error-request-entity-too-large: same as Print-job,
3350 except that no print data is involved.
3352 client-error-document-format-not-supported: not applicable.
3354 client-error-attributes-or-values-not-supported: not
3355 applicable, since unsupported operation attributes and/or
3356 values MUST be ignored and an appropriate success code returned
3362 Hastings, et al. Informational [Page 60]
3364 RFC 3196 Internet Printing Protocol/1.1 November 2001
3367 client-error-conflicting-attributes: same as Print-Job, except
3368 that "ipp-attribute-fidelity" is not involved.
3370 server-error-operation-not-supported: not applicable (since
3371 Get-Jobs is REQUIRED).
3373 server-error-device-error: same as Print-Job, except that no
3374 document data is involved.
3376 server-error-temporary-error: same as Print-Job, except that
3377 no document data is involved.
3379 server-error-not-accepting-jobs: not applicable.
3381 server-error-job-canceled: not applicable.
3383 3.1.3.1.7 Pause-Printer
3385 All of the Print-Job status codes described in Section 3.1.3.1.1
3386 Print-Job Response are applicable to Pause-Printer with the following
3387 specializations and differences. See Section 13 in [RFC2911] for a
3388 more complete description of each status code.
3390 For the following success status codes, the Printer object is being
3391 stopped from scheduling jobs on all its devices.
3393 successful-ok: no request attributes were substituted or
3394 ignored (same as Print-Job).
3396 successful-ok-ignored-or-substituted-attributes: same as
3399 successful-ok-conflicting-attributes: same as Print-Job.
3401 For any of the error status codes, the Printer object has not been
3402 stopped from scheduling jobs on all its devices.
3404 client-error-not-possible: not applicable.
3406 client-error-not-found: the target Printer object does not
3409 client-error-gone: the target Printer object no longer exists
3410 and no forwarding address is known.
3412 client-error-request-entity-too-large: same as Print-Job,
3413 except no document data is involved.
3418 Hastings, et al. Informational [Page 61]
3420 RFC 3196 Internet Printing Protocol/1.1 November 2001
3423 client-error-document-format-not-supported: not applicable.
3425 client-error-conflicting-attributes: same as Print-Job, except
3426 that the Printer's "printer-is-accepting-jobs" attribute is not
3429 server-error-operation-not-supported: the Pause-Printer
3430 operation is not supported.
3432 server-error-device-error: not applicable.
3434 server-error-temporary-error: same as Print-Job, except no
3435 document data is involved.
3437 server-error-not-accepting-jobs: not applicable.
3439 server-error-job-canceled: not applicable.
3441 3.1.3.1.8 Resume-Printer
3443 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3444 Print-Job Response with the specialization's described for Pause-
3445 Printer are applicable to Resume-Printer. See Section 13 in
3446 [RFC2911] for a more complete description of each status code.
3448 For the following success status codes, the Printer object resumes
3449 scheduling jobs on all its devices.
3451 successful-ok: no request attributes were substituted or
3452 ignored (same as Print-Job).
3454 successful-ok-ignored-or-substituted-attributes: same as
3457 successful-ok-conflicting-attributes: same as Print-Job.
3459 For any of the error status codes, the Printer object does not resume
3462 server-error-operation-not-supported: the Resume-Printer
3463 operation is not supported.
3474 Hastings, et al. Informational [Page 62]
3476 RFC 3196 Internet Printing Protocol/1.1 November 2001
3479 3.1.3.1.8.1 What about Printers unable to change state due to an error
3482 If, in case, the IPP printer is unable to change its state due to
3483 some problem with the actual printer device (say, it is shut down or
3484 there is a media-jam as indicated in [RFC2911]), what should be the
3485 result of the "Resume-Printer" operation? Should it still change the
3486 'printer-state-reasons' and return success or should it fail ?
3488 The Resume-Printer operation must clear the 'paused' or 'moving-to-
3489 paused' 'printer-state-message'. The operation must return a
3490 'successful-ok' status code.
3492 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?
3494 If the Resume-Printer operation succeeds, what should be the value of
3495 "printer-state" and who should take care of the "printer-state"
3496 attribute value later on ?
3498 The Resume-Printer operation may change the "printer-state-reasons"
3501 The "printer-state" will change to one of three states:
3503 1. 'idle' - no additional jobs and no error conditions present
3505 2. 'processing' - job available and no error conditions present
3507 3. current state (i.e. no change) an error condition is present
3510 In the third case the "printer-state-reason" will be cleared by
3511 automata when it detects the error condition no longer exists. The
3512 "printer-state" will move to 'idle' or 'processing' when conditions
3513 permit. (i.e. no more error conditions)
3515 3.1.3.1.9 Purge-Printer
3517 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3518 Print-Job Response with the specialization's described for Pause-
3519 Printer are applicable to Purge-Printer. See Section 13 in [RFC2911]
3520 for a more complete description of each status code.
3522 For the following success status codes, the Printer object purges all
3525 successful-ok: no request attributes were substituted or
3526 ignored (same as Print-Job).
3530 Hastings, et al. Informational [Page 63]
3532 RFC 3196 Internet Printing Protocol/1.1 November 2001
3535 successful-ok-ignored-or-substituted-attributes: same as
3538 successful-ok-conflicting-attributes: same as Print-Job.
3540 For any of the error status codes, the Printer object does not purge
3543 server-error-operation-not-supported: the Purge-Printer
3544 operation is not supported.
3546 3.1.3.2 Job Operations
3548 3.1.3.2.1 Send-Document
3550 All of the Print-Job status codes described in Section 3.1.3.1.1
3551 Print-Job Response are applicable to the Get-Printer-Attributes
3552 operation with the following specialization's and differences. See
3553 Section 13 in [RFC2911] for a more complete description of each
3556 For the following success status codes, the document has been added
3557 to the specified Job object and the job's "number-of-documents"
3558 attribute has been incremented:
3560 successful-ok: no request attributes were substituted or
3561 ignored (same as Print-Job).
3563 successful-ok-ignored-or-substituted-attributes: same as
3566 successful-ok-conflicting-attributes: same as Print-Job.
3568 For the error status codes, no document has been added to the Job
3569 object and the job's "number-of-documents" attribute has not been
3572 client-error-not-possible: Same as Print-Job, except that the
3573 Printer's "printer-is-accepting-jobs" attribute is not
3574 involved, so that the client is able to finish submitting a job
3575 that was created with a Create-Job operation after this
3576 attribute has been set to 'true'. Another condition is that
3577 the state of the job precludes Send-Document, i.e., the job has
3586 Hastings, et al. Informational [Page 64]
3588 RFC 3196 Internet Printing Protocol/1.1 November 2001
3591 already been closed out by the client. However, if the IPP
3592 Printer closed out the job due to timeout, the 'client-error-
3593 timeout' error status SHOULD be returned instead.
3595 client-error-timeout: This request was sent after the Printer
3596 closed the job, because it has not received a Send-Document or
3597 Send-URI operation within the Printer's "multiple-operation-
3600 client-error-request-entity-too-large: same as Print-Job.
3602 client-error-conflicting-attributes: same as Print-Job, except
3603 that "ipp-attributes-fidelity" operation attribute is not
3606 server-error-operation-not-supported: the Send-Document
3607 request is not supported.
3609 server-error-not-accepting-jobs: not applicable.
3611 server-error-job-canceled: the job has been canceled by an
3612 operator or the system while the client was transmitting the
3617 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3618 Print-Job Response with the specialization's described for Send-
3619 Document are applicable to Send-URI. See Section 13 in [RFC2911] for
3620 a more complete description of each status code.
3622 client-error-uri-scheme-not-supported: the URI scheme supplied
3623 in the "document-uri" operation attribute is not supported and
3624 the "document-uri" attribute MUST be returned in the
3625 Unsupported Attributes group.
3627 server-error-operation-not-supported: the Send-URI operation is
3630 3.1.3.2.3 Cancel-Job
3632 All of the Print-Job status codes described in Section 3.1.3.1.1
3633 Print-Job Response are applicable to Cancel-Job with the following
3634 specializations and differences. See Section 13 in [RFC2911] for a
3635 more complete description of each status code.
3637 For the following success status codes, the Job object is being
3638 canceled or has been canceled:
3642 Hastings, et al. Informational [Page 65]
3644 RFC 3196 Internet Printing Protocol/1.1 November 2001
3647 successful-ok: no request attributes were substituted or
3648 ignored (same as Print-Job).
3650 successful-ok-ignored-or-substituted-attributes: same as
3653 successful-ok-conflicting-attributes: same as Print-Job.
3655 For any of the error status codes, the Job object has not been
3656 canceled or was previously canceled.
3658 client-error-not-possible: The request cannot be carried out
3659 because of the state of the Job object ('completed',
3660 'canceled', or 'aborted') or the state of the system.
3662 client-error-not-found: the target Printer and/or Job object
3665 client-error-gone: the target Printer and/or Job object no
3666 longer exists and no forwarding address is known.
3668 client-error-request-entity-too-large: same as Print-Job,
3669 except no document data is involved.
3671 client-error-document-format-not-supported: not applicable.
3673 client-error-attributes-or-values-not-supported: not
3674 applicable, since unsupported operation attributes and values
3677 client-error-conflicting-attributes: same as Print-Job, except
3678 that the Printer's "printer-is-accepting-jobs" attribute is not
3681 server-error-operation-not-supported: not applicable (Cancel-
3684 server-error-device-error: same as Print-Job, except no
3685 document data is involved.
3687 server-error-temporary-error: same as Print-Job, except no
3688 document data is involved.
3690 server-error-not-accepting-jobs: not applicable.
3692 server-error-job-canceled: not applicable.
3698 Hastings, et al. Informational [Page 66]
3700 RFC 3196 Internet Printing Protocol/1.1 November 2001
3703 3.1.3.2.4 Get-Job-Attributes
3705 All of the Print-Job status codes described in Section 3.1.3.1.1
3706 Print-Job Response are applicable to Get-Job-Attributes with the
3707 following specializations and differences. See Section 13 in
3708 [RFC2911] for a more complete description of each status code.
3710 For the following success status codes, the requested attributes are
3711 returned in Group 3 in the response:
3713 successful-ok: same as Get-Printer-Attributes (see section
3716 successful-ok-ignored-or-substituted-attributes: same as Get-
3717 Printer-Attributes (see section 3.1.3.1.5).
3719 successful-ok-conflicting-attributes: same as Get-Printer-
3720 Attributes (see section 3.1.3.1.5).
3722 For the error status codes, Group 3 is returned containing no
3723 attributes or is not returned at all.
3725 client-error-not-possible: Same as Print-Job, in addition the
3726 Printer object is not accepting any requests.
3728 client-error-document-format-not-supported: not applicable.
3730 client-error-attributes-or-values-not-supported: not
3733 client-error-uri-scheme-not-supported: not applicable.
3735 client-error-attributes-or-values-not-supported: not
3736 applicable, since unsupported operation attributes and/or
3737 values MUST be ignored and an appropriate success code returned
3740 client-error-conflicting-attributes: not applicable
3742 server-error-operation-not-supported: not applicable (since
3743 Get-Job-Attributes is REQUIRED).
3745 server-error-device-error: same as Print-Job, except no
3746 document data is involved.
3748 server-error-temporary-error: sane as Print-Job, except no
3749 document data is involved..
3754 Hastings, et al. Informational [Page 67]
3756 RFC 3196 Internet Printing Protocol/1.1 November 2001
3759 server-error-not-accepting-jobs: not applicable.
3761 server-error-job-canceled: not applicable.
3765 All of the Print-Job status codes described in Section 3.1.3.1.1
3766 Print-Job Response are applicable to Hold-Job with the following
3767 specializations and differences. See Section 13 in [RFC2911] for a
3768 more complete description of each status code.
3770 For the following success status codes, the Job object is being held
3773 successful-ok: no request attributes were substituted or
3774 ignored (same as Print-Job).
3776 successful-ok-ignored-or-substituted-attributes: same as
3779 successful-ok-conflicting-attributes: same as Print-Job.
3781 For any of the error status codes, the Job object has not been held
3782 or was previously held.
3784 client-error-not-possible: The request cannot be carried out
3785 because of the state of the Job object ('completed',
3786 'canceled', or 'aborted') or the state of the system.
3788 client-error-not-found: the target Printer and/or Job object
3791 client-error-gone: the target Printer and/or Job object no
3792 longer exists and no forwarding address is known.
3794 client-error-request-entity-too-large: same as Print-Job,
3795 except no document data is involved.
3797 client-error-document-format-not-supported: not applicable.
3799 client-error-conflicting-attributes: same as Print-Job, except
3800 that the Printer's "printer-is-accepting-jobs" attribute is not
3803 server-error-operation-not-supported: the Hold-Job operation is
3806 server-error-device-error: not applicable.
3810 Hastings, et al. Informational [Page 68]
3812 RFC 3196 Internet Printing Protocol/1.1 November 2001
3815 server-error-temporary-error: same as Print-Job, except no
3816 document data is involved.
3818 server-error-not-accepting-jobs: not applicable.
3820 server-error-job-canceled: not applicable.
3822 3.1.3.2.6 Release-Job
3824 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3825 Print-Job Response with the specialization's described for Hold-Job
3826 are applicable to Release-Job. See Section 13 in [RFC2911] for a
3827 more complete description of each status code.
3829 server-error-operation-not-supported: the Release-Job operation
3832 3.1.3.2.7 Restart-Job
3834 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3835 Print-Job Response with the specialization's described for Hold-Job
3836 are applicable to Restart-Job. See Section 13 in [RFC2911] for a
3837 more complete description of each status code.
3839 server-error-operation-not-supported: the Restart-Job operation
3842 3.1.3.2.7.1 Can documents be added to a restarted job?
3844 Assume I give a Create-Job request along with a set of 5 documents.
3845 All the documents get printed and the job state is moved to
3846 completed. I issue a Restart-Job request on the job. Now the issue
3847 is that, if I try to add new documents to the restarted job, will the
3848 IPP Server permit me to do so or return "client-error-not-possible "
3849 and again print those 5 jobs?
3851 A job can not move to the 'completed' state until all the documents
3852 have been processed. The 'last-document' flag indicates when the
3853 last document for a job is being sent from the client. This is the
3854 semantic equivalent of closing a job. No documents may be added once
3855 a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job
3856 is moved to the 'pending' job state and restarts the beginning on the
3857 same IPP Printer object with the same attribute values." 'number-
3858 of-documents' is a job attribute.
3866 Hastings, et al. Informational [Page 69]
3868 RFC 3196 Internet Printing Protocol/1.1 November 2001
3871 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
3874 In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
3875 responses, the client cannot depend on getting unsupported attributes
3876 returned in the Unsupported Attributes group that the client
3877 requested, but are not supported by the IPP object. However, such
3878 unsupported requested attributes will not be returned in the Job
3879 Attributes or Printer Attributes group (since they are unsupported).
3880 Furthermore, the IPP object is REQUIRED to return the 'successful-
3881 ok-ignored-or-substituted-attributes' status code, so that the client
3882 knows that not all that was requested has been returned.
3884 3.1.5 Sending empty attribute groups
3886 The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender
3887 not send an empty attribute group in a request or a response.
3888 However, they REQUIRE a receiver to accept an empty attribute group
3889 as equivalent to the omission of that group. So a client SHOULD omit
3890 the Job Template Attributes group entirely in a create operation that
3891 is not supplying any Job Template attributes. Similarly, an IPP
3892 object SHOULD omit an empty Unsupported Attributes group if there are
3893 no unsupported attributes to be returned in a response.
3895 The [RFC2910] specification REQUIRES a receiver to be able to receive
3896 either an empty attribute group or an omitted attribute group and
3897 treat them equivalently. The term "receiver" means an IPP object for
3898 a request and a client for a response. The term "sender' means a
3899 client for a request and an IPP object for a response.
3901 There is an exception to the rule for Get-Jobs when there are no
3902 attributes to be returned. [RFC2910] contains the following
3905 The syntax allows an xxx-attributes-tag to be present when the xxx-
3906 attribute-sequence that follows is empty. The syntax is defined this
3907 way to allow for the response of Get-Jobs where no attributes are
3908 returned for some job-objects. Although it is RECOMMENDED that the
3909 sender not send an xxx-attributes-tag if there are no attributes
3910 (except in the Get-Jobs response just mentioned), the receiver MUST
3911 be able to decode such syntax.
3922 Hastings, et al. Informational [Page 70]
3924 RFC 3196 Internet Printing Protocol/1.1 November 2001
3927 3.2 Printer Operations
3929 3.2.1 Print-Job operation
3931 3.2.1.1 Flow controlling the data portion of a Print-Job request (Issue
3934 A paused printer, or one that is stopped due to paper out or jam or
3935 spool space full or buffer space full, may flow control the data of a
3936 Print-Job operation (at the TCP/IP layer), so that the client is not
3937 able to send all the document data. Consequently, the Printer will
3938 not return a response until the condition is changed.
3940 The Printer should not return a Print-Job response with an error code
3941 in any of these conditions, since either the printer will be resumed
3942 and/or the condition will be freed either by human intervention or as
3945 In writing test scripts to test IPP Printers, the script must also be
3946 written not to expect a response, if the printer has been paused,
3947 until the printer is resumed, in order to work with all possible
3950 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)
3952 An IPP client submits a small job via Print-Job. By the time the IPP
3953 printer/print server is putting together a response to the operation,
3954 the job has finished printing and been removed as an object from the
3955 print system. What should the job-state be in the response?
3957 The Model suggests that the Printer return a response before it even
3958 accepts the document content. The Job Object Attributes are returned
3959 only if the IPP object returns one of the success status codes. Then
3960 the job-state would always be "pending" or "pending-held".
3962 This issue comes up for the implementation of an IPP Printer object
3963 as a server that forwards jobs to devices that do not provide job
3964 status back to the server. If the server is reasonably certain that
3965 the job completed successfully, then it should return the job-state
3966 as 'completed'. Also the server can keep the job in its "job
3967 history" long after the job is no longer in the device. Then a user
3968 could query the server and see that the job was in the 'completed'
3969 state and completed as specified by the jobs "time-at-completed"
3970 time, which would be the same as the server submitted the job to the
3978 Hastings, et al. Informational [Page 71]
3980 RFC 3196 Internet Printing Protocol/1.1 November 2001
3983 An alternative is for the server to respond to the client before or
3984 while sending the job to the device, instead of waiting until the
3985 server has finished sending the job to the device. In this case, the
3986 server can return the job's state as 'pending' with the 'job-
3987 outgoing' value in the job's "job-state-reasons" attribute.
3989 If the server doesn't know for sure whether the job completed
3990 successfully (or at all), it could return the (out-of-band) 'unknown'
3993 On the other hand, if the server is able to query the device and/or
3994 setup some sort of event notification that the device initiates when
3995 the job makes state transitions, then the server can return the
3996 current job state in the Print-Job response and in subsequent queries
3997 because the server knows what the job state is in the device (or can
4000 All of these alternatives depend on implementation of the server and
4003 3.2.2 Get-Printer-Attributes operation
4005 If a Printer supports the "printer-make-and-model" attribute and
4006 returns the .INF file model name of the printer in that attribute,
4007 the Microsoft client will automatically install the correct driver
4010 Clients which poll periodically for printer status or queued-job-
4011 count should use the "requested-attributes" operation attribute to
4012 limit the scope of the query in order to save Printer and network
4015 3.2.3 Get-Jobs operation
4017 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
4020 In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute
4021 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
4022 attribute be there too, and if it's not present what should the IPP
4025 [RFC2911] Section 8.3 describes the various cases of "requesting-
4026 user-name" being present or not for any operation. If the client
4027 does not supply a value for "requesting-user-name", the printer MUST
4028 assume that the client is supplying some anonymous name, such as
4034 Hastings, et al. Informational [Page 72]
4036 RFC 3196 Internet Printing Protocol/1.1 November 2001
4039 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
4041 When using the Get-Jobs operation a client implementer might choose
4042 to limit the number of jobs that the client shows on the first
4043 screenful. For example, if its UI can only display 50 jobs, it can
4044 defend itself against a printer that would otherwise return 500 jobs,
4045 perhaps taking a long time on a slow dial-up line. The client can
4046 then go and ask for a larger number of jobs in the background, while
4047 showing the user the first 50 jobs. Since the job history is returned
4048 in reverse order, namely the most recently completed jobs are
4049 returned first, the user is most likely interested in the first jobs
4050 that are returned. Limiting the number of jobs may be especially
4051 useful for a client that is requesting 'completed' jobs from a
4052 printer that keeps a long job history. Clients that don't mind
4053 sometimes getting very large responses, can omit the "limit"
4054 attribute in their Get-Jobs requests.
4056 3.2.4 Create-Job operation
4058 A Printer may respond to a Create-Job operation with "job-state"
4059 'pending' or 'pending-held' and " job-state-reason" 'job-data-
4060 insufficient' to indicate that operation has been accepted by the
4061 Printer, but the Printer is expecting additional document data before
4062 it can move the job into the 'processing' state. Alternatively, it
4063 may respond with "job-state" 'processing' and "job-state-reason"
4064 'job-incoming' to indicate that the Create-Job operation has been
4065 accepted by the Printer, but the Printer is expecting additional
4066 Send-Document and/or Send-URI operations and/or is
4067 accessing/accepting document data. The second alternative is for
4068 non-spooling Printers that don't implement the 'pending' state.
4070 Should the server wait for the "last-document" operation attribute
4071 set to 'true' before starting to "process" the job?
4073 It depends on implementation. Some servers spool the entire job,
4074 including all document data, before starting to process, so such an
4075 implementation would wait for the "last-document" before starting to
4076 process the job. If the time-out occurs without the "last-document",
4077 then the server takes one of the indicated actions in section 3.3.1
4078 in the [RFC2911] document. Other servers will start to process
4079 document data as soon as they have some. These are the so-called
4080 "non-spooling" printers. Currently, there isn't a way for a client to
4081 determine whether the Printer will spool all the data or will start
4082 to process (and print) as soon as it has some data.
4090 Hastings, et al. Informational [Page 73]
4092 RFC 3196 Internet Printing Protocol/1.1 November 2001
4099 The Validate-Job operation has been designed so that its
4100 implementation may be a part of the Print-Job operation. Therefore,
4101 requiring Validate-Job is not a burden on implementers. Also it is
4102 useful for client's to be able to count on its presence in all
4103 conformance implementations, so that the client can determine before
4104 sending a long document, whether the job will be accepted by the IPP
4109 The Restart-Job operation allows the reprocessing of a completed job.
4110 Some jobs store the document data on the printer. Jobs created using
4111 the Print-Job operation are an example. It is required that the
4112 printer retains the job data after the job has moved to a 'completed
4113 state' in order for the Restart-Job operation to succeed.
4115 Some jobs contain only a reference to the job data. A job created
4116 using the Print-URI is an example of such a job. When the Restart-
4117 Job operation is issued the job is reprocessed. The job data MUST be
4118 retrieved again to print the job.
4120 It is possible that a job fails while attempting to access the print
4121 data. When such a job is the target of a Restart-Job the Printer
4122 SHALL attempt to retrieve the job data again.
4126 4.1 Attribute Syntax's
4128 4.1.1 The 'none' value for empty sets (Issue 1.37)
4130 [RFC2911] states that the 'none' value should be used as the value of
4131 a 1setOf when the set is empty. In most cases, sets that are
4132 potentially empty contain keywords so the keyword 'none' is used, but
4133 for the 3 finishings attributes, the values are enums and thus the
4134 empty set is represented by the enum 3. Currently there are no other
4135 attributes with 1setOf values, which can be empty and can contain
4136 values that are not keywords. This exception requires special code
4137 and is a potential place for bugs. It would have been better if we
4138 had chosen an out-of-band value, either "no-value" or some new value,
4139 such as 'none'. Since we didn't, implementations have to deal with
4140 the different representations of 'none', depending on the attribute
4146 Hastings, et al. Informational [Page 74]
4148 RFC 3196 Internet Printing Protocol/1.1 November 2001
4151 4.1.2 Multi-valued attributes (Issue 1.31)
4153 What is the attribute syntax for a multi-valued attribute? Since
4154 some attributes support values in more than one data type, such as
4155 "media", "job-hold-until", and "job-sheets", IPP semantics associate
4156 the attribute syntax with each value, not with the attribute as a
4157 whole. The protocol associates the attribute syntax tag with each
4158 value. Don't be fooled, just because the attribute syntax tag comes
4159 before the attribute keyword. All attribute values after the first
4160 have a zero length attribute keyword as the indication of a
4161 subsequent value of the same attribute.
4163 4.1.3 Case Sensitivity in URIs (issue 1.6)
4165 IPP client and server implementations must be aware of the diverse
4166 uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and
4167 Host names as case insensitive but reminds us that the rest of the
4168 URL may well demonstrate case sensitivity. When creating URL's for
4169 fields where the choice is completely arbitrary, it is probably best
4170 to select lower case. However, this cannot be guaranteed and
4171 implementations MUST NOT rely on any fields being case-sensitive or
4172 case-insensitive in the URL beyond the URL scheme and host name
4175 The reason that the IPP specification does not make any restrictions
4176 on URIs, is so that implementations of IPP may use off-the-shelf
4177 components that conform to the standards that define URIs, such as
4178 RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these
4179 specifications for rules of matching, comparison, and case-
4182 It is also recommended that System Administrators and implementations
4183 avoid creating URLs for different printers that differ only in their
4184 case. For example, don't have Printer1 and printer1 as two different
4187 Example of equivalent URI's
4189 http://abc.com:80/~smith/home.html
4191 http://ABC.com/%7Esmith/home.html
4193 http:/ABC.com:/%7esmith/home.html
4195 Example of equivalent URI's using the IPP scheme
4197 ipp://abc.com:631/~smith/home.html
4202 Hastings, et al. Informational [Page 75]
4204 RFC 3196 Internet Printing Protocol/1.1 November 2001
4207 ipp://ABC.com/%7Esmith/home.html
4209 http:/ABC.com:631/%7esmith/home.html
4211 The HTTP/1.1 specification [RFC2616] contains more details on
4214 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage
4216 The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes
4217 that have two components. The first component is the 'language'
4218 component that can contain up to 63 octets. The second component is
4219 the 'text' or 'name' component. The maximum length of these are 1023
4220 octets and 255 octets respectively. The definition of attributes
4221 with either syntax may further restrict the length (e.g., printer-
4224 The length of the 'language' component has no effect on the allowable
4225 length of 'text' in 'textWithLanguage' or the length of 'name' in
4228 4.2 Job Template Attributes
4230 4.2.1 multiple-document-handling(type2 keyword)
4232 4.2.1.1 Support of multiple document jobs
4234 IPP/1.0 is silent on which of the four effects an implementation
4235 would perform if it supports Create-Job, but does not support
4236 "multiple-document-handling" or multiple documents per job. IPP/1.1
4237 was changed so that a Printer could support Create-Job without having
4238 to support multiple document jobs. The "multiple-document-jobs-
4239 supported" (boolean) Printer description attribute was added to
4240 IPP/1.1 along with the 'server-error-multiple-document-jobs-not-
4241 supported' status code for a Printer to indicate whether or not it
4242 supports multiple document jobs, when it supports the Create-Job
4243 operation. Also IPP/1.1 was clarified that the Printer MUST support
4244 the "multiple-document-handling" (type2 keyword) Job Template
4245 attribute with at least one value if the Printer supports multiple
4248 4.3 Job Description Attributes
4250 4.3.1 Getting the date and time of day
4252 The "date-time-at-creation", "date-time-at-processing", and "date-
4253 time-at-completed" attributes are returned as dateTime syntax. These
4254 attributes are OPTIONAL for a Printer to support. However, there are
4258 Hastings, et al. Informational [Page 76]
4260 RFC 3196 Internet Printing Protocol/1.1 November 2001
4263 various ways for a Printer to get the date and time of day. Some
4266 1. A Printer can get time from an NTP timeserver if there's one
4267 reachable on the network . See RFC 1305. Also DHCP option 32
4268 in RFC 2132 returns the IP address of the NTP server.
4270 2. Get the date and time at startup from a human operator
4272 3. Have an operator set the date and time using a web
4273 administrative interface
4275 4. Get the date and time from incoming HTTP requests, though the
4276 problems of spoofing need to be considered. Perhaps comparing
4277 several HTTP requests could reduce the chances of spoofing.
4279 5. Internal date time clock battery driven.
4281 6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
4283 4.4 Printer Description Attributes
4285 4.4.1 queued-job-count (integer(0:MAX))
4287 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?
4289 The reason that "queued-job-count" is RECOMMENDED, is that some
4290 clients look at that attribute alone when summarizing the status of a
4291 list of printers, instead of doing a Get-Jobs to determine the number
4292 of jobs in the queue. Implementations that fail to support the
4293 "queued-job-count" will cause that client to display 0 jobs when
4294 there are actually queued jobs.
4296 We would have made it a REQUIRED Printer attribute, but some
4297 implementations had already been completed before the issue was
4298 raised, so making it a SHOULD was a compromise.
4300 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is
4303 The "queued-job-count" is not a good measure of how busy the printer
4304 is when there are held jobs. A future registration could be to add a
4305 "held-job-count" (or an "active-job-count") Printer Description
4306 attribute if experience shows that such an attribute (combination) is
4307 needed to quickly indicate how busy a printer really is.
4314 Hastings, et al. Informational [Page 77]
4316 RFC 3196 Internet Printing Protocol/1.1 November 2001
4319 4.4.2 printer-current-time (dateTime)
4321 A Printer implementation MAY support this attribute by obtaining the
4322 date and time by any number of implementation-dependent means at
4323 startup or subsequently. Examples include:
4325 1. an internal date time clock,
4327 2. from the operator at startup using the console,
4329 3. from an operator using an administrative web page,
4331 4. from HTTP headers supplied in client requests,
4333 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
4335 6. from the network, using NTP [RFC1305] or DHCP option 32
4336 [RFC2132] that returns the IP address of the NTP server.
4338 If an implementation supports this attribute by obtaining the current
4339 time from the network (at startup or later), but the time is not
4340 available, then the implementation MUST return the value of this
4341 attribute using the out-of-band 'no-value' meaning not configured.
4342 See the beginning of section 4.1.
4344 Since the new "date-and-time-at-xxx" Job Description attributes refer
4345 to the "printer-current-time", they will be covered also.
4349 Must the operational attribute for printer-uri match one of the
4350 values in "printer-uri-supported"?
4352 A forgiving printer implementation would not reject the operation.
4353 But the implementation has its rights to reject a printer or job
4354 operation if the operational attribute printer-uri is not a value of
4355 the printer-uri-supported. The printer might not be improperly
4356 configured. The request obviously reached the printer. The printer
4357 could treat the printer-uri as the logical equivalent of a value in
4358 the printer-uri-supported. It would be implementation dependent for
4359 which value, and associated security policy, would apply. This does
4360 also apply to a job object specified with a printer-uri and job-id,
4361 or with a job-uri. See section 4.1.3 for how to compare URI's.
4370 Hastings, et al. Informational [Page 78]
4372 RFC 3196 Internet Printing Protocol/1.1 November 2001
4377 The IPP object model does not prohibit a job that contains no
4378 documents. Such a job may be created in a number of ways including a
4379 'create-job' followed by an 'add-document' that contains no data and
4380 has the 'last-document' flag set.
4382 An empty job is processed just as any other job. The operation that
4383 "closes" an empty job is not rejected because the job is empty. If
4384 no other conditions exist, other than the job is empty, the response
4385 to the operation will indicate success. After the job is scheduled
4386 and processed, the job state SHALL be 'completed'.
4388 There will be some variation in the value(s) of the "job-state-
4389 reasons" attribute. It is required that if no conditions, other than
4390 the job being empty, exist the "job-state-reasons" SHALL include the
4392 'completed-successfully'. If other conditions existed, the
4393 'completed-with-warnings' or 'completed-with-errors' values may be
4396 5 Directory Considerations
4398 5.1 General Directory Schema Considerations
4400 The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object
4401 attributes for directory schemas. See [RFC2911] APPENDIX E: Generic
4404 The SLP printer template is defined in the "Definition of the Printer
4405 Abstract Service Type v2.0" document [svrloc-printer]. The LDAP
4406 printer template is defined in the "Internet Printing Protocol (IPP):
4407 LDAP Schema for Printer Services" document [ldap-printer]. Both
4408 documents systematically add "printer-" to any attribute that doesn't
4409 already start with "printer-" in order to keep the printer directory
4410 attributes distinct from other directory attributes. Also, instead
4411 of using "printer-uri-supported", "uri-authentication-supported", and
4412 "uri-security-supported", they use a "printer-xri-supported"
4413 attribute with special syntax to contain all of the same information
4414 in a single attribute.
4416 5.2 IPP Printer with a DNS name
4418 If the IPP printer has a DNS name should there be at least two values
4419 for the printer-uri-supported attribute. One URL with the fully
4420 qualified DNS name the other with the IP address in the URL?
4426 Hastings, et al. Informational [Page 79]
4428 RFC 3196 Internet Printing Protocol/1.1 November 2001
4431 The printer may contain one or the other or both. It's up to the
4432 administrator to configure this attribute.
4434 6 Security Considerations
4436 The security considerations given in [RFC2911] Section 8 "Security
4437 Considerations" all apply to this document. In addition, the
4438 following sub-sections describes security consideration that have
4439 arisen as a result of implementation testing.
4441 6.1 Querying jobs with IPP that were submitted using other job
4442 submission protocols (Issue 1.32)
4444 The following clarification was added to [RFC2911] section 8.5:
4446 8.5 Queries on jobs submitted using non-IPP protocols If the
4447 device that an IPP Printer is representing is able to accept jobs
4448 using other job submission protocols in addition to IPP, it is
4449 RECOMMEND that such an implementation at least allow such
4450 "foreign" jobs to be queried using Get-Jobs returning "job-id" and
4451 "job-uri" as 'unknown'. Such an implementation NEED NOT support
4452 all of the same IPP job attributes as for IPP jobs. The IPP
4453 object returns the 'unknown' out-of-band value for any requested
4454 attribute of a foreign job that is supported for IPP jobs, but not
4457 It is further RECOMMENDED, that the IPP Printer generate "job-id"
4458 and "job-uri" values for such "foreign jobs", if possible, so that
4459 they may be targets of other IPP operations, such as Get-Job-
4460 Attributes and Cancel-Job. Such an implementation also needs to
4461 deal with the problem of authentication of such foreign jobs. One
4462 approach would be to treat all such foreign jobs as belonging to
4463 users other than the user of the IPP client. Another approach
4464 would be for the foreign job to belong to 'anonymous'. Only if
4465 the IPP client has been authenticated as an operator or
4466 administrator of the IPP Printer object, could the foreign jobs be
4467 queried by an IPP request. Alternatively, if the security policy
4468 were to allow users to query other users' jobs, then the foreign
4469 jobs would also be visible to an end-user IPP client using Get-
4470 Jobs and Get-Job- Attributes.
4472 Thus IPP MAY be implemented as a "universal" protocol that
4473 provides access to jobs submitted with any job submission
4474 protocol. As IPP becomes widely implemented, providing a more
4475 universal access makes sense.
4482 Hastings, et al. Informational [Page 80]
4484 RFC 3196 Internet Printing Protocol/1.1 November 2001
4487 7 Encoding and Transport
4489 This section discusses various aspects of IPP/1.1 Encoding and
4490 Transport [RFC2910].
4492 A server is not required to send a response until after it has
4493 received the client's entire request. Hence, a client must not
4494 expect a response until after it has sent the entire request.
4495 However, we recommend that the server return a response as soon as
4496 possible if an error is detected while the client is still sending
4497 the data, rather than waiting until all of the data is received.
4498 Therefore, we also recommend that a client listen for an error
4499 response that an IPP server MAY send before it receives all the data.
4500 In this case a client, if chunking the data, can send a premature
4501 zero-length chunk to end the request before sending all the data (and
4502 so the client can keep the connection open for other requests, rather
4503 than closing it). If the request is blocked for some reason, a
4504 client MAY determine the reason by opening another connection to
4505 query the server using Get-Printer-Attributes.
4507 IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793]
4508 to throttle clients when Printers are busy. Therefore, it is
4509 perfectly normal for an IPP client transmitting a Job to be blocked
4510 for a really long time. Accordingly, socket timeouts must be
4511 avoided. Some socket implementations have a timeout option, which
4512 specifies how long a write operation on a socket can be blocked
4513 before it times out and the blocking ends. A client should set this
4514 option for infinite timeout when transmitting Job submissions.
4516 Some IPP client applications might be able to perform other useful
4517 work while a Job transmission is blocked. For example, the client
4518 may have other jobs that it could transmit to other Printers
4519 simultaneously. A client may have a GUI, which must remain
4520 responsive to the user while the Job transmission is blocked. These
4521 clients should be designed to spawn a thread to handle the Job
4522 transmission at its own pace, leaving the main application free to do
4523 other work. Alternatively, single-threaded applications could use
4526 Some Printer conditions, such as jam or lack of paper, could cause a
4527 client to be blocked indefinitely. Clients may open additional
4528 connections to the Printer to Get-Printer-Attributes, determine the
4529 state of the device, alert a user if the printer is stopped, and let
4530 a user decide whether to abort the job transmission or not.
4532 In the following sections, there are tables of all HTTP headers,
4533 which describe their use in an IPP client or server. The following
4534 is an explanation of each column in these tables.
4538 Hastings, et al. Informational [Page 81]
4540 RFC 3196 Internet Printing Protocol/1.1 November 2001
4543 - the "header" column contains the name of a header
4544 - the "request/client" column indicates whether a client sends the
4546 - the "request/ server" column indicates whether a server supports
4547 the header when received.
4548 - the "response/ server" column indicates whether a server sends
4550 - the "response /client" column indicates whether a client
4551 supports the header when received.
4552 - the "values and conditions" column specifies the allowed header
4553 values and the conditions for the header to be present in a
4556 The table for "request headers" does not have columns for responses,
4557 and the table for "response headers" does not have columns for
4560 The following is an explanation of the values in the "request/client"
4561 and "response/ server" columns.
4563 - must: the client or server MUST send the header,
4564 - must-if: the client or server MUST send the header when the
4565 condition described in the "values and conditions" column is
4567 - may: the client or server MAY send the header
4568 - not: the client or server SHOULD NOT send the header. It is not
4569 relevant to an IPP implementation.
4571 The following is an explanation of the values in the
4572 "response/client" and "request/ server" columns.
4574 - must: the client or server MUST support the header,
4575 - may: the client or server MAY support the header
4576 - not: the client or server SHOULD NOT support the header. It is
4577 not relevant to an IPP implementation.
4594 Hastings, et al. Informational [Page 82]
4596 RFC 3196 Internet Printing Protocol/1.1 November 2001
4601 The following is a table for the general headers.
4603 General- Request Response Values and Conditions
4606 Client Server Server Client
4609 Cache- not must not "no-cache" only
4612 Connection must- must must- must "close" only. Both
4613 if if client and server
4616 duration of a sequence
4618 client and server MUST
4620 for the last operation
4623 Date may may must may per RFC 1123 [RFC1123]
4627 Pragma must not must not "no-cache" only
4629 Transfer- must- must must- must "chunked" only. Header
4630 Encoding if if MUST be present if
4634 Upgrade not not not not
4650 Hastings, et al. Informational [Page 83]
4652 RFC 3196 Internet Printing Protocol/1.1 November 2001
4657 The following is a table for the request headers.
4659 Request- Client Server Request Values and Conditions
4662 Accept may must "application/ipp" only. This
4663 value is the default if the
4666 Accept- not not Charset information is within the
4667 Charset application/ipp entity
4669 Accept- may must empty and per RFC 2616 [RFC2616]
4670 Encoding and IANA registry for content-
4673 Accept- not not language information is within the
4674 Language application/ipp entity
4676 Authorization must- must per RFC 2616. A client MUST send
4677 if this header when it receives a
4678 401 "Unauthorized" response and
4679 does not receive a "Proxy-
4680 Authenticate" header.
4682 From not not per RFC 2616. Because RFC
4683 recommends sending this header
4684 only with the user's approval,
4685 it is not very useful
4687 Host must must per RFC 2616
4691 If-Modified- not not
4694 If-None-Match not not
4706 Hastings, et al. Informational [Page 84]
4708 RFC 3196 Internet Printing Protocol/1.1 November 2001
4711 Request- Client Server Request Values and Conditions
4714 Max-Forwards not not
4716 Proxy- must- not per RFC 2616. A client MUST send
4717 Authorizati if this header when it receives a
4718 on 401 "Unauthorized" response and
4719 a "Proxy-Authenticate" header.
4762 Hastings, et al. Informational [Page 85]
4764 RFC 3196 Internet Printing Protocol/1.1 November 2001
4767 7.3 Response Headers
4769 The following is a table for the request headers.
4771 Response- Server Client Response Values and Conditions
4775 Accept-Ranges not not
4779 Location must- may per RFC 2616. When URI needs
4782 Proxy- must per RFC 2616
4786 Public may may per RFC 2616
4788 Retry-After may may per RFC 2616
4794 Warning may may per RFC 2616
4796 WWW- must- must per RFC 2616. When a server needs
4797 Authenticate if to authenticate a client.
4818 Hastings, et al. Informational [Page 86]
4820 RFC 3196 Internet Printing Protocol/1.1 November 2001
4825 The following is a table for the entity headers.
4827 Entity-Header Request Response Values and
4830 Client Server Server Client
4832 Allow not not not not
4834 Content-Base not not not not
4836 Content- may must must must per RFC 2616 and
4837 Encoding IANA registry for
4840 Content- not not not not Application/ipp
4841 Language handles language
4843 Content- must- must must- must the length of the
4844 Length if if message-body per
4851 Content- not not not not
4854 Content-MD5 may may may may per RFC 2616
4856 Content-Range not not not not
4858 Content-Type must must must must "application/ipp"
4861 ETag not not not not
4863 Expires not not not not
4865 Last-Modified not not not not
4874 Hastings, et al. Informational [Page 87]
4876 RFC 3196 Internet Printing Protocol/1.1 November 2001
4879 7.5 Optional support for HTTP/1.0
4881 IPP implementations consist of an HTTP layer and an IPP layer. In
4882 the following discussion, the term "client" refers to the HTTP client
4883 layer and the term "server" refers to the HTTP server layer. The
4884 Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST
4885 be supported by all clients and all servers. However, a client
4886 and/or a server implementation may choose to also support HTTP 1.0.
4888 This option means that a server may choose to communicate with a
4889 (non-conforming) client that only supports HTTP 1.0. In such cases
4890 the server should not use any HTTP 1.1 specific parameters or
4891 features and should respond using HTTP version number 1.0.
4893 This option also means that a client may choose to communicate with a
4894 (non-conforming) server that only supports HTTP 1.0. In such cases,
4895 if the server responds with an HTTP 'unsupported version number' to
4896 an HTTP 1.1 request, the client should retry using HTTP version
4899 7.6 HTTP/1.1 Chunking
4901 7.6.1 Disabling IPP Server Response Chunking
4903 Clients MUST anticipate that the HTTP/1.1 server may chunk responses
4904 and MUST accept them in responses. However, a (non-conforming) HTTP
4905 client that is unable to accept chunked responses may attempt to
4906 request an HTTP 1.1 server not to use chunking in its response to an
4907 operation by using the following HTTP header:
4911 This mechanism should not be used by a server to disable a client
4912 from chunking a request, since chunking of document data is an
4913 important feature for clients to send long documents.
4915 7.6.2 Warning About the Support of Chunked Requests
4917 This section describes some problems with the use of chunked requests
4918 and HTTP/1.1 servers.
4920 The HTTP/1.1 standard [RFC2616] requires that conforming servers
4921 support chunked requests for any method. However, in spite of this
4922 requirement, some HTTP/1.1 implementations support chunked responses
4923 in the GET method, but do not support chunked POST method requests.
4924 Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
4925 servlets [Servlet] require that the client supply a Content-Length.
4926 These implementations might reject a chunked POST method and return a
4930 Hastings, et al. Informational [Page 88]
4932 RFC 3196 Internet Printing Protocol/1.1 November 2001
4935 411 status code (Length Required), might attempt to buffer the
4936 request and run out of room returning a 413 status code (Request
4937 Entity Too Large), or might successfully accept the chunked request.
4939 Because of this lack of conformance of HTTP servers to the HTTP/1.1
4940 standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP
4941 Printer object implementation support chunked requests and that
4942 conforming clients accept chunked responses. Therefore, IPP object
4943 implementers are warned to seek HTTP server implementations that
4944 support chunked POST requests in order to conform to the IPP standard
4945 and/or use implementation techniques that support chunked POST
4950 [CGI] CGI/1.1 (http://www.w3.org/CGI/).
4952 [IANA-CS] IANA Registry of Coded Character Sets:
4953 http://www.iana.org/assignments/character-sets
4955 [ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald,
4956 "Internet Printing Protocol (IPP): LDAP Schema for
4957 Printer Services", Work in Progress.
4959 [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
4960 RFC 793, September 1981.
4962 [RFC1123] Braden, R., "Requirements for Internet Hosts -
4963 Application and Support", RFC 1123, October, 1989.
4965 [RFC2026] Bradner, S., "The Internet Standards Process --
4966 Revision 3", BCP 9, RFC 2026, October 1996.
4968 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4969 Requirement Levels", BCP 14, RFC 2119 , March 1997.
4971 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
4972 "Uniform Resource Identifiers (URI): Generic
4973 Syntax", RFC 2396, August 1998.
4975 [RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
4976 and P. Powell, "Internet Printing Protocol/1.0:
4977 Model and Semantics", RFC 2566, April 1999.
4986 Hastings, et al. Informational [Page 89]
4988 RFC 3196 Internet Printing Protocol/1.1 November 2001
4991 [RFC2566] Herriot, R., Butler, S., Moore, P. and R. Turner,
4992 "Internet Printing Protocol/1.0: Encoding and
4993 Transport", RFC 2565, April 1999.
4995 [RFC2567] Wright, D., "Design Goals for an Internet Printing
4996 Protocol", RFC 2567, April 1999.
4998 [RFC2568] Zilles, S., "Rationale for the Structure and Model
4999 and Protocol for the Internet Printing Protocol",
5000 RFC 2568, April 1999.
5002 [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J.
5003 Martin, "Mapping between LPD and IPP Protocols",
5004 RFC 2569, April 1999.
5006 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
5007 Masinter, L., Leach, P. and T. Berners-Lee,
5008 "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
5011 [RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner,
5012 "Internet Printing Protocol/1.0: Encoding and
5013 Transport", RFC 2910, September, 2000.
5015 [RFC2911] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
5016 and P. Powell, "Internet Printing Protocol/1.0:
5017 Model and Semantics", RFC 2911, September, 2000.
5019 [Servlet] Servlet Specification Version 2.1
5020 (http://java.sun.com/products/servlet/2.1/
5023 [svrloc-printer] St. Pierre, P., Isaacson, S., McDonald, I.,
5024 "Definition of the Printer Abstract Service Type
5025 v2.0", http://www.isi.edu/in-
5026 notes/iana/assignments/svrloc-
5027 templates/printer.2.0.en (IANA Registered, May 27,
5030 [SSL] Netscape, The SSL Protocol, Version 3, (Text
5031 version 3.02), November 1996.
5042 Hastings, et al. Informational [Page 90]
5044 RFC 3196 Internet Printing Protocol/1.1 November 2001
5047 9. Authors' Addresses
5052 El Segundo, CA 90245
5054 EMail: hastings@cp10.es.xerox.com
5058 Independent Consultant
5059 1601 N. Sepulveda Blvd. #505
5060 Manhattan Beach, CA 90266
5062 Email: carl@manros.com
5067 IBM Printing Systems Co
5071 EMail: Kugler@us.ibm.com
5075 i-data Printing Systems
5077 2880 Bagsvaerd, Denmark
5079 EMail: hh@I-data.com
5087 EMail: PZehler@crt.xerox.com
5098 Hastings, et al. Informational [Page 91]
5100 RFC 3196 Internet Printing Protocol/1.1 November 2001
5103 IPP Web Page: http://www.pwg.org/ipp/
5104 IPP Mailing List: ipp@pwg.org
5106 To subscribe to the ipp mailing list, send the following email:
5108 1) send it to majordomo@pwg.org
5109 2) leave the subject line blank
5110 3) put the following two lines in the message body:
5114 Implementers of this specification document are encouraged to join
5115 the IPP Mailing List in order to participate in any discussions of
5116 clarification issues and review of registration proposals for
5117 additional attributes and values. In order to reduce spam the
5118 mailing list rejects mail from non-subscribers, so you must subscribe
5119 to the mailing list in order to send a question or comment to the
5124 Chuck Adams - Tektronix Shivaun Albright - HP
5126 Stefan Andersson - Axis Jeff Barnett - IBM
5128 Ron Bergman - Hitachi Koki Dennis Carney - IBM
5131 Keith Carter - IBM Angelo Caruso - Xerox
5133 Rajesh Chawla - TR Computing Nancy Chen - Okidata
5136 Josh Cohen - Microsoft Jeff Copeland - QMS
5138 Andy Davidson - Tektronix Roger deBry - IBM
5140 Maulik Desai - Auco Mabry Dozier - QMS
5142 Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
5145 Steve Gebert - IBM Sue Gleeson - Digital
5147 Charles Gordon - Osicom Brian Grimshaw - Apple
5149 Jerry Hadsell - IBM Richard Hart - Digital
5154 Hastings, et al. Informational [Page 92]
5156 RFC 3196 Internet Printing Protocol/1.1 November 2001
5159 Tom Hastings - Xerox Henrik Holst - I-data
5161 Stephen Holmstead Zhi-Hong Huang - Zenographics
5163 Scott Isaacson - Novell Babek Jahromi - Microsoft
5165 Swen Johnson - Xerox David Kellerman - Northlake
5168 Robert Kline - TrueSpectra Charles Kong - Panasonic
5170 Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
5172 Takami Kurono - Brother Rick Landau - Digital
5174 Scott Lawrence - Agranot Systems Greg LeClair - Epson
5176 Dwight Lewis - Lexmark Harry Lewis - IBM
5178 Tony Liao - Vivid Image Roy Lomicka - Digital
5180 Pete Loya - HP Ray Lutz - Cognisys
5182 Mike MacKay - Novell, Inc. David Manchala - Xerox
5184 Carl-Uno Manros - Xerox Jay Martin - Underscore
5186 Stan McConnell - Xerox Larry Masinter - Xerox
5188 Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
5190 Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
5192 Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
5194 Pat Nogay - IBM Ron Norton - Printronics
5196 Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
5198 Patrick Powell - Astart Jeff Rackowitz - Intermec
5201 Eric Random - Peerless Rob Rhoads - Intel
5203 Xavier Riley - Xerox Gary Roberts - Ricoh
5205 David Roach - Unisys Stuart Rowley - Kyocera
5210 Hastings, et al. Informational [Page 93]
5212 RFC 3196 Internet Printing Protocol/1.1 November 2001
5215 Yuji Sasaki - Japan Computer Richard Schneider - Epson
5218 Kris Schoff - HP Katsuaki Sekiguchi - Canon
5220 Bob Setterbo - Adobe Gail Songer - Peerless
5222 Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
5224 Mike Timperman - Lexmark Atsushi Uchino - Epson
5226 Shigeru Ueda - Canon Bob Von Andel - Allegro Software
5228 William Wagner - NetSilicon/DPI Jim Walker - DAZEL
5230 Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
5232 Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
5234 Jasper Wong - Xionics Don Wright - Lexmark
5236 Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
5238 Michael Yeung - Toshiba Lloyd Young - Lexmark
5240 Atsushi Yuki - Kyocera Peter Zehler - Xerox
5242 William Zhang- Canon Information Frank Zhao - Panasonic
5245 Steve Zilles - Adobe Rob Zirnstein - Canon
5248 10. Description of the Base IPP Documents
5250 In addition to this document, the base set of IPP documents includes:
5252 Design Goals for an Internet Printing Protocol [RFC2567]
5253 Rationale for the Structure and Model and Protocol for the
5255 Printing Protocol [RFC2568]
5256 Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
5257 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
5258 Mapping between LPD and IPP Protocols [RFC2569]
5260 The "Design Goals for an Internet Printing Protocol" document takes a
5261 broad look at distributed printing functionality, and it enumerates
5262 real-life scenarios that help to clarify the features that need to be
5266 Hastings, et al. Informational [Page 94]
5268 RFC 3196 Internet Printing Protocol/1.1 November 2001
5271 included in a printing protocol for the Internet. It identifies
5272 requirements for three types of users: end users, operators, and
5273 administrators. It calls out a subset of end user requirements that
5274 are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator
5275 operations have been added to IPP/1.1 [RFC2911, RFC2910].
5277 The "Rationale for the Structure and Model and Protocol for the
5278 Internet Printing Protocol" document describes IPP from a high level
5279 view, defines a roadmap for the various documents that form the suite
5280 of IPP specification documents, and gives background and rationale
5281 for the IETF IPP working group's major decisions.
5283 The "Internet Printing Protocol/1.1: Model and Semantics" document
5284 describes a simplified model with abstract objects, their attributes,
5285 and their operations. The model introduces a Printer and a Job. The
5286 Job supports multiple documents per Job. The model document also
5287 addresses how security, internationalization, and directory issues
5290 The "Internet Printing Protocol/1.1: Encoding and Transport" document
5291 is a formal mapping of the abstract operations and attributes defined
5292 in the model document onto HTTP/1.1 [RFC2616]. It also defines the
5293 encoding rules for a new Internet MIME media type called
5294 "application/ipp". This document also defines the rules for
5295 transporting a message body over HTTP whose Content-Type is
5296 "application/ipp". This document defines the 'ipp' scheme for
5297 identifying IPP printers and jobs.
5299 The "Mapping between LPD and IPP Protocols" document gives some
5300 advice to implementers of gateways between IPP and LPD (Line Printer
5301 Daemon) implementations.
5322 Hastings, et al. Informational [Page 95]
5324 RFC 3196 Internet Printing Protocol/1.1 November 2001
5327 11 Full Copyright Statement
5329 Copyright (C) The Internet Society (2001). All Rights Reserved.
5331 This document and translations of it may be copied and furnished to
5332 others, and derivative works that comment on or otherwise explain it
5333 or assist in its implementation may be prepared, copied, published
5334 and distributed, in whole or in part, without restriction of any
5335 kind, provided that the above copyright notice and this paragraph are
5336 included on all such copies and derivative works. However, this
5337 document itself may not be modified in any way, such as by removing
5338 the copyright notice or references to the Internet Society or other
5339 Internet organizations, except as needed for the purpose of
5340 developing Internet standards in which case the procedures for
5341 copyrights defined in the Internet Standards process must be
5342 followed, or as required to translate it into languages other than
5345 The limited permissions granted above are perpetual and will not be
5346 revoked by the Internet Society or its successors or assigns.
5348 This document and the information contained herein is provided on an
5349 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
5350 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
5351 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
5352 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
5353 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5357 Funding for the RFC Editor function is currently provided by the
5378 Hastings, et al. Informational [Page 96]