idnits 2.17.1 draft-ietf-ipp-implementers-guide-v11-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 55 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([RFC2568], [RFC2569], [RFC2910], [RFC2911], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document obsoletes RFC2639, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC2910, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 340 has weird spacing: '...section corre...' == Line 411 has weird spacing: '...Attribu s ...' == Line 453 has weird spacing: '...Release ns...' == Line 484 has weird spacing: '...Documen d- ...' == Line 485 has weird spacing: '...tar Job tio...' == (50 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 25, 2001) is 8485 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2568' is mentioned on line 59, but not defined == Missing Reference: 'RFC2044' is mentioned on line 2140, but not defined ** Obsolete undefined reference: RFC 2044 (Obsoleted by RFC 2279) == Missing Reference: 'IANA-CS' is mentioned on line 2141, but not defined == Missing Reference: 'RFC1305' is mentioned on line 3212, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) == Missing Reference: 'RFC2132' is mentioned on line 3213, but not defined == Missing Reference: 'RFC 793' is mentioned on line 3350, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Unused Reference: 'RFC793' is defined on line 3662, but no explicit reference was found in the text == Unused Reference: 'RFC2396' is defined on line 3677, but no explicit reference was found in the text == Unused Reference: 'SSL' is defined on line 3725, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CGI' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2566 (ref. 'RFC2565') (Obsoleted by RFC 2911) ** Obsolete normative reference: RFC 2565 (ref. 'RFC2566') (Obsoleted by RFC 2910) ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-req (ref. 'RFC2567') ** Downref: Normative reference to an Experimental RFC: RFC 2569 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) -- Possible downref: Non-RFC (?) normative reference: ref. 'Servlet' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' Summary: 19 errors (**), 0 flaws (~~), 19 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 draft-ietf-ipp-implementers-guide-v11-02.txt 4 [Obsoletes RFC 2639] T. Hastings 5 Xerox Corporation 6 C. Manros 7 Xerox Corporation 8 C. Kugler 9 IBM Printing Systems Co 10 H. Holst 11 i-data Printing Systems 12 P. Zehler 13 Xerox Corporation 14 January 25, 2001 16 Internet Printing Protocol/1.1: Implementer's Guide 18 Copyright (C) The Internet Society (2001). All Rights Reserved. 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 24 working documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed as 37 http://www.ietf.org/shadow.html. 39 Abstract 40 This document is one of a set of documents, which together describe 41 all aspects of a new Internet Printing Protocol (IPP). IPP is an 42 application level protocol that can be used for distributed printing 43 using Internet tools and technologies. This document contains 44 information that supplements the IPP Model and Semantics [RFC2911] 45 and the IPP Transport and Encoding [RFC2910] documents. It is 46 intended to help implementers understand IPP/1.1, as well as IPP/1.0, 47 and some of the considerations that may assist them in the design of 48 their client and/or IPP object implementations. For example, a 49 typical order of processing requests is given, including error 50 checking. Motivation for some of the specification decisions is also 51 included. 53 This document obsoletes RFC 2639 which was the Implementer's Guide 54 for IPP/1.0. 56 The full set of IPP documents includes: 57 Design Goals for an Internet Printing Protocol [RFC2567] 58 Rationale for the Structure and Model and Protocol for the Internet 59 Printing Protocol [RFC2568] 60 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 61 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 62 Mapping between LPD and IPP Protocols [RFC2569] 63 The document, "Design Goals for an Internet Printing Protocol", takes 64 a broad look at distributed printing functionality, and it enumerates 65 real-life scenarios that help to clarify the features that need to be 66 included in a printing protocol for the Internet. It identifies 67 requirements for three types of users: end users, operators, and 68 administrators. The design goal document calls out a subset of end 69 user requirements that are satisfied in IPP/1.1. Operator and 70 administrator requirements are out of scope for version 1.1. 72 The document, "Rationale for the Structure and Model and Protocol for 73 the Internet Printing Protocol", describes IPP from a high level 74 view, defines a roadmap for the various documents that form the suite 75 of IPP specifications, and gives background and rationale for the 76 IETF working group's major decisions. 78 The document, "Internet Printing Protocol/1.1: Model and Semantics", 79 describes a simplified model with abstract objects, their attributes, 80 and their operations. The model introduces a Printer and a Job. The 81 Job supports multiple documents per Job. The model document also 82 addresses how security, internationalization, and directory issues 83 are addressed. 85 The document, "Internet Printing Protocol/1.1: Encoding and 86 Transport", is a formal mapping of the abstract operations and 87 attributes defined in the model document onto HTTP/1.1. It also 88 defines the encoding rules for a new Internet media type called 89 "application/ipp". 91 The document, "Mapping between LPD and IPP Protocols", gives some 92 advice to implementers of gateways between IPP and LPD (Line Printer 93 Daemon) implementations. 95 TABLE OF CONTENTS 97 1 Introduction....................................................7 98 1.1 Conformance language.........................................7 99 1.2 Other terminology............................................8 100 1.3 Issues Raised from Interoperability Testing Events...........8 102 2 IPP Objects.....................................................8 104 3 IPP Operations.................................................10 105 3.1 Common Semantics............................................10 106 3.1.1 Summary of Operation Attributes............................10 107 3.1.2 Suggested Operation Processing Steps for IPP Objects.......16 108 3.1.2.1 Suggested Operation Processing Steps for all Operations ..17 109 3.1.2.1.1 Validate version number...............................18 110 3.1.2.1.2 Validate operation identifier.........................19 111 3.1.2.1.3 Validate the request identifier.......................19 112 3.1.2.1.4 Validate attribute group and attribute presence and order 113 19 114 3.1.2.1.4.1 Validate the presence and order of attribute groups .19 115 3.1.2.1.4.2 Ignore unknown attribute groups in the expected 116 position 20 117 3.1.2.1.4.3 Validate the presence of a single occurrence of 118 required Operation attributes.....................................21 119 3.1.2.1.5 Validate the values of the REQUIRED Operation attributes 120 28 121 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes 122 32 123 3.1.2.2 Suggested Additional Processing Steps for Operations that 124 Create/Validate Jobs and Add Documents............................35 125 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied......35 126 3.1.2.2.2 Check that the Printer object is accepting jobs.......36 127 3.1.2.2.3 Validate the values of the Job Template attributes....36 128 3.1.2.3 Algorithm for job validation .............................37 129 3.1.2.3.1 Check for conflicting Job Template attributes values..43 130 3.1.2.3.2 Decide whether to REJECT the request..................43 131 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success 132 status codes......................................................45 133 3.1.2.3.4 Create the Job object with attributes to support......45 134 3.1.2.3.5 Return one of the success status codes................47 135 3.1.2.3.6 Accept appended Document Content......................48 136 3.1.2.3.7 Scheduling and Starting to Process the Job............48 137 3.1.2.3.8 Completing the Job....................................48 138 3.1.2.3.9 Destroying the Job after completion...................48 139 3.1.2.3.10 Interaction with "ipp-attribute-fidelity".............49 140 3.1.2.3.11 Character set code conversion support.................49 141 3.1.2.3.12 What charset to return when an unsupported charset is 142 requested (Issue 1.19)?...........................................50 143 3.1.2.3.13 Natural Language Override (NLO).......................51 144 3.1.3 Status codes returned by operation.........................53 145 3.1.3.1 Printer Operations .......................................53 146 3.1.3.1.1 Print-Job.............................................53 147 3.1.3.1.2 Print-URI.............................................55 148 3.1.3.1.3 Validate-Job..........................................56 149 3.1.3.1.4 Create-Job............................................56 150 3.1.3.1.5 Get-Printer-Attributes................................56 151 3.1.3.1.6 Get-Jobs..............................................57 152 3.1.3.1.7 Pause-Printer.........................................58 153 3.1.3.1.8 Resume-Printer........................................59 154 3.1.3.1.8.1 What about Printers unable to change state due to an 155 error condition?..................................................59 156 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? ...59 157 3.1.3.1.9 Purge-Printer.........................................60 158 3.1.3.2 Job Operations ...........................................60 159 3.1.3.2.1 Send-Document.........................................60 160 3.1.3.2.2 Send-URI..............................................61 161 3.1.3.2.3 Cancel-Job............................................62 162 3.1.3.2.4 Get-Job-Attributes....................................62 163 3.1.3.2.5 Hold-Job..............................................63 164 3.1.3.2.6 Release-Job...........................................64 165 3.1.3.2.7 Restart-Job...........................................64 166 3.1.3.2.7.1 Can documents be added to a restarted job? ..........65 167 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue 168 1.18) 65 169 3.1.5 Sending empty attribute groups.............................65 170 3.2 Printer Operations..........................................66 171 3.2.1 Print-Job operation........................................66 172 3.2.1.1 Flow controlling the data portion of a Print-Job request 173 (Issue 1.22)......................................................66 174 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) ...66 175 3.2.2 Get-Printer-Attributes operation...........................67 176 3.2.3 Get-Jobs operation.........................................67 177 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 178 1.39)? 67 179 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation? 180 68 181 3.2.4 Create-Job operation.......................................68 182 3.3 Job Operations..............................................69 183 3.3.1 Validate-Job...............................................69 184 3.3.2 Restart-Job................................................69 186 4 Object Attributes..............................................70 187 4.1 Attribute Syntax's..........................................70 188 4.1.1 The 'none' value for empty sets (Issue 1.37)...............70 189 4.1.2 Multi-valued attributes (Issue 1.31).......................70 190 4.1.3 Case Sensitivity in URIs (issue 1.6).......................70 191 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage..71 192 4.2 Job Template Attributes.....................................72 193 4.2.1 multiple-document-handling(type2 keyword)..................72 194 4.2.1.1 Support of multiple document jobs ........................72 195 4.3 Job Description Attributes..................................72 196 4.3.1 Getting the date and time of day...........................72 197 4.4 Printer Description Attributes..............................73 198 4.4.1 queued-job-count (integer(0:MAX))..........................73 199 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? ......73 200 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer 201 is (Issue 1.15)?..................................................73 202 4.4.2 printer-current-time (dateTime)............................73 203 4.4.3 Printer-uri................................................74 204 4.5 Empty Jobs..................................................74 206 5 Directory Considerations.......................................75 207 5.1 General Directory Schema Considerations.....................75 208 5.2 IPP Printer with a DNS name.................................75 210 6 Security Considerations........................................75 211 6.1 Querying jobs with IPP that were submitted using other job 212 submission protocols (Issue 1.32).................................75 214 7 Encoding and Transport.........................................76 215 7.1 General Headers.............................................78 216 7.2 Request Headers............................................79 217 7.3 Response Headers............................................81 218 7.4 Entity Headers.............................................81 219 7.5 Optional support for HTTP/1.0...............................82 220 7.6 HTTP/1.1 Chunking...........................................83 221 7.6.1 Disabling IPP Server Response Chunking.....................83 222 7.6.2 Warning About the Support of Chunked Requests..............83 224 8 References.....................................................84 226 9 Authors' Address...............................................85 228 10 Full Copyright Statement.......................................86 230 TABLES 232 Table 1 - Summary of Printer operation attributes that sender MUST 233 supply ........................................................11 234 Table 2 - Summary of Printer operation attributes that sender MAY 235 supply ........................................................12 236 Table 3 - Summary of Job operation attributes that sender MUST supply 237 ..............................................................13 238 Table 4 - Summary of Job operation attributes that sender MAY supply 239 ..............................................................14 240 Table 5 - Printer operation response attributes...................15 241 Table 6 - Examples of validating IPP version......................18 242 Table 7 - Rules for validating single values X against Z..........38 244 1 Introduction 246 The IPP Implementer's Guide (IIG) (this document) contains 247 information that supplements the IPP Model and Semantics [RFC2911] 248 and the IPP Transport and Encoding [RFC2910] documents. As such this 249 information is not part of the formal specifications. Instead 250 information is presented to help implementers understand the 251 specification, including some of the motivation for decisions taken 252 by the committee in developing the specification. Some of the 253 implementation considerations are intended to help implementers 254 design their client and/or IPP object implementations. If there are 255 any contradictions between this document and [RFC2911] or [RFC2910], 256 those documents take precedence over this document. 258 Platform-specific implementation considerations will be included in 259 this guide as they become known. 261 In order to help the reader of the IIG and the IPP Model and 262 Semantics document, the sections in this document parallel the 263 corresponding sections in the Model document and are numbered the 264 same for ease of cross reference. The sections that correspond to 265 the IPP Transport and Encoding are correspondingly offset. 267 1.1 Conformance language 269 Usually, this document does not contain the terminology MUST, MUST 270 NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. 271 However, when those terms do appear in this document, their intent is 272 to repeat what the [RFC2911] and [RFC2910] documents require and 273 allow, rather than specifying additional conformance requirements. 274 These terms are defined in section 12 on conformance terminology in 275 [RFC2911], most of which is taken from RFC 2119 [RFC2119]. 277 Implementers should read section 12 (APPENDIX A) in [RFC2911] in 278 order to understand these capitalized words. The words MUST, MUST 279 NOT, and REQUIRED indicate what implementations are required to 280 support in a client or IPP object in order to be conformant to 281 [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is 282 merely allowed as an implementer option. The verbs SHOULD and SHOULD 283 NOT indicate suggested behavior, but which is not required or 284 disallowed, respectively, in order to conform to the specification. 286 1.2 Other terminology 288 This document uses other terms, such as "attributes", "operation", 289 and "Printer" as defined in [RFC2911] section 12. In addition, the 290 term "sender" refers to the client that sends a request or an IPP 291 object that returns a response. The term "receiver" refers to the 292 IPP object that receives a request and to a client that receives a 293 response. 295 1.3 Issues Raised from Interoperability Testing Events 297 The IPP WG has conducted three open Interoperability Testing Events. 298 The first one was held in September 1998, the second one was held in 299 March 1999, and the third one was held in October 2000. See the 300 summary reports in: 302 ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/ 304 The issues raised from the first Interoperability Testing Event are 305 numbered 1.n in this document and have been incorporated into 306 "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and 307 Transport" [RFC2565] documents. However, some of the discussion is 308 left here in the Implementer's Guide to help understanding. 310 The issues raised from the second Interoperability Testing Event are 311 numbered 2.n in this document have been incorporated into "IPP/1.1 312 Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and 313 Transport" [RFC2910] documents. However, some of the discussion is 314 left here in the Implementer's Guide to help understanding. 316 The issues raised from the third Interoperability Testing Event are 317 numbered 3.n in this document and are described in: 319 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.pdf 320 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.doc 321 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt 323 2 IPP Objects 325 The term "client" in IPP is intended to mean any client that issues 326 IPP operation requests and accepts IPP operation responses, whether 327 it be a desktop or a server. In other words, the term "client" does 328 not just mean end-user clients, such as those associated with 329 desktops. 331 The term "IPP Printer" in IPP is intended to mean an object that 332 accepts IPP operation requests and returns IPP operation responses, 333 whether implemented in a server or a device. An IPP Printer object 334 MAY, if implemented in a server, turn around and forward received 335 jobs (and other requests) to other devices and print 336 servers/services, either using IPP or some other protocol. 338 3 IPP Operations 340 This section corresponds to Section 3 "IPP Operations" in the 341 IPP/1.1 Model and Semantics document [RFC2911]. 343 3.1 Common Semantics 345 This section discusses semantics common to all operations. 347 3.1.1 Summary of Operation Attributes 349 Legend for the following table: 351 R indicates a REQUIRED operation that MUST be supported by the IPP 352 object (Printer or Job). For attributes, R indicates that the 353 attribute MUST be supported by the IPP object supports the 354 associated operation. 356 O indicates an OPTIONAL operation or attribute that MAY be 357 supported by the IPP object (Printer or Job). 359 + indicates that this is not an IPP/1.0 feature, but is only a part 360 of IPP/1.1 and future versions of IPP. 362 Table 1 - Summary of Printer operation attributes that sender MUST 363 supply 365 Printer Operations 366 Requests Response 367 s 369 Operation Print- Pri Crea Get- Get Pause- All 370 Attributes Job, te- Printer- - Printer Operatio 371 Validate URI Job Attribut Job , ns 372 -Job (R) (O) (O) es (R) s Resume- 373 (R) Printer 374 , 375 Purge- 376 nt- Printer 377 (O+) 379 Operation parameters--REQUIRED to be supplied by the sender: 380 operation-id R R R R R R 381 status-code R 382 request-id R R R R R R R 383 version- R R R R R R R 384 number 385 Operation attributes--REQUIRED to be supplied by the sender: 386 attributes- R R R R R R R 387 charset 388 attributes- R R R R R R R 389 natural- 390 language 391 document-uri R 392 job-id* 393 job-uri* 394 last- 395 document 396 printer-uri R R R R R R 397 Operation attributes--RECOMMENDED to be supplied by the sender: 398 job-name R R R 399 requesting- R R R R R R 400 user-name 401 Table 2 - Summary of Printer operation attributes that sender MAY 402 supply 404 Printer Operations 405 Requests Respo 406 nses 408 Operation Print- Prin Crea Get- Get Pause- All 409 Attributes Job, t- te- Printer - Printer Opera 410 Valida URI Job - Job , tions 411 te-Job (O) (O) Attribu s Resume- 412 (R) tes (R) (R) Printer 413 , 414 Purge- 415 Printer 416 (O+) 418 Operation attributes--OPTIONAL to be supplied by the sender: 419 status-message O 420 detailed-status- O 421 message 422 document-access- O** 423 error 424 compression O O 425 document-format R R R 426 document-name O O 427 document-natural- O O 428 language 429 ipp-attribute- R R R 430 fidelity 431 job-impressions O O O 432 job-k-octets O O O 433 job-media-sheets O O O 434 limit R 435 message 436 my-jobs R 437 requested- R R 438 attributes 439 which-jobs R 440 * "job-id" is REQUIRED only if used together with "printer-uri" 441 to identify the target job; otherwise, "job-uri" is REQUIRED. 442 ** "document-access-error" applies to the Print-URI response 443 only. 445 Table 3 - Summary of Job operation attributes that sender MUST supply 447 Job Operations 448 Requests Respons 449 es 451 Operation Send- Send Cance Get- All 452 Attributes Docume -URI l-Job Job- Job, Operatio 453 nt (O) (R) Attrib Release ns 454 (O) utes -Job, 455 (R) Restart 456 -Job 457 (O+) 459 Operation parameters--REQUIRED to be supplied by the sender: 460 operation-id R R R R R 461 status-code R 462 request-id R R R R R R 463 version-number R R R R R R 464 Operation attributes--REQUIRED to be supplied by the sender: 465 attributes-charset R R R R R R 466 attributes-natural- R R R R R R 467 language 468 document-uri R 469 job-id* R R R R R 470 job-uri* R R R R R 471 last-document R R 472 printer-uri R R R R R 473 Operation attributes--RECOMMENDED to be supplied by the sender: 474 job-name 475 requesting-user- R R R R R 476 name 477 Table 4 - Summary of Job operation attributes that sender MAY supply 479 Job Operations 480 Requests Respo 481 nses 483 Operation Send- Sen Cance Hold- Relea All 484 Attributes Documen d- l-Job Get- Job, se- Opera 485 t URI (R) Attrib Restar Job tions 486 (O) (O) utes t-Job (O+) 487 (R) (O+) 489 Operation attributes--OPTIONAL to be supplied by the sender: 490 status-message O 491 detailed-status- O 492 message 493 document-access- O** 494 error 495 compression O O 496 document-format R R 497 document-name O O 498 document-natural- O O 499 language 500 ipp-attribute- 501 fidelity 502 job-impressions 503 job-k-octets 504 job-media-sheets 505 limit 506 message O O O 507 job-hold-until R 508 my-jobs 509 requested- R 510 attributes 511 which-jobs 512 * "job-id" is REQUIRED only if used together with "printer-uri" to 513 identify the target job; otherwise, "job-uri" is REQUIRED. 514 ** "document-access-error" applies to the Send-URI operation only. 516 Table 5 - Printer operation response attributes 518 Printer Operations 519 Response 521 Operation Print- Validat Prin Create Get- Get- Pause- 522 Attributes Job e-Job t- -Job Printe Jobs Printer 523 (R),Send (R) URI (O) r- (R) , 524 - (O), Attrib Resume- 525 Document Send utes Printer 526 (O) -URI (R) , 527 (O) Purge- 528 Printer 529 (O+) 531 job-uri R R R 532 job-id R R R 533 job-state R R R 534 job-state- R+ R+ R+ 535 reasons 536 number-of- O O O 537 intervening- 538 jobs 539 document- O 540 access-error+ 542 3.1.2 Suggested Operation Processing Steps for IPP Objects 544 This section suggests the steps and error checks that an IPP object 545 MAY perform when processing requests and returning responses. An IPP 546 object MAY perform some or all of the error checks. However, some 547 implementations MAY choose to be more forgiving than the error checks 548 shown here, in order to be able to accept requests from non- 549 conforming clients. Not performing all of these error checks is a 550 so-called "forgiving" implementation. On the other hand, clients 551 that successfully submit requests to IPP objects that do perform all 552 the error checks will be more likely to be able to interoperate with 553 other IPP object implementations. Thus an implementer of an IPP 554 object needs to decide whether to be a "forgiving" or a "strict" 555 implementation. Therefore, the error status codes returned may 556 differ between implementations. Consequentially, client SHOULD NOT 557 expect exactly the error code processing described in this section. 559 When an IPP object receives a request, the IPP object either accepts 560 or rejects the request. In order to determine whether or not to 561 accept or reject the request, the IPP object SHOULD execute the 562 following steps. The order of the steps may be rearranged and/or 563 combined, including making one or multiple passes over the request. 565 A client MUST supply requests that would pass all of the error checks 566 indicated here in order to be a conforming client. Therefore, a 567 client SHOULD supply requests that are conforming, in order to avoid 568 being rejected by some IPP object implementations and/or risking 569 different semantics by different implementations of forgiving 570 implementations. For example, a forgiving implementation that 571 accepts multiple occurrences of the same attribute, rather than 572 rejecting the request might use the first occurrences, while another 573 might use the last occurrence. Thus such a non-conforming client 574 would get different results from the two forgiving implementations. 576 In the following, processing continues step by step until a "RETURNS 577 the xxx status code ..." statement is encountered. Error returns are 578 indicated by the verb: "REJECTS". Since clients have difficulty 579 getting the status code before sending all of the document data in a 580 Print-Job request, clients SHOULD use the Validate-Job operation 581 before sending large documents to be printed, in order to validate 582 whether the IPP Printer will accept the job or not. 584 It is assumed that security authentication and authorization has 585 already taken place at a lower layer. 587 3.1.2.1 Suggested Operation Processing Steps for all Operations 589 This section is intended to apply to all operations. The next 590 section contains the additional steps for the Print-Job, Validate- 591 Job, Print-URI, Create-Job, Send-Document, and Send-URI operations 592 that create jobs, adds documents, and validates jobs. 594 IIG Sect # Flow IPP error status codes 595 ---------- ---- ---------------------- 596 | 597 v err 598 3.1.2.1.1 --> server-error-version-not- 599 supported 600 ok| 601 v err 602 3.1.2.1.2 --> server-error-operation-not- 603 supported 604 ok| 605 v err 606 3.1.2.1.4.1- --> client-error-bad-request 607 3.1.2.1.4.2 608 ok| 609 v err 610 3.1.2.1.4.3 --> client-error-bad-request 611 612 ok| 613 v err 614 3.1.2.1.5 --> client-error-bad-request 615 client-error-request-value- 616 too-long 617 <(length, tag, range,> 618 619 ok| 620 v err 621 3.1.2.1.5 --> client-error-bad-request 622 client-error-charset-not- 623 supported 624 ok| client-error-attributes-or- 625 values- 626 | not-supported 627 v err 628 3.1.2.1.6 --> client-error-bad-request 629 client-error-natural-language- 630 not-supported 631 | client-error-request-value- 632 too-long 633 | client-error-attributes-or- 634 values-not-supported 636 3.1.2.1.1 Validate version number 638 Every request and every response contains the "version-number" 639 attribute. The value of this attribute is the major and minor 640 version number of the syntax and semantics that the client and IPP 641 object is using, respectively. The "version-number" attribute 642 remains in a fixed position across all future versions so that all 643 clients and IPP object that support future versions can determine 644 which version is being used. The IPP object checks to see if the 645 major version number supplied in the request is supported. If not, 646 the Printer object REJECTS the request and RETURNS the 'server-error- 647 version-not-supported' status code in the response. The IPP object 648 returns in the "version-number" response attribute the major and 649 minor version for the error response. Thus the client can learn at 650 least one major and minor version that the IPP object supports. The 651 IPP object is encouraged to return the closest version number to the 652 one supplied by the client. 654 The checking of the minor version number is implementation dependent, 655 however if the client supplied minor version is explicitly supported, 656 the IPP object MUST respond using that identical minor version 657 number. If the major version number matches, but the minor version 658 number does not, the Printer SHOULD accept and attempt to process 659 the request, or MAY reject the request and return the 'server-error- 660 version-not-supported' status code. In all cases, the Printer MUST 661 return the nearest version number that it supports. For example, 662 suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'. 663 The following responses are conforming: 665 Table 6 - Examples of validating IPP version 667 Client supplies Printer Accept Request? Printer returns 669 1.0 yes (SHOULD) 1.1 671 1.0 no (SHOULD NOT) 1.1 673 1.1 yes (MUST) 1.1 675 1.2 yes (MUST) 1.2 677 1.3 yes (SHOULD) 1.2 679 1.3 no (SHOULD NOT) 1.2 681 It is advantageous for Printers to support both IPP/1.1 and IPP/1.0, 682 so that they can interoperate with either client implementations. 683 Some implementations may allow an Administrator to explicitly disable 684 support for one or the other by setting the "ipp-versions-supported" 685 Printer description attribute. 687 Likewise, it is advantageous for clients to support both versions to 688 allow interoperability with new and legacy Printers. 690 3.1.2.1.2 Validate operation identifier 692 The Printer object checks to see if the "operation-id" attribute 693 supplied by the client is supported as indicated in the Printer 694 object's "operations-supported" attribute. If not, the Printer 695 REJECTS the request and returns the 'server-error-operation-not- 696 supported' status code in the response. 698 3.1.2.1.3 Validate the request identifier 700 The Printer object SHOULD NOT check to see if the "request-id" 701 attribute supplied by the client is in range: between 1 and 2**31 - 1 702 (inclusive), but copies all 32 bits. 704 Note: The "version-number", "operation-id", and the "request-id" 705 parameters are in fixed octet positions in the IPP/1.1 encoding. The 706 "version-number" parameter will be the same fixed octet position in 707 all versions of the protocol. These fields are validated before 708 proceeding with the rest of the validation. 710 3.1.2.1.4 Validate attribute group and attribute presence and order 712 The order of the following validation steps depends on 713 implementation. 715 3.1.2.1.4.1 Validate the presence and order of attribute groups 716 Client requests and IPP object responses contain attribute groups 717 that Section 3 requires to be present and in a specified order. An 718 IPP object verifies that the attribute groups are present and in the 719 correct order in requests supplied by clients (attribute groups 720 without an * in the following tables). 722 If an IPP object receives a request with (1) required attribute 723 groups missing, or (2) the attributes groups are out of order, or (3) 724 the groups are repeated, the IPP object REJECTS the request and 725 RETURNS the 'client-error-bad-request' status code. For example, it 726 is an error for the Job Template Attributes group to occur before the 727 Operation Attributes group, for the Operation Attributes group to be 728 omitted, or for an attribute group to occur more than once, except in 729 the Get-Jobs response. 731 Since this kind of attribute group error is most likely to be an 732 error detected by a client developer rather than by a customer, the 733 IPP object NEED NOT return an indication of which attribute group was 734 in error in either the Unsupported Attributes group or the Status 735 Message. Also, the IPP object NEED NOT find all attribute group 736 errors before returning this error. 738 3.1.2.1.4.2 Ignore unknown attribute groups in the expected position 739 Future attribute groups may be added to the specification at the end 740 of requests just before the Document Content and at the end of 741 response, except for the Get-Jobs response, where it maybe there or 742 before the first job attributes returned. If an IPP object receives 743 an unknown attribute group in these positions, it ignores the entire 744 group, rather than returning an error, since that group may be a new 745 group in a later minor version of the protocol that can be ignored. 746 (If the new attribute group cannot be ignored without confusing the 747 client, the major version number would have been increased in the 748 protocol document and in the request). If the unknown group occurs 749 in a different position, the IPP object REJECTS the request and 750 RETURNS the 'client-error-bad-request' status code. 752 Clients also ignore unknown attribute groups returned in a response. 754 Note: By validating that requests are in the proper form, IPP 755 objects force clients to use the proper form which, in turn, 756 increases the chances that customers will be able to use such clients 757 from multiple vendors with IPP objects from other vendors. 759 3.1.2.1.4.3 Validate the presence of a single occurrence of required 760 Operation attributes 761 Client requests and IPP object responses contain Operation attributes 762 that [RFC2911] Section 3 requires to be present. Attributes within a 763 group may be in any order, except for the ordering of target, 764 charset, and natural languages attributes. These attributes MUST be 765 first, and MUST be supplied in the following order: charset, natural 766 language, and then target. An IPP object verifies that the attributes 767 that Section 4 requires to be supplied by the client have been 768 supplied in the request (attributes without an * in the following 769 tables). An asterisk (*) indicates groups and Operation attributes 770 that the client may omit in a request or an IPP object may omit in a 771 response. 773 If an IPP object receives a request with required attributes missing 774 or repeated from a group or in the wrong position, the behavior of 775 the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible 776 implementations are: 778 REJECTS the request and RETURNS the 'client-error-bad-request' 779 status code 781 accepts the request and uses the first occurrence of the 782 attribute no matter where it is 784 accepts the request and uses the last occurrence of the 785 attribute no matter where it is 787 accept the request and assume some default value for the 788 missing attribute 790 Therefore, client MUST send conforming requests, if they want to 791 receive the same behavior from all IPP object implementations. For 792 example, it is an error for the "attributes-charset" or "attributes- 793 natural-language" attribute to be omitted in any operation request, 794 or for an Operation attribute to be supplied in a Job Template group 795 or a Job Template attribute to be supplied in an Operation Attribute 796 group in a create request. It is also an error to supply the 797 "attributes-charset" attribute twice. 799 Since these kinds of attribute errors are most likely to be detected 800 by a client developer rather than by a customer, the IPP object NEED 801 NOT return an indication of which attribute was in error in either 802 the Unsupported Attributes group or the Status Message. Also, the 803 IPP object NEED NOT find all attribute errors before returning this 804 error. 806 The following tables list all the attributes for all the operations 807 by attribute group in each request and each response. The order of 808 the groups is the order that the client supplies the groups as 809 specified in [RFC2911] Section 3. The order of the attributes within 810 a group is arbitrary, except as noted for some of the special 811 operation attributes (charset, natural language, and target). The 812 tables below use the following notation: 814 R indicates a REQUIRED attribute or operation that an IPP object 815 MUST support 816 O indicates an OPTIONAL attribute or operation that an IPP 817 object NEED NOT support 818 * indicates that a client MAY omit the attribute in a request 819 and that an IPP object MAY omit the attribute in a 820 response. The absence of an * means that a client MUST 821 supply the attribute in a request and an IPP object 822 MUST supply the attribute in a response. 823 + indicates that this is not a IPP/1.0 operation, but is only a 824 part of IPP/1.1 and future versions of IPP. 826 Operation Requests 828 The tables below show the attributes in their proper attribute groups 829 for operation requests: 831 Note: All operation requests contain "version-number", "operation- 832 id", and "request-id" parameters. 834 Print-Job Request (R): 835 Group 1: Operation Attributes (R) 836 attributes-charset (R) 837 attributes-natural-language (R) 838 printer-uri (R) 839 requesting-user-name (R*) 840 job-name (R*) 841 ipp-attribute-fidelity (R*) 842 document-name (R*) 843 document-format (R*) 844 document-natural-language (O*) 845 compression (O*) 846 job-k-octets (O*) 847 job-impressions (O*) 848 job-media-sheets (O*) 849 Group 2: Job Template Attributes (R*) 850 (O*) 851 (see [RFC2911] Section 4.2) 852 Group 3: Document Content (R) 853 855 Validate-Job Request (R): 856 Group 1: Operation Attributes (R) 857 attributes-charset (R) 858 attributes-natural-language (R) 859 printer-uri (R) 860 requesting-user-name (R*) 861 job-name (R*) 862 ipp-attribute-fidelity (R*) 863 document-name (R*) 864 document-format (R*) 865 document-natural-language (O*) 866 compression (O*) 867 job-k-octets (O*) 868 job-impressions (O*) 869 job-media-sheets (O*) 870 Group 2: Job Template Attributes (R*) 871 (O*) 872 (see [RFC2911] Section 4.2) 874 Print-URI Request (O): 875 Group 1: Operation Attributes (R) 876 attributes-charset (R) 877 attributes-natural-language (R) 878 printer-uri (R) 879 document-uri (R) 880 requesting-user-name (R*) 881 job-name (R*) 882 ipp-attribute-fidelity (R*) 883 document-name (R*) 884 document-format (R*) 885 document-natural-language (O*) 886 compression (O*) 887 job-k-octets (O*) 888 job-impressions (O*) 889 job-media-sheets (O*) 890 Group 2: Job Template Attributes (R*) 891 (O*) (see 892 (see [RFC2911] Section 4.2) 894 Create-Job Request (O): 895 Group 1: Operation Attributes (R) 896 attributes-charset (R) 897 attributes-natural-language (R) 898 printer-uri (R) 899 requesting-user-name (R*) 900 job-name (R*) 901 ipp-attribute-fidelity (R*) 902 job-k-octets (O*) 903 job-impressions (O*) 904 job-media-sheets (O*) 905 Group 2: Job Template Attributes (R*) 906 (O*) (see 907 (see [RFC2911] Section 4.2) 909 Get-Printer-Attributes Request (R): 910 Group 1: Operation Attributes (R) 911 attributes-charset (R) 912 attributes-natural-language (R) 913 printer-uri (R) 914 requesting-user-name (R*) 915 requested-attributes (R*) 916 document-format (R*) 918 Get-Jobs Request (R): 919 Group 1: Operation Attributes (R) 920 attributes-charset (R) 921 attributes-natural-language (R) 922 printer-uri (R) 923 requesting-user-name (R*) 924 limit (R*) 925 requested-attributes (R*) 926 which-jobs (R*) 927 my-jobs (R*) 929 Send-Document Request (O): 930 Group 1: Operation Attributes (R) 931 attributes-charset (R) 932 attributes-natural-language (R) 933 (printer-uri & job-id) | job-uri (R) 934 last-document (R) 935 requesting-user-name (R*) 936 document-name (R*) 937 document-format (R*) 938 document-natural-language (O*) 939 compression (O*) 940 Group 2: Document Content (R*) 941 943 Send-URI Request (O): 944 Group 1: Operation Attributes (R) 945 attributes-charset (R) 946 attributes-natural-language (R) 947 (printer-uri & job-id) | job-uri (R) 948 last-document (R) 949 document-uri (R) 950 requesting-user-name (R*) 951 document-name (R*) 952 document-format (R*) 953 document-natural-language (O*) 954 compression (O*) 956 Cancel-Job Request (R): 957 Release-Job Request (O+): 958 Group 1: Operation Attributes (R) 959 attributes-charset (R) 960 attributes-natural-language (R) 961 (printer-uri & job-id) | job-uri (R) 962 requesting-user-name (R*) 963 message (O*) 965 Get-Job-Attributes Request (R): 966 Group 1: Operation Attributes (R) 967 attributes-charset (R) 968 attributes-natural-language (R) 969 (printer-uri & job-id) | job-uri (R) 970 requesting-user-name (R*) 971 requested-attributes (R*) 973 Pause-Printer Request (O+): 974 Resume-Printer Request (O+): 975 Purge-Printer Request (O+): 976 Group 1: Operation Attributes (R) 977 attributes-charset (R) 978 attributes-natural-language (R) 979 printer-uri (R) 980 requesting-user-name (R*) 982 Hold-Job Request (O+): 983 Restart-Job Request (O+): 984 Group 1: Operation Attributes (R) 985 attributes-charset (R) 986 attributes-natural-language (R) 987 (printer-uri & job-id) | job-uri (R) 988 requesting-user-name (R*) 989 job-hold-until (R*) 990 message (O*) 992 Operation Responses 994 The tables below show the response attributes in their proper 995 attribute groups for responses. 997 Note: All operation responses contain "version-number", "status- 998 code", and "request-id" parameters. 1000 Print-Job Response (R): 1001 Create-Job Response (O): 1002 Send-Document Response (O): 1004 Group 1: Operation Attributes (R) 1005 attributes-charset (R) 1006 attributes-natural-language (R) 1007 status-message (O*) 1008 detailed-status-message (O*) 1009 Group 2: Unsupported Attributes (R*) (see Note 3) 1010 (R*) 1011 Group 3: Job Object Attributes(R*) (see Note 2) 1012 job-uri (R) 1013 job-id (R) 1014 job-state (R) 1015 job-state-reasons (O* | R+) 1016 job-state-message (O*) 1017 number-of-intervening-jobs (O*) 1019 Validate-Job Response (R): 1020 Cancel-Job Response (R): 1021 Hold-Job Response (O+): 1022 Release-Job Response (O+): 1023 Restart-Job Response (O+): 1024 Group 1: Operation Attributes (R) 1025 attributes-charset (R) 1026 attributes-natural-language (R) 1027 status-message (O*) 1028 detailed-status-message (O*) 1029 Group 2: Unsupported Attributes (R*) (see Note 3) 1030 (R*) 1032 Print-URI Response (O): 1033 Send-URI Response (O): 1034 Group 1: Operation Attributes (R) 1035 attributes-charset (R) 1036 attributes-natural-language (R) 1037 status-message (O*) 1038 detailed-status-message (O*) 1039 document-access-error (O*) 1040 Group 2: Unsupported Attributes (R*) (see Note 3) 1041 (R*) 1042 Group 3: Job Object Attributes(R*) (see Note 2) 1043 job-uri (R) 1044 job-id (R) 1045 job-state (R) 1046 job-state-reasons (O* | R+) 1047 job-state-message (O*) 1048 number-of-intervening-jobs (O*) 1050 Get-Printer-Attributes Response (R): 1051 Group 1: Operation Attributes (R) 1052 attributes-charset (R) 1053 attributes-natural-language (R) 1054 status-message (O*) 1055 detailed-status-message (O*) 1056 Group 2: Unsupported Attributes (R*) (see Note 4) 1057 (R*) 1058 Group 3: Printer Object Attributes(R*) (see Note 2) 1059 (R*) 1061 Get-Jobs Response (R): 1062 Group 1: Operation Attributes (R) 1063 attributes-charset (R) 1064 attributes-natural-language (R) 1065 status-message (O*) 1066 detailed-status-message (O*) 1067 Group 2: Unsupported Attributes (R*) (see Note 4) 1068 (R*) 1069 Group 3: Job Object Attributes(R*) (see Note 2, 5) 1070 (R*) 1072 Get-Job-Attributes Response (R): 1073 Group 1: Operation Attributes (R) 1074 attributes-charset (R) 1075 attributes-natural-language (R) 1076 status-message (O*) 1077 detailed-status-message (O*) 1078 Group 2: Unsupported Attributes (R*) (see Note 4) 1079 (R*) 1080 Group 3: Job Object Attributes(R*) (see Note 2) 1081 (R*) 1083 Pause-Printer Response (O+): 1084 Resume-Printer Response (O+): 1085 Purge-Printer Response (O+): 1086 Group 1: Operation Attributes (R) 1087 attributes-charset (R) 1088 attributes-natural-language (R) 1089 status-message (O*) 1090 detailed-status-message (O*) 1091 Group 2: Unsupported Attributes (R*) (see Note 4) 1092 (R*) 1094 Note 2 - the Job Object Attributes and Printer Object Attributes are 1095 returned only if the IPP object returns one of the success status 1096 codes. 1098 Note 3 - the Unsupported Attributes Group is present only if the 1099 client included some Operation and/or Job Template attributes or 1100 values that the Printer doesn't support whether a success or an error 1101 return. 1103 Note 4 - the Unsupported Attributes Group is present only if the 1104 client included some Operation attributes that the Printer doesn't 1105 support whether a success or an error return. 1107 Note 5: for the Get-Jobs operation the response contains a separate 1108 Job Object Attributes group 3 to N containing requested-attributes 1109 for each job object in the response. 1111 3.1.2.1.5 Validate the values of the REQUIRED Operation attributes 1113 An IPP object validates the values supplied by the client of the 1114 REQUIRED Operation attribute that the IPP object MUST support. The 1115 next section specifies the validation of the values of the OPTIONAL 1116 Operation attributes that IPP objects MAY support. 1118 The IPP object performs the following syntactic validation checks of 1119 each Operation attribute value: 1121 a) that the length of each Operation attribute value is 1122 correct for the attribute syntax tag supplied by the client 1123 according to [RFC2911] Section 4.1, 1125 b) that the attribute syntax tag is correct for that Operation 1126 attribute according to [RFC2911] Section 3, 1128 c) that the value is in the range specified for that Operation 1129 attribute according to [RFC2911] Section 3, 1131 d) that multiple values are supplied by the client only for 1132 operation attributes that are multi-valued, i.e., that are 1setOf 1133 X according to [RFC2911] Section 3. 1135 If any of these checks fail, the IPP object REJECTS the request and 1136 RETURNS the 'client-error-bad-request' or the 'client-error-request- 1137 value-too-long' status code. Since such an error is most likely to 1138 be an error detected by a client developer, rather than by an end- 1139 user, the IPP object NEED NOT return an indication of which attribute 1140 had the error in either the Unsupported Attributes Group or the 1141 Status Message. The description for each of these syntactic checks 1142 is explicitly expressed in the first IF statement in the following 1143 table. 1145 In addition, the IPP object checks each Operation attribute value 1146 against some Printer object attribute or some hard-coded value if 1147 there is no "xxx-supported" Printer object attribute defined. If its 1148 value is not among those supported or is not in the range supported, 1149 then the IPP object REJECTS the request and RETURNS the error status 1150 code indicated in the table by the second IF statement. If the value 1151 of the Printer object's "xxx-supported" attribute is 'no-value' 1152 (because the system administrator hasn't configured a value), the 1153 check always fails. 1155 ----------------------------------------------- 1157 attributes-charset (charset) 1159 IF NOT a single non-empty 'charset' value, REJECT/RETURN 1160 'client-error-bad-request'. 1161 IF the value length is greater than 63 octets, REJECT/RETURN 1162 'client-error-request-value-too-long'. 1163 IF NOT in the Printer object's "charset-supported" attribute, 1164 REJECT/RETURN "client-error-charset-not-supported". 1166 attributes-natural-language(naturalLanguage) 1168 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 1169 'client-error-bad-request'. 1170 IF the value length is greater than 63 octets, REJECT/RETURN 1171 'client-error-request-value-too-long'. 1172 ACCEPT the request even if not a member of the set in the 1173 Printer object's "generated-natural-language-supported" 1174 attribute. If the supplied value is not a member of the 1175 Printer object's "generated-natural-language-supported" 1176 attribute, use the Printer object's "natural-language- 1177 configured" value. 1179 requesting-user-name 1181 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- 1182 request'. 1183 IF the value length is greater than 255 octets, REJECT/RETURN 1184 'client-error-request-value-too-long'. 1185 IF the IPP object can obtain a better-authenticated name, use it 1186 instead. 1188 job-name(name) 1190 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- 1191 request'. 1192 IF the value length is greater than 255 octets, REJECT/RETURN 1193 'client-error-request-value-too-long'. 1195 IF NOT supplied by the client, the Printer object creates a name 1196 from the document-name or document-uri. 1198 document-name (name) 1200 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- 1201 request'. 1202 IF the value length is greater than 255 octets, REJECT/RETURN 1203 'client-error-request-value-too-long'. 1205 ipp-attribute-fidelity (boolean) 1207 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, 1208 REJECT/RETURN 'client-error-bad-request'. 1209 IF the value length is NOT equal to 1 octet, REJECT/RETURN 1210 'client-error-request-value-too-long' 1211 IF NOT supplied by the client, the IPP object assumes the value 1212 'false'. 1214 document-format (mimeMediaType) 1216 IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN 1217 'client-error-bad-request'. 1218 IF the value length is greater than 255 octets, REJECT/RETURN 1219 'client-error-request-value-too-long'. 1220 IF NOT in the Printer object's "document-format-supported" 1221 attribute, REJECT/RETURN 'client-error-document-format-not- 1222 supported' 1223 IF NOT supplied by the client, the IPP object assumes the value 1224 of the Printer object's "document-format-default" 1225 attribute. 1227 document-uri (uri) 1229 IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client- 1230 error-bad-request'. 1231 IF the value length is greater than 1023 octets, REJECT/RETURN 1232 'client-error-request-value-too-long'. 1233 IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad- 1234 request'. 1235 If the client-supplied URI scheme is not supported, i.e. the 1236 value is not in the Printer object's referenced-uri-scheme- 1237 supported" attribute, the Printer object MUST reject the 1238 request and return the 'client-error-uri-scheme-not- 1239 supported' status code. The Printer object MAY check to see 1240 if the document exists and is accessible. If the document 1241 is not found or is not accessible, REJECT/RETURN 'client- 1242 error-not found'. 1243 last-document (boolean) 1244 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, 1245 REJECT/RETURN 'client-error-bad-request'. 1246 IF the value length is NOT equal to 1 octet, REJECT/RETURN 1247 'client-error-request-value-too-long' 1249 job-id (integer(1:MAX)) 1251 IF NOT an single 'integer' value equal to 4 octets AND in the 1252 range 1 to MAX, REJECT/RETURN 'client-error-bad-request'. 1253 IF NOT a job-id of an existing Job object, REJECT/RETURN 1254 'client-error-not-found' or 'client-error-gone' status 1255 code, if keep track of recently deleted jobs. 1257 requested-attributes (1setOf keyword) 1259 IF NOT one or more 'keyword' values, REJECT/RETURN 'client- 1260 error-bad-request'. 1261 IF the value length is greater than 255 octets, REJECT/RETURN 1262 'client-error-request-value-too-long'. 1263 Ignore unsupported values, which are the keyword names of 1264 unsupported attributes. Don't bother to copy such 1265 requested (unsupported) attributes to the Unsupported 1266 Attribute response group since the response will not return 1267 them. 1269 which-jobs (type2 keyword) 1271 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error- 1272 bad-request'. 1273 IF the value length is greater than 255 octets, REJECT/RETURN 1274 'client-error-request-value-too-long'. 1275 IF NEITHER 'completed' NOR 'not-completed', copy the attribute 1276 and the unsupported value to the Unsupported Attributes 1277 response group and REJECT/RETURN 'client-error-attributes- 1278 or-values-not-supported'. 1279 Note: a Printer still supports the 'completed' value even if it 1280 keeps no completed/canceled/aborted jobs: by returning no 1281 jobs when so queried. 1282 IF NOT supplied by the client, the IPP object assumes the 'not- 1283 completed' value. 1285 my-jobs (boolean) 1287 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, 1288 REJECT/RETURN 'client-error-bad-request'. 1289 IF the value length is NOT equal to 1 octet, REJECT/RETURN 1290 'client-error-request-value-too-long' 1291 IF NOT supplied by the client, the IPP object assumes the 1292 'false' value. 1294 limit (integer(1:MAX)) 1296 IF NOT a single 'integer' value equal to 4 octets AND in the 1297 range 1 to MAX, REJECT/RETURN 'client-error-bad-request'. 1298 IF NOT supplied by the client, the IPP object returns all jobs, 1299 no matter how many. 1301 ----------------------------------------------- 1303 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes 1305 OPTIONAL Operation attributes are those that an IPP object MAY 1306 support. An IPP object validates the values of the OPTIONAL 1307 attributes supplied by the client. The IPP object performs the same 1308 syntactic validation checks for each OPTIONAL attribute value as in 1309 Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP 1310 object REJECTS the request and RETURNS the 'client-error-bad-request' 1311 or the 'client-error-request-value-too-long' status code. 1313 In addition, the IPP object checks each Operation attribute value 1314 against some Printer attribute or some hard-coded value if there is 1315 no "xxx-supported" Printer attribute defined. If its value is not 1316 among those supported or is not in the range supported, then the IPP 1317 object REJECTS the request and RETURNS the error status code 1318 indicated in the table. If the value of the Printer object's "xxx- 1319 supported" attribute is 'no-value' (because the system administrator 1320 hasn't configured a value), the check always fails. 1322 If the IPP object doesn't recognize/support an attribute, the IPP 1323 object treats the attribute as an unknown or unsupported attribute 1324 (see the last row in the table below). 1326 ----------------------------------------------- 1328 document-natural-language (naturalLanguage) 1330 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 1331 'client-error-bad-request'. 1332 IF the value length is greater than 63 octets, REJECT/RETURN 1333 'client-error-request-value-too-long'. 1334 IF NOT a value that the Printer object supports in document 1335 formats, (no corresponding "xxx-supported" Printer attribute), 1336 REJECT/RETURN 'client-error-natural-language-not-supported'. 1338 compression (type3 keyword) 1340 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- 1341 request'. 1343 IF the value length is greater than 255 octets, REJECT/RETURN 1344 'client-error-request-value-too-long'. 1345 IF NOT in the Printer object's "compression-supported" attribute, 1346 copy the attribute and the unsupported value to the 1347 Unsupported Attributes response group and REJECT/RETURN 1348 'client-error-attributes-or-values-not-supported'. 1349 Note to IPP/1.0 implementers: Support for the "compression" 1350 attribute was optional in IPP/1.0 and was changed to REQUIRED 1351 in IPP/1.1. However, an IPP/1.0 object SHOULD at least check 1352 for the "compression" attribute being present and reject the 1353 create request, if they don't support "compression". Not 1354 checking is a bug, since the data will be unintelligible. 1356 job-k-octets (integer(0:MAX)) 1358 IF NOT a single 'integer' value equal to 4 octets, 1359 REJECT/RETURN 'client-error-bad-request'. 1360 IF NOT in the range of the Printer object's "job-k-octets- 1361 supported" attribute, copy the attribute and the unsupported 1362 value to the Unsupported Attributes response group and 1363 REJECT/RETURN 'client-error-attributes-or-values-not- 1364 supported'. 1366 job-impressions (integer(0:MAX)) 1368 IF NOT a single 'integer' value equal to 4 octets, 1369 REJECT/RETURN 'client-error-bad-request'. 1370 IF NOT in the range of the Printer object's "job-impressions- 1371 supported" attribute, copy the attribute and the unsupported 1372 value to the Unsupported Attributes response group and 1373 REJECT/RETURN 'client-error-attributes-or-values-not- 1374 supported'. 1376 job-media-sheets (integer(0:MAX)) 1378 IF NOT a single 'integer' value equal to 4 octets, 1379 REJECT/RETURN 'client-error-bad-request'. 1380 IF NOT in the range of the Printer object's "job-media-sheets- 1381 supported" attribute, copy the attribute and the unsupported 1382 value to the Unsupported Attributes response group and 1383 REJECT/RETURN 'client-error-attributes-or-values-not- 1384 supported'. 1386 message (text(127)) 1388 IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad- 1389 request'. 1390 IF the value length is greater than 127 octets, 1391 REJECT/RETURN 'client-error-request-value-too-long'. 1393 unknown or unsupported attribute 1395 IF the attribute syntax supplied by the client is supported but the 1396 length is not legal for that attribute syntax, REJECT/RETURN 1397 'client-error-request-value-too-long'. 1398 ELSE copy the attribute and value to the Unsupported Attributes 1399 response group and change the attribute value to the "out-of- 1400 band" 'unsupported' value, but otherwise ignore the attribute. 1402 Note: Future Operation attributes may be added to the protocol 1403 specification that may occur anywhere in the specified group. When 1404 the operation is otherwise successful, the IPP object returns the 1405 'successful-ok-ignored-or-substituted-attributes' status code. 1406 Ignoring unsupported Operation attributes in all operations is 1407 analogous to the handling of unsupported Job Template attributes in 1408 the create and Validate-Job operations when the client supplies the 1409 "ipp-attribute-fidelity" Operation attribute with the 'false' value. 1410 This last rule is so that we can add OPTIONAL Operation attributes to 1411 future versions of IPP so that older clients can inter-work with new 1412 IPP objects and newer clients can inter-work with older IPP objects. 1413 (If the new attribute cannot be ignored without performing 1414 unexpectedly, the major version number would have been increased in 1415 the protocol document and in the request). This rule for Operation 1416 attributes is independent of the value of the "ipp-attribute- 1417 fidelity" attribute. For example, if an IPP object doesn't support 1418 the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-k- 1419 octets" as an unknown attribute and only checks the length for the 1420 'integer' attribute syntax supplied by the client. If it is not four 1421 octets, the IPP object REJECTS the request and RETURNS the 'client- 1422 error-bad-request' status code, else the IPP object copies the 1423 attribute to the Unsupported Attribute response group, setting the 1424 value to the "out-of-band" 'unsupported' value, but otherwise ignores 1425 the attribute. 1427 3.1.2.2 Suggested Additional Processing Steps for Operations that 1428 Create/Validate Jobs and Add Documents 1430 This section in combination with the previous section recommends the 1431 processing steps for the Print-Job, Validate-Job, Print-URI, Create- 1432 Job, Send-Document, and Send-URI operations that IPP objects SHOULD 1433 use. These are the operations that create jobs, validate a Print-Job 1434 request, and add documents to a job. 1436 IIG Sect # Flow IPP error status codes 1437 ---------- ---- ---------------------- 1438 | 1439 v No 1440 3.1.2.2.1 ------------------+ 1441 | 1442 Yes| | 1443 | ipp-attribute-fidelity = no | 1444 |<------------------------------+ 1445 v No 1446 3.1.2.2.2 --> server-error-not-accepting-jobs 1447 1448 Yes| 1449 v err 1450 3.1.2.3 --> client-error-bad-request 1451 client-error-request-value-too- 1452 long 1453 <(length, tag, range,> 1454 1455 ok| 1456 v err 1457 3.1.2.3 --> client-error-bad-request 1458 client-error-attributes-or- 1459 | values-not-supported 1460 v err 1461 3.1.2.3.1 --> client-error-conflicting- 1462 attributes 1463 client-error-attributes-or- 1464 values-not-supported 1465 v 1467 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied 1469 The Printer object checks to see if the client supplied an "ipp- 1470 attribute-fidelity" Operation attribute. If the attribute is not 1471 supplied by the client, the IPP object assumes that the value is 1472 'false'. 1474 3.1.2.2.2 Check that the Printer object is accepting jobs 1476 If the value of the Printer objects "printer-is-accepting-jobs" is 1477 'false', the Printer object REJECTS the request and RETURNS the 1478 'server-error-not-accepting-jobs' status code. 1480 3.1.2.2.3 Validate the values of the Job Template attributes 1482 An IPP object validates the values of all Job Template attribute 1483 supplied by the client. The IPP object performs the analogous 1484 syntactic validation checks of each Job Template attribute value that 1485 it performs for Operation attributes (see Section 3.1.2.1.5.): 1487 a) that the length of each value is correct for the attribute 1488 syntax tag supplied by the client according to [RFC2911] Section 1489 4.1. 1491 b) that the attribute syntax tag is correct for that attribute 1492 according to [RFC2911] Sections 4.2 to 4.4. 1494 c) that multiple values are supplied only for multi-valued 1495 attributes, i.e., that are 1setOf X according to [RFC2911] 1496 Sections 4.2 to 4.4. 1498 As in Section 3.1.2.1.5, if any of these syntactic checks fail, the 1499 IPP object REJECTS the request and RETURNS the 'client-error-bad- 1500 request' or 'client-error-request-value-too-long' status code as 1501 appropriate, independent of the value of the "ipp-attribute- 1502 fidelity". Since such an error is most likely to be an error 1503 detected by a client developer, rather than by an end-user, the IPP 1504 object NEED NOT return an indication of which attribute had the error 1505 in either the Unsupported Attributes Group or the Status Message. 1506 The description for each of these syntactic checks is explicitly 1507 expressed in the first IF statement in the following table. 1509 Each Job Template attribute MUST occur no more than once. If an IPP 1510 Printer receives a create request with multiple occurrences of a Job 1511 Template attribute, it MAY: 1513 1. reject the operation and return the 'client-error-bad-request' 1514 error status code 1516 2. accept the operation and use the first occurrence of the 1517 attribute 1519 3. accept the operation and use the last occurrence of the 1520 attribute 1522 depending on implementation. Therefore, clients MUST NOT supply 1523 multiple occurrences of the same Job Template attribute in the Job 1524 Attributes group in the request. 1526 3.1.2.3 Algorithm for job validation 1528 The process of validating a Job-Template attribute "xxx" against a 1529 Printer attribute "xxx-supported" can use the following validation 1530 algorithm (see section 3.2.1.2 in [RFC2911]). 1532 To validate the value U of Job-Template attribute "xxx" against the 1533 value V of Printer "xxx-supported", perform the following 1534 algorithm: 1536 1.If U is multi-valued, validate each value X of U by performing 1537 the algorithm in Table 7 with each value X. Each validation is 1538 separate from the standpoint of returning unsupported values. 1539 Example: If U is "finishings" that the client supplies with 1540 'staple', 'bind' values, then X takes on the successive values: 1541 'staple', then 'bind' 1543 2.If V is multi-valued, validate X against each Z of V by 1544 performing the algorithm in Table 7 with each value Z. If a 1545 value Z validates, the validation for the attribute value X 1546 succeeds. If it fails, the algorithm is applied to the next 1547 value Z of V. If there are no more values Z of V, validation 1548 fails. Example" If V is "sides-supported" with values: 'one- 1549 sided', 'two-sided-long', and 'two-sided-short', then Z takes on 1550 the successive values: 'one-sided', 'two-sided-long', and 'two- 1551 sided-short'. If the client supplies "sides" with 'two-sided- 1552 long', the first comparison fails ('one-sided' is not equal to 1553 'two-sided-long'), the second comparison succeeds ('two-sided- 1554 long' is equal to 'two-sided-long"), and the third comparison 1555 ('two-sided-short' with 'two-sided-long') is not even performed. 1557 3.If both U and V are single-valued, let X be U and Z be V and use 1558 the validation rules in Table 7. 1560 Table 7 - Rules for validating single values X against Z 1562 Attribute syntax attribute syntax validated if: 1563 of X of Z 1565 integer rangeOfInteger X is within the range of Z 1567 uri uriScheme the uri scheme in X is equal to 1568 Z 1570 any boolean the value of Z is TRUE 1572 any any X and Z are of the same type 1573 and are equal. 1575 If the value of the Printer object's "xxx-supported" attribute is 1576 'no-value' (because the system administrator hasn't configured a 1577 value), the check always fails. If the check fails, the IPP object 1578 copies the attribute to the Unsupported Attributes response group 1579 with its unsupported value. If the attribute contains more than one 1580 value, each value is checked and each unsupported value is separately 1581 copied, while supported values are not copied. If an IPP object 1582 doesn't recognize/support a Job Template attribute, i.e., there is no 1583 corresponding Printer object "xxx-supported" attribute, the IPP 1584 object treats the attribute as an unknown or unsupported attribute 1585 (see the last row in the table below). 1587 If some Job Template attributes are supported for some document 1588 formats and not for others or the values are different for different 1589 document formats, the IPP object SHOULD take that into account in 1590 this validation using the value of the "document-format" supplied by 1591 the client (or defaulted to the value of the Printer's "document- 1592 format-default" attribute, if not supplied by the client). For 1593 example, if "number-up" is supported for the 'text/plain' document 1594 format, but not for the 'application/postscript' document format, the 1595 check SHOULD (though it NEED NOT) depend on the value of the 1596 "document-format" operation attribute. See "document-format" in 1597 [RFC2911] section 3.2.1.1 and 3.2.5.1. 1599 Note: whether the request is accepted or rejected is determined by 1600 the value of the "ipp-attribute-fidelity" attribute in a subsequent 1601 step, so that all Job Template attribute supplied are examined and 1602 all unsupported attributes and/or values are copied to the 1603 Unsupported Attributes response group. 1605 ----------------------------------------------- 1607 job-priority (integer(1:100)) 1609 IF NOT a single 'integer' value with a length equal to 4 octets, 1610 REJECT/RETURN 'client-error-bad-request'. 1611 IF NOT supplied by the client, use the value of the Printer 1612 object's "job-priority-default" attribute at job submission 1613 time. 1614 IF NOT in the range 1 to 100, inclusive, copy the attribute and the 1615 unsupported value to the Unsupported Attributes response 1616 group. 1617 Map the value to the nearest supported value in the range 1:100 as 1618 specified by the number of discrete values indicated by the 1619 value of the Printer's "job-priority-supported" attribute. 1620 See the formula in [RFC2911] Section 4.2.1. 1622 job-hold-until (type3 keyword | name) 1624 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- 1625 error-bad-request'. 1626 IF the value length is greater than 255 octets, REJECT/RETURN 1627 'client-error-request-value-too-long'. 1628 IF NOT supplied by the client, use the value of the Printer 1629 object's "job-hold-until" attribute at job submission time. 1630 IF NOT in the Printer object's "job-hold-until-supported" 1631 attribute, copy the attribute and the unsupported value to the 1632 Unsupported Attributes response group. 1634 job-sheets (type3 keyword | name) 1636 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- 1637 error-bad-request'. 1638 IF the value length is greater than 255 octets, REJECT/RETURN 1639 'client-error-request-value-too-long'. 1640 IF NOT in the Printer object's "job-sheets-supported" attribute, 1641 copy the attribute and the unsupported value to the 1642 Unsupported Attributes response group. 1644 multiple-document-handling (type2 keyword) 1646 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- 1647 request'. 1648 IF the value length is greater than 255 octets, REJECT/RETURN 1649 'client-error-request-value-too-long'. 1650 IF NOT in the Printer object's "multiple-document-handling- 1651 supported" attribute, copy the attribute and the unsupported 1652 value to the Unsupported Attributes response group. 1654 copies (integer(1:MAX)) 1655 IF NOT a single 'integer' value with a length equal to 4 octets, 1656 REJECT/RETURN 'client-error-bad-request'. 1657 IF NOT in range of the Printer object's "copies-supported" 1658 attribute 1659 copy the attribute and the unsupported value to the Unsupported 1660 Attributes response group. 1662 finishings (1setOf type2 enum) 1664 IF NOT an 'enum' value(s) each with a length equal to 4 octets, 1665 REJECT/RETURN 'client-error-bad-request'. 1666 IF NOT in the Printer object's "finishings-supported" attribute, 1667 copy the attribute and the unsupported value(s), but not any 1668 supported values, to the Unsupported Attributes response 1669 group. 1671 page-ranges (1setOf rangeOfInteger(1:MAX)) 1673 IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8 1674 octets, REJECT/RETURN 'client-error-bad-request'. 1675 IF first value is greater than second value in any range, the 1676 ranges are not in ascending order, or ranges overlap, 1677 REJECT/RETURN 'client-error-bad-request'. 1678 IF the value of the Printer object's "page-ranges-supported" 1679 attribute is 'false', copy the attribute to the Unsupported 1680 Attributes response group and set the value to the "out-of- 1681 band" 'unsupported' value. 1683 sides (type2 keyword) 1685 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- 1686 request'. 1687 IF the value length is greater than 255 octets, REJECT/RETURN 1688 'client-error-request-value-too-long'. 1689 IF NOT in the Printer object's "sides-supported" attribute, copy 1690 the attribute and the unsupported value to the Unsupported 1691 Attributes response group. 1693 number-up (integer(1:MAX)) 1695 IF NOT a single 'integer' value with a length equal to 4 octets, 1696 REJECT/RETURN 'client-error-bad-request'. 1697 IF NOT a value or in the range of one of the values of the Printer 1698 object's "number-up-supported" attribute, copy the attribute 1699 and value to the Unsupported Attribute response group. 1701 orientation-requested (type2 enum) 1703 IF NOT a single 'enum' value with a length equal to 4 octets, 1704 REJECT/RETURN 'client-error-bad-request'. 1706 IF NOT in the Printer object's "orientation-requested-supported" 1707 attribute, copy the attribute and the unsupported value to the 1708 Unsupported Attributes response group. 1710 media (type3 keyword | name) 1712 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- 1713 error-bad-request'. 1714 IF the value length is greater than 255 octets, REJECT/RETURN 1715 'client-error-request-value-too-long'. 1716 IF NOT in the Printer object's "media-supported" attribute, copy 1717 the attribute and the unsupported value to the Unsupported 1718 Attributes response group. 1720 printer-resolution (resolution) 1722 IF NOT a single 'resolution' value with a length equal to 9 octets, 1723 REJECT/RETURN 'client-error-bad-request'. 1724 IF NOT in the Printer object's "printer-resolution-supported" 1725 attribute, copy the attribute and the unsupported value to the 1726 Unsupported Attributes response group. 1728 print-quality (type2 enum) 1730 IF NOT a single 'enum' value with a length equal to 4 octets, 1731 REJECT/RETURN 'client-error-bad-request'. 1732 IF NOT in the Printer object's "print-quality-supported" attribute, 1733 copy the attribute and the unsupported value to the 1734 Unsupported Attributes response group. 1736 unknown or unsupported attribute (i.e., there is no corresponding 1737 Printer object "xxx-supported" attribute) 1739 IF the attribute syntax supplied by the client is supported but the 1740 length is not legal for that attribute syntax, 1741 REJECT/RETURN 'client-error-bad-request' if the length of the 1742 attribute syntax is fixed or 'client-error-request-value-too- 1743 long' if the length of the attribute syntax is variable. 1744 ELSE copy the attribute and value to the Unsupported Attributes 1745 response group and change the attribute value to the "out-of- 1746 band" 'unsupported' value. Any remaining Job Template 1747 Attributes are either unknown or unsupported Job Template 1748 attributes and are validated algorithmically according to 1749 their attribute syntax for proper length (see below). 1750 ----------------------------------------------- 1751 If the attribute syntax is supported AND the length check fails, the 1752 IPP object REJECTS the request and RETURNS the 'client-error-bad- 1753 request' if the length of the attribute syntax is fixed or the 1754 'client-error-request-value-too-long' status code if the length of 1755 the attribute syntax is variable. Otherwise, the IPP object copies 1756 the unsupported Job Template attribute to the Unsupported Attributes 1757 response group and changes the attribute value to the "out-of-band" 1758 'unsupported' value. The following table shows the length checks for 1759 all attribute syntaxes. In the following table: "<=" means less 1760 than or equal, "=" means equal to: 1762 Name Octet length check for read-write attributes 1763 ----------- -------------------------------------------- 1764 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63 1765 'textWithoutLanguage' <= 1023 1766 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 1767 'nameWithoutLanguage' <= 255 1768 'keyword' <= 255 1769 'enum' = 4 1770 'uri' <= 1023 1771 'uriScheme' <= 63 1772 'charset' <= 63 1773 'naturalLanguage' <= 63 1774 'mimeMediaType' <= 255 1775 'octetString' <= 1023 1776 'boolean' = 1 1777 'integer' = 4 1778 'rangeOfInteger' = 8 1779 'dateTime' = 11 1780 'resolution' = 9 1781 '1setOf X' 1783 Note: It's possible for a Printer to receive a zero length keyword 1784 in a request. Since this is a keyword, its value needs to be 1785 compared with the supported values. Assuming that the printer 1786 doesn't have any values in its corresponding "xxx-supported" 1787 attribute that are keywords of zero length, the comparison will fail. 1788 Then the request will be accepted or rejected depending on the value 1789 of "ipp-attributes-fidelity" being 'false' or 'true', respectively. 1790 No special handling is required for 1792 3.1.2.3.1 Check for conflicting Job Template attributes values 1794 Once all the Operation and Job Template attributes have been checked 1795 individually, the Printer object SHOULD check for any conflicting 1796 values among all the supported values supplied by the client. For 1797 example, a Printer object might be able to staple and to print on 1798 transparencies, however due to physical stapling constraints, the 1799 Printer object might not be able to staple transparencies. The IPP 1800 object copies the supported attributes and their conflicting 1801 attribute values to the Unsupported Attributes response group. The 1802 Printer object only copies over those attributes that the Printer 1803 object either ignores or substitutes in order to resolve the 1804 conflict, and it returns the original values which were supplied by 1805 the client. For example suppose the client supplies "finishings" 1806 equals 'staple' and "media" equals 'transparency', but the Printer 1807 object does not support stapling transparencies. If the Printer 1808 chooses to ignore the stapling request in order to resolve the 1809 conflict, the Printer objects returns "finishings" equal to 'staple' 1810 in the Unsupported Attributes response group. If any attributes are 1811 multi-valued, only the conflicting values of the attributes are 1812 copied. 1814 Note: The decisions made to resolve the conflict (if there is a 1815 choice) is implementation dependent. 1817 3.1.2.3.2 Decide whether to REJECT the request 1819 If there were any unsupported Job Template attributes or 1820 unsupported/conflicting Job Template attribute values and the client 1821 supplied the "ipp-attribute-fidelity" attribute with the 'true' 1822 value, the Printer object REJECTS the request and return the status 1823 code: 1825 1. 'client-error-conflicting-attributes' status code, if there were 1826 any conflicts between attributes supplied by the client. 1827 2. 'client-error-attributes-or-values-not-supported' status code, 1828 otherwise. 1830 Note: Unsupported Operation attributes or values that are returned 1831 do not affect the status returned in this step. If the unsupported 1832 Operation attribute was a serious error, the above already rejected 1833 the request in a previous step. If control gets to this step with 1834 unsupported Operation attributes being returned, they are not serious 1835 errors. 1837 In general, the final results of Job processing are unknown at Job 1838 submission time. The client has to rely on notifications or polling 1839 to find out what happens at Job processing time. However, there are 1840 cases in which some Printers can determine at Job submission time 1841 that Job processing is going to fail. As an optimization, we'd like 1842 to have the Printer reject the Job in these cases. 1844 There are three types of "processing" errors that might be detectable 1845 at Job submission time: 1847 1. 'client-error-document-format-not-supported' : For the Print- 1848 Job, Send-Document, Print-URI, and Send-URI operations, if all these 1849 conditions are true: 1851 - the Printer supports auto-sensing, 1852 - the request "document-format" operation attribute is 1853 'application/octet-stream', 1854 - the Printer receives document data before responding, 1855 - the Printer auto-senses the document format before responding, 1856 - the sensed document format is not supported by the Printer 1857 then the Printer should respond with 'client-error-document-format- 1858 not-supported' status. 1860 2. 'client-error-compression-error': For the Print-Job, Send- 1861 Document, Print-URI, and Send-URI operations, if all these 1862 conditions are true: 1864 - the client supplies a supported value for the "compression" 1865 operation attribute in the request 1866 - the Printer receives document data before responding, 1867 - the Printer attempts to decompress the document data before 1868 responding, 1869 - the document data cannot be decompressed using the algorithm 1870 specified by the "compression" operation attribute 1871 then the Printer should respond with 'client-error-compression-error' 1872 status. 1874 3. 'client-error-document-access-error': For the Print-URI, and 1875 Send-URI operations, if the Printer attempts and fails to pull the 1876 referenced document data before responding, it should respond with 1877 'client-error-document-access-error' status. 1879 Some Printers are not able to detect these errors until Job 1880 processing time. In that case, the errors are recorded in the 1881 corresponding job-state and job-state reason attributes. (There is 1882 no standard way for a client to determine whether a Printer can 1883 detect these errors at Job submission time.) For example, if auto- 1884 sensing happens AFTER the job is accepted (as opposed to auto-sensing 1885 at submit time before returning the response), the implementation 1886 aborts the job, puts the job in the 'aborted' state and sets the 1887 'unsupported-document-format' value in the job's "job-state-reasons". 1889 A client should always provide a valid "document-format" operation 1890 attribute whenever practical. In the absence of other information, a 1891 client itself may sniff the document data to determine document 1892 format. 1894 Auto sensing at Job submission time may be more difficult for the 1895 Printer when combined with compression. For auto-sensed Jobs, a 1896 client may be better off deferring compression to the transfer 1897 protocol layer, e.g.; by using the HTTP Content-Encoding header. 1899 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success 1900 status codes 1902 If the requested operation is the Validate-Job operation, the Printer 1903 object returns: 1905 1. the "successful-ok" status code, if there are no unsupported or 1906 conflicting Job Template attributes or values. 1907 2. the "successful-ok-conflicting-attributes, if there are any 1908 conflicting Job Template attribute or values. 1909 3. the "successful-ok-ignored-or-substituted-attributes, if there 1910 are only unsupported Job Template attributes or values. 1912 Note: Unsupported Operation attributes or values that are returned 1913 do not affect the status returned in this step. If the unsupported 1914 Operation attribute was a serious error, the above already rejected 1915 the request in a previous step. If control gets to this step with 1916 unsupported Operation attributes being returned, they are not serious 1917 errors. 1919 3.1.2.3.4 Create the Job object with attributes to support 1921 If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied 1922 by the client), the Printer object: 1924 1. creates a Job object, assigns a unique value to the job's "job- 1925 uri" and "job-id" attributes, and initializes all of the job's 1926 other supported Job Description attributes. 1927 2. removes all unsupported attributes from the Job object. 1928 3. for each unsupported value, removes either the unsupported value 1929 or substitutes the unsupported attribute value with some 1930 supported value. If an attribute has no values after removing 1931 unsupported values from it, the attribute is removed from the 1932 Job object (so that the normal default behavior at job 1933 processing time will take place for that attribute). 1934 4. for each conflicting value, removes either the conflicting value 1935 or substitutes the conflicting attribute value with some other 1936 supported value. If an attribute has no values after removing 1937 conflicting values from it, the attribute is removed from the 1938 Job object (so that the normal default behavior at job 1939 processing time will take place for that attribute). 1941 If there were no attributes or values flagged as unsupported, or the 1942 value of 'ipp-attribute-fidelity" was 'false', the Printer object is 1943 able to accept the create request and create a new Job object. If 1944 the "ipp-attribute-fidelity" attribute is set to 'true', the Job 1945 Template attributes that populate the new Job object are necessarily 1946 all the Job Template attributes supplied in the create request. If 1947 the "ipp-attribute-fidelity" attribute is set to 'false', the Job 1948 Template attributes that populate the new Job object are all the 1949 client supplied Job Template attributes that are supported or that 1950 have value substitution. Thus, some of the requested Job Template 1951 attributes will not appear in the Job object because the Printer 1952 object did not support those attributes. The attributes that 1953 populate the Job object are persistently stored with the Job object 1954 for that Job. A Get-Job-Attributes operation on that Job object will 1955 return only those attributes that are persistently stored with the 1956 Job object. 1958 Note: All Job Template attributes that are persistently stored with 1959 the Job object are intended to be "override values"; that is, they 1960 that take precedence over whatever other embedded instructions might 1961 be in the document data itself. However, it is not possible for all 1962 Printer objects to realize the semantics of "override". End users 1963 may query the Printer's "pdl-override-supported" attribute to 1964 determine if the Printer either attempts or does not attempt to 1965 override document data instructions with IPP attributes. 1967 There are some cases, where a Printer supports a Job Template 1968 attribute and has an associated default value set for that attribute. 1969 In the case where a client does not supply the corresponding 1970 attribute, the Printer does not use its default values to populate 1971 Job attributes when creating the new Job object; only Job Template 1972 attributes actually in the create request are used to populate the 1973 Job object. The Printer's default values are only used later at Job 1974 processing time if no other IPP attribute or instruction embedded in 1975 the document data is present. 1977 Note: If the default values associated with Job Template attributes 1978 that the client did not supply were to be used to populate the Job 1979 object, then these values would become "override values" rather than 1980 defaults. If the Printer supports the 'attempted' value of the "pdl- 1981 override-supported" attribute, then these override values could 1982 replace values specified within the document data. This is not the 1983 intent of the default value mechanism. A default value for an 1984 attribute is used only if the create request did not specify that 1985 attribute (or it was ignored when allowed by "ipp-attribute-fidelity" 1986 being 'false') and no value was provided within the content of the 1987 document data. 1989 If the client does not supply a value for some Job Template 1990 attribute, and the Printer does not support that attribute, as far as 1991 IPP is concerned, the result of processing that Job (with respect to 1992 the missing attribute) is undefined. 1994 3.1.2.3.5 Return one of the success status codes 1996 Once the Job object has been created, the Printer object accepts the 1997 request and returns to the client: 1999 1. the 'successful-ok' status code, if there are no unsupported or 2000 conflicting Job Template attributes or values. 2001 2. the 'successful-ok-conflicting-attributes' status code, if there 2002 are any conflicting Job Template attribute or values. 2003 3. the 'successful-ok-ignored-or-substituted-attributes' status 2004 code, if there are only unsupported Job Template attributes or 2005 values. 2007 Note: Unsupported Operation attributes or values that are returned 2008 do not affect the status returned in this step. If the unsupported 2009 Operation attribute was a serious error, the above already rejected 2010 the request in a previous step. If control gets to this step with 2011 unsupported Operation attributes being returned, they are not serious 2012 errors. 2014 The Printer object also returns Job status attributes that indicate 2015 the initial state of the Job ('pending', 'pending-held', 2016 'processing', etc.), etc. See Print-Job Response, [RFC2911] section 2017 3.2.1.2. 2019 3.1.2.3.6 Accept appended Document Content 2021 The Printer object accepts the appended Document Content data and 2022 either starts it printing, or spools it for later processing. 2024 3.1.2.3.7 Scheduling and Starting to Process the Job 2026 The Printer object uses its own configuration and implementation 2027 specific algorithms for scheduling the Job in the correct processing 2028 order. Once the Printer object begins processing the Job, the 2029 Printer changes the Job's state to 'processing'. If the Printer 2030 object supports PDL override (the "pdl-override-supported" attribute 2031 set to 'attempted'), the implementation does its best to see that IPP 2032 attributes take precedence over embedded instructions in the document 2033 data. 2035 3.1.2.3.8 Completing the Job 2037 The Printer object continues to process the Job until it can move the 2038 Job into the 'completed' state. If an Cancel-Job operation is 2039 received, the implementation eventually moves the Job into the 2040 'canceled' state. If the system encounters errors during processing 2041 that do not allow it to progress the Job into a completed state, the 2042 implementation halts all processing, cleans up any resources, and 2043 moves the Job into the 'aborted' state. 2045 3.1.2.3.9 Destroying the Job after completion 2047 Once the Job moves to the 'completed', 'aborted', or 'canceled' 2048 state, it is an implementation decision as to when to destroy the Job 2049 object and release all associated resources. Once the Job has been 2050 destroyed, the Printer would return either the "client-error-not- 2051 found" or "client-error-gone" status codes for operations directed at 2052 that Job. 2054 Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" 2055 value for a sufficiently long time after a job has been destroyed, so 2056 that stale references kept by clients are less likely to access the 2057 wrong (newer) job. 2059 3.1.2.3.10 Interaction with "ipp-attribute-fidelity" 2061 Some Printer object implementations may support "ipp-attribute- 2062 fidelity" set to 'true' and "pdl-override-supported" set to 2063 'attempted' and yet still not be able to realize exactly what the 2064 client specifies in the create request. This is due to legacy 2065 decisions and assumptions that have been made about the role of job 2066 instructions embedded within the document data and external job 2067 instructions that accompany the document data and how to handle 2068 conflicts between such instructions. The inability to be 100% 2069 precise about how a given implementation will behave is also 2070 compounded by the fact that the two special attributes, "ipp- 2071 attribute-fidelity" and "pdl-"override-supported", apply to the whole 2072 job rather than specific values for each attribute. For example, some 2073 implementations may be able to override almost all Job Template 2074 attributes except for "number-up". Character Sets, natural languages, 2075 and internationalization 2077 This section discusses character set support, natural language 2078 support and internationalization. 2080 3.1.2.3.11 Character set code conversion support 2082 IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY 2083 support additional charsets. It is RECOMMENDED that an IPP object 2084 also support US-ASCII, since many clients support US-ASCII, and 2085 indicate that UTF-8 and US-ASCII are supported by populating the 2086 Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An 2087 IPP object is required to code covert with as little loss as possible 2088 between the charsets that it supports, as indicated in the Printer's 2089 "charsets-supported" attribute. 2091 How should the server handle the situation where the "attributes- 2092 charset" of the response itself is "us-ascii", but one or more 2093 attributes in that response is in the "utf-8" format? 2095 Example: Consider a case where a client sends a Print-Job request 2096 with "utf-8" as the value of "attributes-charset" and with the "job- 2097 name" attribute supplied. Later another client submits a Get-Job- 2098 Attribute or Get-Jobs request. This second request contains the 2099 "attributes-charset" with value "us-ascii" and "requested-attributes" 2100 attribute with exactly one value "job-name". 2102 According to the RFC2911 document (section 3.1.4.2), the value of the 2103 "attributes-charset" for the response of the second request must be 2104 "us-ascii" since that is the charset specified in the request. The 2105 "job-name" value, however, is in "utf-8" format. Should the request 2106 be rejected even though both "utf-8" and "us-ascii" charsets are 2107 supported by the server? or should the "job-name" value be converted 2108 to "us-ascii" and return "successful-ok-conflicting-attributes" 2109 (0x0002) as the status code? 2111 Answer: An IPP object that supports both utf-8 (REQUIRED) and us- 2112 ascii, the second paragraph of section 3.1.4.2 applies so that the 2113 IPP object MUST accept the request, perform code set conversion 2114 between these two charsets with "the highest fidelity possible" and 2115 return 'successful-ok', rather than a warning 'successful-ok- 2116 conflicting-attributes, or an error. The printer will do the best it 2117 can to convert between each of the character sets that it supports-- 2118 even if that means providing a string of question marks because none 2119 of the characters are representable in US ASCII. If it can't perform 2120 such conversion, it MUST NOT advertise us-ascii as a value of its 2121 "attributes-charset-supported" and MUST reject any request that 2122 requests 'us-ascii'. 2124 One IPP object implementation strategy is to convert all request text 2125 and name values to a Unicode internal representation. This is 16-bit 2126 and virtually universal. Then convert to the specified operation 2127 attributes-charset on output. 2129 Also it would be smarter for a client to ask for 'utf-8', rather than 2130 'us-ascii' and throw away characters that it doesn't understand, 2131 rather than depending on the code conversion of the IPP object. 2133 3.1.2.3.12 What charset to return when an unsupported charset is 2134 requested (Issue 1.19)? 2136 Section 3.1.4.1 Request Operation attributes was clarified in 2137 November 1998 as follows: 2139 All clients and IPP objects MUST support the 'utf-8' charset 2140 [RFC2044] and MAY support additional charsets provided that they are 2141 registered with IANA [IANA-CS]. If the Printer object does not 2142 support the client supplied charset value, the Printer object MUST 2143 reject the request, set the "attributes-charset" to 'utf-8' in the 2144 response, and return the 'client-error-charset-not-supported' status 2145 code and any 'text' or 'name' attributes using the 'utf-8' charset. 2147 Since the client and IPP object MUST support UTF-8, returning any 2148 text or name attributes in UTF-8 when the client requests a charset 2149 that is not supported should allow the client to display the text or 2150 name. 2152 Since such an error is a client error, rather than a user error, the 2153 client should check the status code first so that it can avoid 2154 displaying any other returned 'text' and 'name' attributes that are 2155 not in the charset requested. 2157 Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not- 2158 supported (0x040D) was clarified in November 1998 as follows: 2160 For any operation, if the IPP Printer does not support the charset 2161 supplied by the client in the "attributes-charset" operation 2162 attribute, the Printer MUST reject the operation and return this 2163 status and any 'text' or 'name' attributes using the 'utf-8' charset 2164 (see Section 3.1.4.1). 2166 3.1.2.3.13 Natural Language Override (NLO) 2168 The 'text' and 'name' attributes each have two forms. One has an 2169 implicit natural language, and the other has an explicit natural 2170 language. The 'textWithoutLanguage' and 'textWithLanguage' are the 2171 two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage 2172 are the two 'name' forms. If a receiver (IPP object or IPP client) 2173 supports an attribute with attribute syntax 'text', it MUST support 2174 both forms in a request and a response. A sender (IPP client or IPP 2175 object) MAY send either form for any such attribute. When a sender 2176 sends a WithoutLanguage form, the implicit natural language is 2177 specified in the "attributes-natural-language" operation attribute, 2178 which all senders MUST include in every request and response. 2180 When a sender sends a WithLanguage form, it MAY be different from the 2181 implicit natural language supplied by the sender or it MAY be the 2182 same. The receiver MUST treat either form equivalently. 2184 There is an implementation decision for senders, whether to always 2185 send the WithLanguage forms or use the WithoutLanguage form when the 2186 attribute's natural language is the same as the request or response. 2187 The former approach makes the sender implementation simpler. The 2188 latter approach is more efficient on the wire and allows inter- 2189 working with non-conforming receivers that fail to support the 2190 WithLanguage forms. As each approach have advantages, the choice is 2191 completely up to the implementer of the sender. 2193 Furthermore, when a client receives a 'text' or 'name' job attribute 2194 that it had previously supplied, that client MUST NOT expect to see 2195 the attribute in the same form, i.e., in the same WithoutLanguage or 2196 WithLanguage form as the client supplied when it created the job. 2197 The IPP object is free to transform the attribute from the 2198 WithLanguage form to the WithoutLanguage form and vice versa, as long 2199 as the natural language is preserved. However, in order to meet this 2200 latter requirement, it is usually simpler for the IPP object 2201 implementation to store the natural language explicitly with the 2202 attribute value, i.e., to store using an internal representation that 2203 resembles the WithLanguage form. 2205 The IPP Printer MUST copy the natural language of a job, i.e., the 2206 value of the "attributes-natural-language" operation attribute 2207 supplied by the client in the create operation, to the Job object as 2208 a Job Description attribute, so that a client is able to query it. 2209 In returning a Get-Job-Attributes response, the IPP object MAY return 2210 one of three natural language values in the response's "attributes- 2211 natural-language" operation attribute: (1) that requested by the 2212 requester, (2) the natural language of the job, or (3) the configured 2213 natural language of the IPP Printer, if the requested language is not 2214 supported by the IPP Printer. 2216 This "attributes-natural-language" Job Description attribute is 2217 useful for an IPP object implementation that prints start sheets in 2218 the language of the user who submitted the job. This same Job 2219 Description attribute is useful to a multi-lingual operator who has 2220 to communicate with different job submitters in different natural 2221 languages. This same Job Description attribute is expected to be 2222 used in the future to generate notification messages in the natural 2223 language of the job submitter. 2225 Early drafts of [RFC2911] contained a job-level natural language 2226 override (NLO) for the Get-Jobs response. A job-level (NLO) is an 2227 (unrequested) Job Attribute which then specified the implicit natural 2228 language for any other WithoutLanguage job attributes returned in the 2229 response for that job. Interoperability testing of early 2230 implementations showed that no one was implementing the job-level NLO 2231 in Get-Job responses. So the job-level NLO was eliminated from the 2232 Get-Jobs response. This simplification makes all requests and 2233 responses consistent in that the implicit natural language for any 2234 WithoutLanguage 'text' or 'name' form is always supplied in the 2235 request's or response's "attributes-natural-language" operation 2236 attribute. 2238 3.1.3 Status codes returned by operation 2240 This section corresponds to [RFC2911] section 3.1.6 "Operation 2241 Response Status Codes and Status Messages". This section lists all 2242 status codes once in the first operation (Print-Job). Then it lists 2243 the status codes that are different or specialized for subsequent 2244 operations under each operation. 2246 3.1.3.1 Printer Operations 2248 3.1.3.1.1 Print-Job 2250 The Printer object MUST return one of the following "status-code" 2251 values for the indicated reason. Whether all of the document data 2252 has been accepted or not before returning the success or error 2253 response depends on implementation. See Section 13 in [RFC2911] for 2254 a more complete description of each status code. 2256 For the following success status codes, the Job object has been 2257 created and the "job-id", and "job-uri" assigned and returned in the 2258 response: 2260 successful-ok: no request attributes were substituted or ignored. 2261 successful-ok-ignored-or-substituted-attributes: some supplied (1) 2262 attributes were ignored or (2) unsupported attribute syntaxes or 2263 values were substituted with supported values or were ignored. 2264 Unsupported attributes, attribute syntax's, or values MUST be 2265 returned in the Unsupported Attributes group of the response. 2266 successful-ok-conflicting-attributes: some supplied attribute 2267 values conflicted with the values of other supplied attributes 2268 and were either substituted or ignored. Attributes or values 2269 which conflict with other attributes and have been substituted 2270 or ignored MUST be returned in the Unsupported Attributes group 2271 of the response as supplied by the client. 2273 [RFC2911] section 3.1.6 Operation Status Codes and Messages states: 2275 If the Printer object supports the "status-message" operation 2276 attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a 2277 status message for the following error status codes (see section 13 2278 in [RFC2911]): 'client-error-bad-request', 'client-error-charset- 2279 not-supported', 'server-error-internal-error', 'server-error- 2280 operation-not-supported', and 'server-error-version-not-supported'. 2281 In this case, it MUST set the value of the "attributes-charset" 2282 operation attribute to 'utf-8' in the error response. 2284 For the following error status codes, no job is created and no 2285 "job-id" or "job-uri" is returned: 2287 client-error-bad-request: The request syntax does not conform 2288 to the specification. 2289 client-error-forbidden: The request is being refused for 2290 authorization or authentication reasons. The implementation 2291 security policy is to not reveal whether the failure is one of 2292 authentication or authorization. 2293 client-error-not-authenticated: Either the request requires 2294 authentication information to be supplied or the 2295 authentication information is not sufficient for 2296 authorization. 2297 client-error-not-authorized: The requester is not authorized to 2298 perform the request on the target object. 2299 client-error-not-possible: The request cannot be carried out 2300 because of the state of the system. See also 'server-error- 2301 not-accepting-jobs' status code, which MUST take precedence if 2302 the Printer object's "printer-accepting-jobs" attribute is 2303 'false'. 2304 client-error-timeout: not applicable. 2305 client-error-not-found: the target object does not exist. 2306 client-error-gone: the target object no longer exists and no 2307 forwarding address is known. 2308 client-error-request-entity-too-large: the size of the request 2309 and/or print data exceeds the capacity of the IPP Printer to 2310 process it. 2311 client-error-request-value-too-long: the size of request 2312 variable length attribute values, such as 'text' and 'name' 2313 attribute syntax's, exceed the maximum length specified in 2314 [RFC2911] for the attribute and MUST be returned in the 2315 Unsupported Attributes Group. 2316 client-error-document-format-not-supported: the document format 2317 supplied is not supported. The "document-format" attribute 2318 with the unsupported value MUST be returned in the Unsupported 2319 Attributes Group. This error SHOULD take precedence over any 2320 other 'xxx-not-supported' error, except 'client-error-charset- 2321 not-supported'. 2322 client-error-attributes-or-values-not-supported: one or more 2323 supplied attributes, attribute syntax's, or values are not 2324 supported and the client supplied the "ipp-attributes- 2325 fidelity" operation attribute with a 'true' value. They MUST 2326 be returned in the Unsupported Attributes Group as explained 2327 below. 2328 client-error-uri-scheme-not-supported: not applicable. 2330 client-error-charset-not-supported: the charset supplied in the 2331 "attributes-charset" operation attribute is not supported. 2332 The Printer's "configured-charset" MUST be returned in the 2333 response as the value of the "attributes-charset" operation 2334 attribute and used for any 'text' and 'name' attributes 2335 returned in the error response. This error SHOULD take 2336 precedence over any other error, unless the request syntax is 2337 so bad that the client's supplied "attributes-charset" cannot 2338 be determined. 2339 client-error-conflicting-attributes: one or more supplied 2340 attribute values conflicted with each other and the client 2341 supplied the "ipp-attributes-fidelity" operation attribute 2342 with a 'true' value. They MUST be returned in the Unsupported 2343 Attributes Group as explained below. 2344 server-error-internal-error: an unexpected condition prevents 2345 the request from being fulfilled. 2346 server-error-operation-not-supported: not applicable (since 2347 Print-Job is REQUIRED). 2348 server-error-service-unavailable: the service is temporarily 2349 overloaded. 2350 server-error-version-not-supported: the version in the request 2351 is not supported. The "closest" version number supported MUST 2352 be returned in the response. 2353 server-error-device-error: a device error occurred while 2354 receiving or spooling the request or document data or the IPP 2355 Printer object can only accept one job at a time. 2356 server-error-temporary-error: a temporary error such as a 2357 buffer full write error, a memory overflow, or a disk full 2358 condition occurred while receiving the request and/or the 2359 document data. 2360 server-error-not-accepting-jobs: the Printer object's "printer- 2361 is-not-accepting-jobs" attribute is 'false'. 2362 server-error-busy: the Printer is too busy processing jobs to 2363 accept another job at this time. 2364 server-error-job-canceled: the job has been canceled by an 2365 operator or the system while the client was transmitting the 2366 document data. 2368 3.1.3.1.2 Print-URI 2370 All of the Print-Job status codes described in Section 3.1.3.1.1 2371 Print-Job Response are applicable to Print-URI with the following 2372 specializations and differences. See Section 14 for a more complete 2373 description of each status code. 2375 client-error-uri-scheme-not-supported: the URI scheme supplied in 2376 the "document-uri" operation attribute is not supported and is 2377 returned in the Unsupported Attributes group. 2378 server-error-operation-not-supported: the Print-URI operation is 2379 not supported. 2381 3.1.3.1.3 Validate-Job 2383 All of the Print-Job status codes described in Section 3.1.3.1.1 2384 Print-Job Response are applicable to Validate-Job. See Section 13 in 2385 [RFC2911] for a more complete description of each status code. 2387 3.1.3.1.4 Create-Job 2389 All of the Print-Job status codes described in Section 3.1.3.1.1 2390 Print-Job Response are applicable to Create-Job with the following 2391 specializations and differences. See Section 13 in [RFC2911] for a 2392 more complete description of each status code. 2394 server-error-operation-not-supported: the Create-Job operation is 2395 not supported. 2396 client-error-multiple-document-jobs-not-supported: while the 2397 Create-Job and Send-Document operations are supported, this 2398 implementation doesn't support more than one document with data. 2400 3.1.3.1.5 Get-Printer-Attributes 2402 All of the Print-Job status codes described in Section 3.1.3.1.1 2403 Print-Job Response are applicable to the Get-Printer-Attributes 2404 operation with the following specialization's and differences. See 2405 Section 13 in [RFC2911] for a more complete description of each 2406 status code. 2408 For the following success status codes, the requested attributes are 2409 returned in Group 3 in the response: 2411 successful-ok: no operation attributes or values were substituted 2412 or ignored (same as Print-Job) and no requested attributes were 2413 unsupported. 2414 successful-ok-ignored-or-substituted-attributes: The "requested- 2415 attributes" operation attribute MAY, but NEED NOT, be returned 2416 with the unsupported values. 2417 successful-ok-conflicting-attributes: same as Print-Job. 2419 For the error status codes, Group 3 is returned containing no 2420 attributes or is not returned at all: 2422 client-error-not-possible: Same as Print-Job, in addition the 2423 Printer object is not accepting any requests. 2424 client-error-request-entity-too-large: same as Print-job, except 2425 that no print data is involved. 2427 client-error-attributes-or-values-not-supported: not applicable, 2428 since unsupported operation attributes and/or values MUST be 2429 ignored and an appropriate success code returned (see above). 2430 client-error-conflicting-attributes: same as Print-Job, except 2431 that "ipp-attribute-fidelity" is not involved. 2432 server-error-operation-not-supported: not applicable (since Get- 2433 Printer-Attributes is REQUIRED). 2434 server-error-device-error: same as Print-Job, except that no 2435 document data is involved. 2436 server-error-temporary-error: same as Print-Job, except that no 2437 document data is involved. 2438 server-error-not-accepting-jobs: not applicable. 2439 server-error-busy: same as Print-Job, except the IPP object is too 2440 busy to accept even query requests. 2441 server-error-job-canceled: not applicable. 2443 3.1.3.1.6 Get-Jobs 2445 All of the Print-Job status codes described in Section 3.1.3.1.1 2446 Print-Job Response are applicable to the Get-Jobs operation with the 2447 following specialization's and differences. See Section 13 in 2448 [RFC2911] for a more complete description of each status code. 2450 For the following success status codes, the requested attributes are 2451 returned in Group 3 in the response: 2453 successful-ok: same as Get-Printer-Attributes (see section 2454 3.1.3.1.5). 2455 successful-ok-ignored-or-substituted-attributes: same as Get- 2456 Printer-Attributes (see section 3.1.3.1.5). 2457 successful-ok-conflicting-attributes: same as Get-Printer- 2458 Attributes (see section 3.1.3.1.5). 2460 For any error status codes, Group 3 is returned containing no 2461 attributes or is not returned at all. The following brief error 2462 status code descriptions contain unique information for use with Get- 2463 Jobs operation. See section 14 for the other error status codes that 2464 apply uniformly to all operations: 2466 client-error-not-possible: Same as Print-Job, in addition the 2467 Printer object is not accepting any requests. 2468 client-error-request-entity-too-large: same as Print-job, 2469 except that no print data is involved. 2470 client-error-document-format-not-supported: not applicable. 2471 client-error-attributes-or-values-not-supported: not 2472 applicable, since unsupported operation attributes and/or 2473 values MUST be ignored and an appropriate success code 2474 returned (see above). 2475 client-error-conflicting-attributes: same as Print-Job, except 2476 that "ipp-attribute-fidelity" is not involved. 2478 server-error-operation-not-supported: not applicable (since 2479 Get-Jobs is REQUIRED). 2480 server-error-device-error: same as Print-Job, except that no 2481 document data is involved. 2482 server-error-temporary-error: same as Print-Job, except that no 2483 document data is involved. 2484 server-error-not-accepting-jobs: not applicable. 2485 server-error-job-canceled: not applicable. 2487 3.1.3.1.7 Pause-Printer 2489 All of the Print-Job status codes described in Section 3.1.3.1.1 2490 Print-Job Response are applicable to Pause-Printer with the following 2491 specializations and differences. See Section 13 in [RFC2911] for a 2492 more complete description of each status code. 2494 For the following success status codes, the Printer object is being 2495 stopped from scheduling jobs on all its devices. 2497 successful-ok: no request attributes were substituted or 2498 ignored (same as Print-Job). 2499 successful-ok-ignored-or-substituted-attributes: same as 2500 Print-Job. 2501 successful-ok-conflicting-attributes: same as Print-Job. 2503 For any of the error status codes, the Printer object has not been 2504 stopped from scheduling jobs on all its devices. 2506 client-error-not-possible: not applicable. 2507 client-error-not-found: the target Printer object does not 2508 exist. 2509 client-error-gone: the target Printer object no longer exists 2510 and no forwarding address is known. 2511 client-error-request-entity-too-large: same as Print-Job, 2512 except no document data is involved. 2513 client-error-document-format-not-supported: not applicable. 2514 client-error-conflicting-attributes: same as Print-Job, except 2515 that the Printer's "printer-is-accepting-jobs" attribute is 2516 not involved. 2517 server-error-operation-not-supported: the Pause-Printer 2518 operation is not supported. 2519 server-error-device-error: not applicable. 2520 server-error-temporary-error: same as Print-Job, except no 2521 document data is involved. 2522 server-error-not-accepting-jobs: not applicable. 2523 server-error-job-canceled: not applicable. 2525 3.1.3.1.8 Resume-Printer 2527 All of the Print-Job status code descriptions in Section 3.1.3.1.1 2528 Print-Job Response with the specialization's described for Pause- 2529 Printer are applicable to Resume-Printer. See Section 13 in 2530 [RFC2911] for a more complete description of each status code. 2532 For the following success status codes, the Printer object resumes 2533 scheduling jobs on all its devices. 2535 successful-ok: no request attributes were substituted or 2536 ignored (same as Print-Job). 2537 successful-ok-ignored-or-substituted-attributes: same as 2538 Print-Job. 2539 successful-ok-conflicting-attributes: same as Print-Job. 2541 For any of the error status codes, the Printer object does not resume 2542 scheduling jobs. 2544 server-error-operation-not-supported: the Resume-Printer 2545 operation is not supported. 2547 3.1.3.1.8.1 What about Printers unable to change state due to an error 2548 condition? 2549 If, in case, the IPP printer is unable to change its state due to 2550 some problem with the actual printer device (say, it is shut down or 2551 there is a media-jam as indicated in [RFC2911]), what should be the 2552 result of the "Resume-Printer" operation? Should it still change the 2553 'printer-state-reasons' and return success or should it fail ? 2555 The Resume-Printer operation must clear the 'paused' or 'moving-to- 2556 paused' 'printer-state-message'. The operation must return a 2557 'successful-ok' status code. 2559 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? 2561 If the Resume-Printer operation succeeds, what should be the value of 2562 "printer-state" and who should take care of the "printer-state" 2563 attribute value later on ? 2565 The Resume-Printer operation may change the "printer-state-reasons" 2566 value. 2568 The "printer-state" will change to one of three states: 2570 1. 'idle' - no additional jobs and no error conditions present 2571 2. 'processing' - job available and no error conditions present 2573 3. current state (i.e. no change) an error condition is present 2574 (e.g. media jam) 2576 In the third case the "printer-state-reason" will be cleared by 2577 automata when it detects the error condition no longer exists. The 2578 "printer-state" will move to 'idle' or 'processing' when conditions 2579 permit. (i.e. no more error conditions) 2581 3.1.3.1.9 Purge-Printer 2583 All of the Print-Job status code descriptions in Section 3.1.3.1.1 2584 Print-Job Response with the specialization's described for Pause- 2585 Printer are applicable to Purge-Printer. See Section 13 in [RFC2911] 2586 for a more complete description of each status code. 2588 For the following success status codes, the Printer object purges all 2589 it's jobs. 2591 successful-ok: no request attributes were substituted or 2592 ignored (same as Print-Job). 2593 successful-ok-ignored-or-substituted-attributes: same as 2594 Print-Job. 2595 successful-ok-conflicting-attributes: same as Print-Job. 2597 For any of the error status codes, the Printer object does not purge 2598 any jobs. 2600 server-error-operation-not-supported: the Purge-Printer 2601 operation is not supported. 2603 3.1.3.2 Job Operations 2605 3.1.3.2.1 Send-Document 2607 All of the Print-Job status codes described in Section 3.1.3.1.1 2608 Print-Job Response are applicable to the Get-Printer-Attributes 2609 operation with the following specialization's and differences. See 2610 Section 13 in [RFC2911] for a more complete description of each 2611 status code. 2613 For the following success status codes, the document has been added 2614 to the specified Job object and the job's "number-of-documents" 2615 attribute has been incremented: 2617 successful-ok: no request attributes were substituted or 2618 ignored (same as Print-Job). 2620 successful-ok-ignored-or-substituted-attributes: same as Print- 2621 Job. 2622 successful-ok-conflicting-attributes: same as Print-Job. 2624 For the error status codes, no document has been added to the Job 2625 object and the job's "number-of-documents" attribute has not been 2626 incremented: 2628 client-error-not-possible: Same as Print-Job, except that the 2629 Printer's "printer-is-accepting-jobs" attribute is not 2630 involved, so that the client is able to finish submitting a 2631 job that was created with a Create-Job operation after this 2632 attribute has been set to 'true'. Another condition is that 2633 the state of the job precludes Send-Document, i.e., the job 2634 has already been closed out by the client. However, if the 2635 IPP Printer closed out the job due to timeout, the 'client- 2636 error-timeout' error status SHOULD be returned instead. 2637 client-error-timeout: This request was sent after the Printer 2638 closed the job, because it has not received a Send-Document or 2639 Send-URI operation within the Printer's "multiple-operation- 2640 time-out" period . 2641 client-error-request-entity-too-large: same as Print-Job. 2642 client-error-conflicting-attributes: same as Print-Job, except 2643 that "ipp-attributes-fidelity" operation attribute is not 2644 involved.. 2645 server-error-operation-not-supported: the Send-Document request 2646 is not supported. 2647 server-error-not-accepting-jobs: not applicable. 2648 server-error-job-canceled: the job has been canceled by an 2649 operator or the system while the client was transmitting the 2650 data. 2652 3.1.3.2.2 Send-URI 2654 All of the Print-Job status code descriptions in Section 3.1.3.1.1 2655 Print-Job Response with the specialization's described for Send- 2656 Document are applicable to Send-URI. See Section 13 in [RFC2911] for 2657 a more complete description of each status code. 2659 client-error-uri-scheme-not-supported: the URI scheme supplied 2660 in the "document-uri" operation attribute is not supported and 2661 the "document-uri" attribute MUST be returned in the 2662 Unsupported Attributes group. 2663 server-error-operation-not-supported: the Send-URI operation is 2664 not supported. 2666 3.1.3.2.3 Cancel-Job 2668 All of the Print-Job status codes described in Section 3.1.3.1.1 2669 Print-Job Response are applicable to Cancel-Job with the following 2670 specializations and differences. See Section 13 in [RFC2911] for a 2671 more complete description of each status code. 2673 For the following success status codes, the Job object is being 2674 canceled or has been canceled: 2676 successful-ok: no request attributes were substituted or 2677 ignored (same as Print-Job). 2678 successful-ok-ignored-or-substituted-attributes: same as 2679 Print-Job. 2680 successful-ok-conflicting-attributes: same as Print-Job. 2682 For any of the error status codes, the Job object has not been 2683 canceled or was previously canceled. 2685 client-error-not-possible: The request cannot be carried out 2686 because of the state of the Job object ('completed', 2687 'canceled', or 'aborted') or the state of the system. 2688 client-error-not-found: the target Printer and/or Job object 2689 does not exist. 2690 client-error-gone: the target Printer and/or Job object no 2691 longer exists and no forwarding address is known. 2692 client-error-request-entity-too-large: same as Print-Job, 2693 except no document data is involved. 2694 client-error-document-format-not-supported: not applicable. 2695 client-error-attributes-or-values-not-supported: not 2696 applicable, since unsupported operation attributes and values 2697 MUST be ignored. 2698 client-error-conflicting-attributes: same as Print-Job, except 2699 that the Printer's "printer-is-accepting-jobs" attribute is 2700 not involved. 2701 server-error-operation-not-supported: not applicable (Cancel- 2702 Job is REQUIRED). 2703 server-error-device-error: same as Print-Job, except no 2704 document data is involved. 2705 server-error-temporary-error: same as Print-Job, except no 2706 document data is involved. 2707 server-error-not-accepting-jobs: not applicable.. 2708 server-error-job-canceled: not applicable. 2710 3.1.3.2.4 Get-Job-Attributes 2712 All of the Print-Job status codes described in Section 3.1.3.1.1 2713 Print-Job Response are applicable to Get-Job-Attributes with the 2714 following specializations and differences. See Section 13 in 2715 [RFC2911] for a more complete description of each status code. 2717 For the following success status codes, the requested attributes are 2718 returned in Group 3 in the response: 2720 successful-ok: same as Get-Printer-Attributes (see section 2721 3.1.3.1.5). 2722 successful-ok-ignored-or-substituted-attributes: same as Get- 2723 Printer-Attributes (see section 3.1.3.1.5). 2724 successful-ok-conflicting-attributes: same as Get-Printer- 2725 Attributes (see section 3.1.3.1.5). 2727 For the error status codes, Group 3 is returned containing no 2728 attributes or is not returned at all. 2730 client-error-not-possible: Same as Print-Job, in addition the 2731 Printer object is not accepting any requests. 2732 client-error-document-format-not-supported: not applicable. 2733 client-error-attributes-or-values-not-supported: not 2734 applicable. 2735 client-error-uri-scheme-not-supported: not applicable. 2736 client-error-attributes-or-values-not-supported: not 2737 applicable, since unsupported operation attributes and/or 2738 values MUST be ignored and an appropriate success code 2739 returned (see above). 2740 client-error-conflicting-attributes: not applicable 2741 server-error-operation-not-supported: not applicable (since 2742 Get-Job-Attributes is REQUIRED). 2743 server-error-device-error: same as Print-Job, except no 2744 document data is involved. 2745 server-error-temporary-error: sane as Print-Job, except no 2746 document data is involved.. 2747 server-error-not-accepting-jobs: not applicable. 2748 server-error-job-canceled: not applicable. 2750 3.1.3.2.5 Hold-Job 2752 All of the Print-Job status codes described in Section 3.1.3.1.1 2753 Print-Job Response are applicable to Hold-Job with the following 2754 specializations and differences. See Section 13 in [RFC2911] for a 2755 more complete description of each status code. 2757 For the following success status codes, the Job object is being held 2758 or has been held: 2760 successful-ok: no request attributes were substituted or 2761 ignored (same as Print-Job). 2762 successful-ok-ignored-or-substituted-attributes: same as 2763 Print-Job. 2764 successful-ok-conflicting-attributes: same as Print-Job. 2766 For any of the error status codes, the Job object has not been held 2767 or was previously held. 2769 client-error-not-possible: The request cannot be carried out 2770 because of the state of the Job object ('completed', 2771 'canceled', or 'aborted') or the state of the system. 2772 client-error-not-found: the target Printer and/or Job object 2773 does not exist. 2774 client-error-gone: the target Printer and/or Job object no 2775 longer exists and no forwarding address is known. 2776 client-error-request-entity-too-large: same as Print-Job, 2777 except no document data is involved. 2778 client-error-document-format-not-supported: not applicable. 2779 client-error-conflicting-attributes: same as Print-Job, except 2780 that the Printer's "printer-is-accepting-jobs" attribute is 2781 not involved. 2782 server-error-operation-not-supported: the Hold-Job operation is 2783 not supported. 2784 server-error-device-error: not applicable. 2785 server-error-temporary-error: same as Print-Job, except no 2786 document data is involved. 2787 server-error-not-accepting-jobs: not applicable. 2788 server-error-job-canceled: not applicable. 2790 3.1.3.2.6 Release-Job 2792 All of the Print-Job status code descriptions in Section 3.1.3.1.1 2793 Print-Job Response with the specialization's described for Hold-Job 2794 are applicable to Release-Job. See Section 13 in [RFC2911] for a 2795 more complete description of each status code. 2797 server-error-operation-not-supported: the Release-Job operation 2798 is not supported. 2800 3.1.3.2.7 Restart-Job 2802 All of the Print-Job status code descriptions in Section 3.1.3.1.1 2803 Print-Job Response with the specialization's described for Hold-Job 2804 are applicable to Restart-Job. See Section 13 in [RFC2911] for a 2805 more complete description of each status code. 2807 server-error-operation-not-supported: the Restart-Job operation 2808 is not supported. 2810 3.1.3.2.7.1 Can documents be added to a restarted job? 2811 Assume I give a Create-Job request along with a set of 5 documents . 2812 All the documents get printed and the job state is moved to completed 2813 . I issue a Restart-Job request on the job. Now the issue is that, if 2814 I try to add new documents to the restarted job, will the IPP Server 2815 permit me to do so or return "client-error-not-possible " and again 2816 print those 5 jobs? 2818 A job can not move to the 'completed' state until all the documents 2819 have been processed. The 'last-document' flag indicates when the 2820 last document for a job is being sent from the client. This is the 2821 semantic equivalent of closing a job. No documents may be added once 2822 a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job 2823 is moved to the 'pending' job state and restarts the beginning on the 2824 same IPP Printer object with the same attribute values." 'number-of- 2825 documents' is a job attribute. 2827 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue 2828 1.18) 2830 In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes 2831 responses, the client cannot depend on getting unsupported attributes 2832 returned in the Unsupported Attributes group that the client 2833 requested, but are not supported by the IPP object. However, such 2834 unsupported requested attributes will not be returned in the Job 2835 Attributes or Printer Attributes group (since they are unsupported). 2836 Furthermore, the IPP object is REQUIRED to return the 'successful-ok- 2837 ignored-or-substituted-attributes' status code, so that the client 2838 knows that not all that was requested has been returned. 2840 3.1.5 Sending empty attribute groups 2842 The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender 2843 not send an empty attribute group in a request or a response. 2844 However, they REQUIRE a receiver to accept an empty attribute group 2845 as equivalent to the omission of that group. So a client SHOULD omit 2846 the Job Template Attributes group entirely in a create operation that 2847 is not supplying any Job Template attributes. Similarly, an IPP 2848 object SHOULD omit an empty Unsupported Attributes group if there are 2849 no unsupported attributes to be returned in a response. 2851 The [RFC2910] specification REQUIRES a receiver to be able to receive 2852 either an empty attribute group or an omitted attribute group and 2853 treat them equivalently. The term "receiver" means an IPP object for 2854 a request and a client for a response. The term "sender' means a 2855 client for a request and an IPP object for a response. 2857 There is an exception to the rule for Get-Jobs when there are no 2858 attributes to be returned. [RFC2910] contains the following 2859 paragraph: 2861 The syntax allows an xxx-attributes-tag to be present when the xxx- 2862 attribute-sequence that follows is empty. The syntax is defined this 2863 way to allow for the response of Get-Jobs where no attributes are 2864 returned for some job-objects. Although it is RECOMMENDED that the 2865 sender not send an xxx-attributes-tag if there are no attributes 2866 (except in the Get-Jobs response just mentioned), the receiver MUST 2867 be able to decode such syntax. 2869 3.2 Printer Operations 2871 3.2.1 Print-Job operation 2873 3.2.1.1 Flow controlling the data portion of a Print-Job request 2874 (Issue 1.22) 2876 A paused printer, or one that is stopped due to paper out or jam or 2877 spool space full or buffer space full, may flow control the data of a 2878 Print-Job operation (at the TCP/IP layer), so that the client is not 2879 able to send all the document data. Consequently, the Printer will 2880 not return a response until the condition is changed. 2882 The Printer should not return a Print-Job response with an error code 2883 in any of these conditions, since either the printer will be resumed 2884 and/or the condition will be freed either by human intervention or as 2885 jobs print. 2887 In writing test scripts to test IPP Printers, the script must also be 2888 written not to expect a response, if the printer has been paused, 2889 until the printer is resumed, in order to work with all possible 2890 implementations. 2892 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) 2894 An IPP client submits a small job via Print-Job. By the time the IPP 2895 printer/print server is putting together a response to the operation, 2896 the job has finished printing and been removed as an object from the 2897 print system. What should the job-state be in the response? 2899 The Model suggests that the Printer return a response before it even 2900 accepts the document content. The Job Object Attributes are returned 2901 only if the IPP object returns one of the success status codes. Then 2902 the job-state would always be "pending" or "pending-held". 2904 This issue comes up for the implementation of an IPP Printer object 2905 as a server that forwards jobs to devices that do not provide job 2906 status back to the server. If the server is reasonably certain that 2907 the job completed successfully, then it should return the job-state 2908 as 'completed'. Also the server can keep the job in its "job 2909 history" long after the job is no longer in the device. Then a user 2910 could query the server and see that the job was in the 'completed' 2911 state and completed as specified by the jobs "time-at-completed" 2912 time, which would be the same as the server submitted the job to the 2913 device. 2915 An alternative is for the server to respond to the client before or 2916 while sending the job to the device, instead of waiting until the 2917 server has finished sending the job to the device. In this case, the 2918 server can return the job's state as 'pending' with the 'job- 2919 outgoing' value in the job's "job-state-reasons" attribute. 2921 If the server doesn't know for sure whether the job completed 2922 successfully (or at all), it could return the (out-of-band) 'unknown' 2923 value. 2925 On the other hand, if the server is able to query the device and/or 2926 setup some sort of event notification that the device initiates when 2927 the job makes state transitions, then the server can return the 2928 current job state in the Print-Job response and in subsequent queries 2929 because the server knows what the job state is in the device (or can 2930 query the device). 2932 All of these alternatives depend on implementation of the server and 2933 the device. 2935 3.2.2 Get-Printer-Attributes operation 2937 If a Printer supports the "printer-make-and-model" attribute and 2938 returns the .INF file model name of the printer in that attribute, 2939 the Microsoft client will automatically install the correct driver 2940 (if available). 2942 Clients which poll periodically for printer status or queued-job- 2943 count should use the "requested-attributes" operation attribute to 2944 limit the scope of the query in order to save Printer and network 2945 resources. 2947 3.2.3 Get-Jobs operation 2949 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 2950 1.39)? 2952 In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute 2953 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' 2954 attribute be there too, and if it's not present what should the IPP 2955 printer do? 2957 [RFC2911] Section 8.3 describes the various cases of "requesting- 2958 user-name" being present or not for any operation. If the client 2959 does not supply a value for "requesting-user-name", the printer MUST 2960 assume that the client is supplying some anonymous name, such as 2961 "anonymous". 2963 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation? 2965 When using the Get-Jobs operation a client implementer might choose 2966 to limit the number of jobs that the client shows on the first 2967 screenful. For example, if its UI can only display 50 jobs, it can 2968 defend itself against a printer that would otherwise return 500 jobs, 2969 perhaps taking a long time on a slow dial-up line. The client can 2970 then go and ask for a larger number of jobs in the background, while 2971 showing the user the first 50 jobs. Since the job history is returned 2972 in reverse order, namely the most recently completed jobs are 2973 returned first, the user is most likely interested in the first jobs 2974 that are returned. Limiting the number of jobs may be especially 2975 useful for a client that is requesting 'completed' jobs from a 2976 printer that keeps a long job history. Clients that don't mind 2977 sometimes getting very large responses, can omit the "limit" 2978 attribute in their Get-Jobs requests. 2980 3.2.4 Create-Job operation 2982 A Printer may respond to a Create-Job operation with "job-state" 2983 'pending' or 'pending-held' and " job-state-reason" 'job-data- 2984 insufficient' to indicate that operation has been accepted by the 2985 Printer, but the Printer is expecting additional document data before 2986 it can move the job into the 'processing' state. Alternatively, it 2987 may respond with "job-state" 'processing' and "job-state-reason" 2988 'job-incoming' to indicate that the Create-Job operation has been 2989 accepted by the Printer, but the Printer is expecting additional 2990 Send-Document and/or Send-URI operations and/or is 2991 accessing/accepting document data. The second alternative is for 2992 non-spooling Printers that don't implement the 'pending' state. 2994 Should the server wait for the "last-document" operation attribute 2995 set to 'true' before starting to "process" the job? 2996 It depends on implementation. Some servers spool the entire job, 2997 including all document data, before starting to process, so such an 2998 implementation would wait for the "last-document" before starting to 2999 process the job. If the time-out occurs without the "last-document", 3000 then the server takes one of the indicated actions in section 3.3.1 3001 in the [RFC2911] document. Other servers will start to process 3002 document data as soon as they have some. These are the so-called 3003 "non-spooling" printers. Currently, there isn't a way for a client to 3004 determine whether the Printer will spool all the data or will start 3005 to process (and print) as soon as it has some data. 3007 3.3 Job Operations 3009 3.3.1 Validate-Job 3011 The Validate-Job operation has been designed so that its 3012 implementation may be a part of the Print-Job operation. Therefore, 3013 requiring Validate-Job is not a burden on implementers. Also it is 3014 useful for client's to be able to count on its presence in all 3015 conformance implementations, so that the client can determine before 3016 sending a long document, whether the job will be accepted by the IPP 3017 Printer or not. 3019 3.3.2 Restart-Job 3021 The Restart-Job operation allows the reprocessing of a completed job. 3022 Some jobs store the document data on the printer. Jobs created using 3023 the Print-Job operation are an example. It is required that the 3024 printer retains the job data after the job has moved to a 'completed 3025 state' in order for the Restart-Job operation to succeed. 3027 Some jobs contain only a reference to the job data. A job created 3028 using the Print-URI is an example of such a job. When the Restart- 3029 Job operation is issued the job is reprocessed. The job data MUST be 3030 retrieved again to print the job. 3032 It is possible that a job fails while attempting to access the print 3033 data. When such a job is the target of a Restart-Job the Printer 3034 SHALL attempt to retrieve the job data again. 3036 4 Object Attributes 3038 4.1 Attribute Syntax's 3040 4.1.1 The 'none' value for empty sets (Issue 1.37) 3042 [RFC2911] states that the 'none' value should be used as the value of 3043 a 1setOf when the set is empty. In most cases, sets that are 3044 potentially empty contain keywords so the keyword 'none' is used, but 3045 for the 3 finishings attributes, the values are enums and thus the 3046 empty set is represented by the enum 3. Currently there are no other 3047 attributes with 1setOf values, which can be empty and can contain 3048 values that are not keywords. This exception requires special code 3049 and is a potential place for bugs. It would have been better if we 3050 had chosen an out-of-band value, either "no-value" or some new value, 3051 such as 'none'. Since we didn't, implementations have to deal with 3052 the different representations of 'none', depending on the attribute 3053 syntax. 3055 4.1.2 Multi-valued attributes (Issue 1.31) 3057 What is the attribute syntax for a multi-valued attribute? Since 3058 some attributes support values in more than one data type, such as 3059 "media", "job-hold-until", and "job-sheets", IPP semantics associate 3060 the attribute syntax with each value, not with the attribute as a 3061 whole. The protocol associates the attribute syntax tag with each 3062 value. Don't be fooled, just because the attribute syntax tag comes 3063 before the attribute keyword. All attribute values after the first 3064 have a zero length attribute keyword as the indication of a 3065 subsequent value of the same attribute. 3067 4.1.3 Case Sensitivity in URIs (issue 1.6) 3069 IPP client and server implementations must be aware of the diverse 3070 uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and 3071 Host names as case insensitive but reminds us that the rest of the 3072 URL may well demonstrate case sensitivity. When creating URL's for 3073 fields where the choice is completely arbitrary, it is probably best 3074 to select lower case. However, this cannot be guaranteed and 3075 implementations MUST NOT rely on any fields being case-sensitive or 3076 case-insensitive in the URL beyond the URL scheme and host name 3077 fields. 3079 The reason that the IPP specification does not make any restrictions 3080 on URIs, is so that implementations of IPP may use off-the-shelf 3081 components that conform to the standards that define URIs, such as 3082 RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these 3083 specifications for rules of matching, comparison, and case- 3084 sensitivity. 3086 It is also recommended that System Administrators and implementations 3087 avoid creating URLs for different printers that differ only in their 3088 case. For example, don't have Printer1 and printer1 as two different 3089 IPP Printers. 3091 Example of equivalent URI's 3093 http://abc.com:80/~smith/home.html 3095 http://ABC.com/%7Esmith/home.html 3097 http:/ABC.com:/%7esmith/home.html 3099 Example of equivalent URI's using the IPP scheme 3101 ipp://abc.com:631/~smith/home.html 3103 ipp://ABC.com/%7Esmith/home.html 3105 http:/ABC.com:631/%7esmith/home.html 3107 The HTTP/1.1 specification [RFC2616] contains more details on 3108 comparing URLs. 3110 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage 3112 The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes 3113 that have two components. The first component is the 'language' 3114 component that can contain up to 63 octets. The second component is 3115 the 'text' or 'name' component. The maximum length of these are 1023 3116 octets and 255 octets respectively. The definition of attributes 3117 with either syntax may further restrict the length. (e.g. printer- 3118 name (name(127))) 3120 The length of the 'language' component has no effect on the allowable 3121 length of 'text' in 'textWithLanguage' or the length of 'name' in 3122 'nameWithLanguage' 3124 4.2 Job Template Attributes 3126 4.2.1 multiple-document-handling(type2 keyword) 3128 4.2.1.1 Support of multiple document jobs 3130 IPP/1.0 is silent on which of the four effects an implementation 3131 would perform if it supports Create-Job, but does not support 3132 "multiple-document-handling" or multiple documents per job. IPP/1.1 3133 was changed so that a Printer could support Create-Job without having 3134 to support multiple document jobs. The "multiple-document-jobs- 3135 supported" (boolean) Printer description attribute was added to 3136 IPP/1.1 along with the 'server-error-multiple-document-jobs-not- 3137 supported' status code for a Printer to indicate whether or not it 3138 supports multiple document jobs, when it supports the Create-Job 3139 operation. Also IPP/1.1 was clarified that the Printer MUST support 3140 the "multiple-document-handling" (type2 keyword) Job Template 3141 attribute with at least one value if the Printer supports multiple 3142 documents per job. 3144 4.3 Job Description Attributes 3146 4.3.1 Getting the date and time of day 3148 The "date-time-at-creation", "date-time-at-processing", and "date- 3149 time-at-completed" attributes are returned as dateTime syntax. 3150 These attributes are OPTIONAL for a Printer to support. However, 3151 there are various ways for a Printer to get the date and time of day. 3152 Some suggestions: 3154 1. A Printer can get time from an NTP timeserver if there's one 3155 reachable on the network . See RFC 1305. Also DHCP option 32 in 3156 RFC 2132 returns the IP address of the NTP server. 3158 2. Get the date and time at startup from a human operator 3160 3. Have an operator set the date and time using a web 3161 administrative interface 3163 4. Get the date and time from incoming HTTP requests, though the 3164 problems of spoofing need to be considered. Perhaps comparing 3165 several HTTP requests could reduce the chances of spoofing. 3167 5. Internal date time clock battery driven. 3169 6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" 3171 4.4 Printer Description Attributes 3173 4.4.1 queued-job-count (integer(0:MAX)) 3175 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? 3177 The reason that "queued-job-count" is RECOMMENDED, is that some 3178 clients look at that attribute alone when summarizing the status of a 3179 list of printers, instead of doing a Get-Jobs to determine the number 3180 of jobs in the queue. Implementations that fail to support the 3181 "queued-job-count" will cause that client to display 0 jobs when 3182 there are actually queued jobs. 3184 We would have made it a REQUIRED Printer attribute, but some 3185 implementations had already been completed before the issue was 3186 raised, so making it a SHOULD was a compromise. 3188 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is 3189 (Issue 1.15)? 3191 The "queued-job-count" is not a good measure of how busy the printer 3192 is when there are held jobs. A future registration could be to add a 3193 "held-job-count" (or an "active-job-count") Printer Description 3194 attribute if experience shows that such an attribute (combination) is 3195 needed to quickly indicate how busy a printer really is. 3197 4.4.2 printer-current-time (dateTime) 3199 A Printer implementation MAY support this attribute by obtaining the 3200 date and time by any number of implementation-dependent means at 3201 startup or subsequently. Examples include: 3203 1. an internal date time clock, 3205 2. from the operator at startup using the console, 3207 3. from an operator using an administrative web page, 3209 4. from HTTP headers supplied in client requests, 3211 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" 3212 6. from the network, using NTP [RFC1305] or DHCP option 32 3213 [RFC2132] that returns the IP address of the NTP server. 3215 If an implementation supports this attribute by obtaining the current 3216 time from the network (at startup or later), but the time is not 3217 available, then the implementation MUST return the value of this 3218 attribute using the out-of-band 'no-value' meaning not configured. 3219 See the beginning of section 4.1. 3221 Since the new "date-and-time-at-xxx" Job Description attributes refer 3222 to the "printer-current-time", they will be covered also. 3224 4.4.3 Printer-uri 3226 Must the operational attribute for printer-uri match one of the 3227 values in "printer-uri-supported"? 3229 A forgiving printer implementation would not reject the operation. 3230 But the implementation has its rights to reject a printer or job 3231 operation if the operational attribute printer-uri is not a value of 3232 the printer-uri-supported. The printer might not be improperly 3233 configured. The request obviously reached the printer. The printer 3234 could treat the printer-uri as the logical equivalent of a value in 3235 the printer-uri-supported. It would be implementation dependent for 3236 which value, and associated security policy, would apply. This does 3237 also apply to a job object specified with a printer-uri and job-id, 3238 or with a job-uri. See section 4.1.3 for how to compare URI's. 3240 4.5 Empty Jobs 3242 The IPP object model does not prohibit a job that contains no 3243 documents. Such a job may be created in a number of ways including a 3244 'create-job' followed by an 'add-document' that contains no data and 3245 has the 'last-document' flag set. 3247 An empty job is processed just as any other job. The operation that 3248 "closes" an empty job is not rejected because the job is empty. If 3249 no other conditions exist, other than the job is empty, the response 3250 to the operation will indicate success. After the job is scheduled 3251 and processed, the job state SHALL be 'completed'. 3253 There will be some variation in the value(s) of the "job-state- 3254 reasons" attribute. It is required that if no conditions, other than 3255 the job being empty, exist the "job-state-reasons" SHALL include the 3256 'completed-successfully'. If other conditions existed, the 3257 'completed-with-warnings' or 'completed-with-errors' values may be 3258 used. 3260 5 Directory Considerations 3262 5.1 General Directory Schema Considerations 3264 The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object 3265 attributes for directory schemas. See [RFC2911] APPENDIX E: Generic 3266 Directory Schema. 3268 The SLP printer template is defined in the "Definition of the Printer 3269 Abstract Service Type v2.0" document [svrloc-printer]. The LDAP 3270 printer template is defined in the "Internet Printing Protocol (IPP): 3271 LDAP Schema for Printer Services" document [ldap-printer]. Both 3272 documents systematically add "printer-" to any attribute that doesn't 3273 already start with "printer-" in order to keep the printer directory 3274 attributes distinct from other directory attributes. Also, instead 3275 of using "printer-uri-supported", "uri-authentication-supported", and 3276 "uri-security-supported", they use a "printer-xri-supported" 3277 attribute with special syntax to contain all of the same information 3278 in a single attribute. 3280 5.2 IPP Printer with a DNS name 3282 If the IPP printer has a DNS name should there be at least two values 3283 for the printer-uri-supported attribute. One URL with the fully 3284 qualified DNS name the other with the IP address in the URL? 3286 The printer may contain one or the other or both. It's up to the 3287 administrator to configure this attribute. 3289 6 Security Considerations 3291 This section corresponds to the RFC2911 Section 8 "Security 3292 Considerations. 3294 6.1 Querying jobs with IPP that were submitted using other job 3295 submission protocols (Issue 1.32) 3297 The following clarification was added to [RFC2911] section 8.5: 3299 8.5 Queries on jobs submitted using non-IPP protocols 3300 If the device that an IPP Printer is representing is able to accept 3301 jobs using other job submission protocols in addition to IPP, it is 3302 RECOMMEND that such an implementation at least allow such "foreign" 3303 jobs to be queried using Get-Jobs returning "job-id" and "job-uri" 3304 as 'unknown'. Such an implementation NEED NOT support all of the 3305 same IPP job attributes as for IPP jobs. The IPP object returns 3306 the 'unknown' out-of-band value for any requested attribute of a 3307 foreign job that is supported for IPP jobs, but not for foreign 3308 jobs. 3310 It is further RECOMMENDED, that the IPP Printer generate "job-id" 3311 and "job-uri" values for such "foreign jobs", if possible, so that 3312 they may be targets of other IPP operations, such as Get-Job- 3313 Attributes and Cancel-Job. Such an implementation also needs to 3314 deal with the problem of authentication of such foreign jobs. One 3315 approach would be to treat all such foreign jobs as belonging to 3316 users other than the user of the IPP client. Another approach 3317 would be for the foreign job to belong to 'anonymous'. Only if the 3318 IPP client has been authenticated as an operator or administrator 3319 of the IPP Printer object, could the foreign jobs be queried by an 3320 IPP request. Alternatively, if the security policy were to allow 3321 users to query other users' jobs, then the foreign jobs would also 3322 be visible to an end-user IPP client using Get-Jobs and Get-Job- 3323 Attributes. 3325 Thus IPP MAY be implemented as a "universal" protocol that provides 3326 access to jobs submitted with any job submission protocol. As IPP 3327 becomes widely implemented, providing a more universal access makes 3328 sense. 3330 7 Encoding and Transport 3332 This section discusses various aspects of IPP/1.1 Encoding and 3333 Transport [RFC2910]. 3335 A server is not required to send a response until after it has 3336 received the client's entire request. Hence, a client must not 3337 expect a response until after it has sent the entire request. 3338 However, we recommend that the server return a response as soon as 3339 possible if an error is detected while the client is still sending 3340 the data, rather than waiting until all of the data is received. 3341 Therefore, we also recommend that a client listen for an error 3342 response that an IPP server MAY send before it receives all the data. 3343 In this case a client, if chunking the data, can send a premature 3344 zero-length chunk to end the request before sending all the data (and 3345 so the client can keep the connection open for other requests, rather 3346 than closing it). If the request is blocked for some reason, a client 3347 MAY determine the reason by opening another connection to query the 3348 server using Get-Printer-Attributes. 3350 IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] 3351 to throttle clients when Printers are busy. Therefore, it is 3352 perfectly normal for an IPP client transmitting a Job to be blocked 3353 for a really long time. Accordingly, socket timeouts must be 3354 avoided. Some socket implementations have a timeout option, which 3355 specifies how long a write operation on a socket can be blocked 3356 before it times out and the blocking ends. A client should set this 3357 option for infinite timeout when transmitting Job submissions. 3359 Some IPP client applications might be able to perform other useful 3360 work while a Job transmission is blocked. For example, the client 3361 may have other jobs that it could transmit to other Printers 3362 simultaneously. A client may have a GUI, which must remain 3363 responsive to the user while the Job transmission is blocked. These 3364 clients should be designed to spawn a thread to handle the Job 3365 transmission at its own pace, leaving the main application free to do 3366 other work. Alternatively, single-threaded applications could use 3367 non-blocking I/O. 3369 Some Printer conditions, such as jam or lack of paper, could cause a 3370 client to be blocked indefinitely. Clients may open additional 3371 connections to the Printer to Get-Printer-Attributes, determine the 3372 state of the device, alert a user if the printer is stopped, and let 3373 a user decide whether to abort the job transmission or not. 3375 In the following sections, there are tables of all HTTP headers, 3376 which describe their use in an IPP client or server. The following 3377 is an explanation of each column in these tables. 3379 - the "header" column contains the name of a header 3380 - the "request/client" column indicates whether a client sends the 3381 header. 3382 - the "request/ server" column indicates whether a server supports 3383 the header when received. 3384 - the "response/ server" column indicates whether a server sends 3385 the header. 3386 - the "response /client" column indicates whether a client 3387 supports the header when received. 3388 - the "values and conditions" column specifies the allowed header 3389 values and the conditions for the header to be present in a 3390 request/response. 3392 The table for "request headers" does not have columns for responses, 3393 and the table for "response headers" does not have columns for 3394 requests. 3396 The following is an explanation of the values in the "request/client" 3397 and "response/ server" columns. 3399 - must: the client or server MUST send the header, 3400 - must-if: the client or server MUST send the header when the 3401 condition described in the "values and conditions" column is 3402 met, 3403 - may: the client or server MAY send the header 3404 - not: the client or server SHOULD NOT send the header. It is not 3405 relevant to an IPP implementation. 3407 The following is an explanation of the values in the 3408 "response/client" and "request/ server" columns. 3410 - must: the client or server MUST support the header, 3411 - may: the client or server MAY support the header 3412 - not: the client or server SHOULD NOT support the header. It is 3413 not relevant to an IPP implementation. 3415 7.1 General Headers 3417 The following is a table for the general headers. 3419 General- Request Response Values and Conditions 3420 Header 3422 Client Server Server Client 3424 Cache- must not must not "no-cache" only 3425 Control 3427 Connection must- must must- must "close" only. Both 3428 if if client and server SHOULD 3429 keep a connection for 3430 the duration of a 3431 sequence of operations. 3432 The client and server 3433 MUST include this header 3434 for the last operation 3435 in such a sequence. 3437 Date may may must may per RFC 1123 [RFC1123] 3438 from RFC 2616 [RFC2616] 3440 Pragma must not must not "no-cache" only 3442 Transfer- must- must must- must "chunked" only . Header 3443 Encoding if if MUST be present if 3444 Content-Length is 3445 absent. 3447 Upgrade not not not not 3449 Via not not not not 3451 7.2 Request Headers 3453 The following is a table for the request headers. 3455 Request- Client Server Request Values and Conditions 3456 Header 3457 Request- Client Server Request Values and Conditions 3458 Header 3460 Accept may must "application/ipp" only. This 3461 value is the default if the client 3462 omits it 3464 Accept- not not Charset information is within the 3465 Charset application/ipp entity 3467 Accept- may must empty and per RFC 2616 [RFC2616] 3468 Encoding and IANA registry for content- 3469 codings 3471 Accept- not not language information is within the 3472 Language application/ipp entity 3474 Authorization must- must per RFC 2616. A client MUST send 3475 if this header when it receives a 401 3476 "Unauthorized" response and does 3477 not receive a "Proxy- 3478 Authenticate" header. 3480 From not not per RFC 2616. Because RFC 3481 recommends sending this header 3482 only with the user's approval, it 3483 is not very useful 3485 Host must must per RFC 2616 3487 If-Match not not 3489 If-Modified- not not 3490 Since 3492 If-None-Match not not 3494 If-Range not not 3496 If- not not 3497 Unmodified- 3498 Since 3500 Max-Forwards not not 3502 Proxy- must- not per RFC 2616. A client MUST send 3503 Authorization if this header when it receives a 401 3504 "Unauthorized" response and a 3506 Request- Client Server Request Values and Conditions 3507 Header 3509 "Proxy-Authenticate" header. 3511 Range not not 3513 Referrer not not 3515 User-Agent not not 3517 7.3 Response Headers 3519 The following is a table for the request headers. 3521 Response- Server Client Response Values and Conditions 3522 Header 3524 Accept-Ranges not not 3526 Age not not 3528 Location must- may per RFC 2616. When URI needs 3529 if redirection. 3531 Proxy- not must per RFC 2616 3532 Authenticate 3534 Public may may per RFC 2616 3536 Retry-After may may per RFC 2616 3538 Server not not 3540 Vary not not 3542 Warning may may per RFC 2616 3544 WWW- must- must per RFC 2616. When a server needs 3545 Authenticate if to authenticate a client. 3547 7.4 Entity Headers 3549 The following is a table for the entity headers. 3551 Entity-Header Request Response Values and 3552 Conditions 3554 Client Server Server Client 3556 Allow not not not not 3558 Content-Base not not not not 3560 Content- may must must must per RFC 2616 and 3561 Encoding IANA registry for 3562 content codings. 3564 Content- not not not not Application/ipp 3565 Language handles language 3567 Content- must- must must- must the length of the 3568 Length if if message-body per 3569 RFC 2616. Header 3570 MUST be present if 3571 Transfer-Encoding 3572 is absent.. 3574 Content- not not not not 3575 Location 3577 Content-MD5 may may may may per RFC 2616 3579 Content-Range not not not not 3581 Content-Type must must must must "application/ipp" 3582 only 3584 ETag not not not not 3586 Expires not not not not 3588 Last-Modified not not not not 3590 7.5 Optional support for HTTP/1.0 3592 IPP implementations consist of an HTTP layer and an IPP layer. In 3593 the following discussion, the term "client" refers to the HTTP client 3594 layer and the term "server" refers to the HTTP server layer. The 3595 Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST 3596 be supported by all clients and all servers. However, a client 3597 and/or a server implementation may choose to also support HTTP 1.0. 3599 This option means that a server may choose to communicate with a 3600 (non-conforming) client that only supports HTTP 1.0. In such cases 3601 the server should not use any HTTP 1.1 specific parameters or 3602 features and should respond using HTTP version number 1.0. 3604 This option also means that a client may choose to communicate with a 3605 (non-conforming) server that only supports HTTP 1.0. In such cases, 3606 if the server responds with an HTTP 'unsupported version number' to 3607 an HTTP 1.1 request, the client should retry using HTTP version 3608 number 1.0. 3610 7.6 HTTP/1.1 Chunking 3612 7.6.1 Disabling IPP Server Response Chunking 3614 Clients MUST anticipate that the HTTP/1.1 server may chunk responses 3615 and MUST accept them in responses. However, a (non-conforming) HTTP 3616 client that is unable to accept chunked responses may attempt to 3617 request an HTTP 1.1 server not to use chunking in its response to an 3618 operation by using the following HTTP header: 3620 TE: identity 3622 This mechanism should not be used by a server to disable a client 3623 from chunking a request, since chunking of document data is an 3624 important feature for clients to send long documents. 3626 7.6.2 Warning About the Support of Chunked Requests 3628 This section describes some problems with the use of chunked requests 3629 and HTTP/1.1 servers. 3631 The HTTP/1.1 standard [RFC2616] requires that conforming servers 3632 support chunked requests for any method. However, in spite of this 3633 requirement, some HTTP/1.1 implementations support chunked responses 3634 in the GET method, but do not support chunked POST method requests. 3635 Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or 3636 servlets [Servlet] require that the client supply a Content-Length. 3637 These implementations might reject a chunked POST method and return a 3638 411 status code (Length Required), might attempt to buffer the 3639 request and run out of room returning a 413 status code (Request 3640 Entity Too Large), or might successfully accept the chunked request. 3642 Because of this lack of conformance of HTTP servers to the HTTP/1.1 3643 standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP 3644 Printer object implementation support chunked requests and that 3645 conforming clients accept chunked responses. Therefore, IPP object 3646 implementers are warned to seek HTTP server implementations that 3647 support chunked POST requests in order to conform to the IPP standard 3648 and/or use implementation techniques that support chunked POST 3649 requests. 3651 8 References 3653 [CGI] 3654 CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11- 3655 00.txt). 3657 [ldap-printer] 3658 Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing 3659 Protocol (IPP): LDAP Schema for Printer Services", , work in progress, April 27, 2000. 3662 [RFC793] 3663 J. Postel, "Transmission Control Protocol", RFC 793. 3665 [RFC1123] 3666 Braden, S., "Requirements for Internet Hosts - Application and 3667 Support", RFC 1123, October, 1989. 3669 [RFC2026] 3670 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 3671 2026, October 1996. 3673 [RFC2119] 3674 S. Bradner, "Key words for use in RFCs to Indicate Requirement 3675 Levels", RFC 2119 , March 1997. 3677 [RFC2396] 3678 Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 3679 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 3681 [RFC2565] 3682 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 3683 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 3684 April 1999. 3686 [RFC2566] 3687 Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing 3688 Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. 3690 [RFC2567] 3691 Wright, D., "Design Goals for an Internet Printing Protocol", 3692 draft-ietf-ipp-req-03.txt, November, 1998. 3694 [RFC2568 3695 Zilles, S., "Rationale for the Structure and Model and Protocol for 3696 the Internet Printing Protocol", RFC 2568, April 1999. 3698 [RFC2569] 3699 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 3700 LPD and IPP Protocols", RFC 2569, April 1999. 3702 [RFC2616] 3703 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 3704 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 3705 RFC 2616, June 1999. 3707 [RFC2910] 3708 Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing 3709 Protocol/1.0: Encoding and Transport", RFC 2910, September, 2000. 3711 [RFC2911] 3712 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 3713 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, 3714 September, 2000. 3716 [Servlet] 3717 Servlet Specification Version 2.1 3718 (http://java.sun.com/products/servlet/2.1/index.html). 3720 [svrloc-printer] 3721 St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the 3722 Printer Abstract Service Type v2.0", , work in progress, March 8, 2000. 3725 [SSL] 3726 Netscape, The SSL Protocol, Version 3, (Text version 3.02), 3727 November 1996. 3729 9 Authors' Address 3731 Thomas N. Hastings 3732 Xerox Corporation 3733 701 Aviation Blvd. 3734 El Segundo, CA 90245 3735 hastings@cp10.es.xerox.com 3737 Carl-Uno Manros 3738 Xerox Corporation 3739 701 Aviation Blvd. 3740 El Segundo, CA 90245 3741 manros@cp10.es.xerox.com 3743 Carl Kugler 3744 Mail Stop 003G 3745 IBM Printing Systems Co 3746 6300 Diagonal Hwy 3747 Boulder CO 80301 3748 Kugler@us.ibm.com 3750 Henrik Holst 3751 i-data Printing Systems 3752 Vadstrupvej 35-43 3753 2880 Bagsvaerd, Denmark 3754 hh@I-data.com 3756 Peter Zehler 3757 Xerox Corporation 3758 800 Philips Road 3759 Webster, NY 14580 3760 peter.zehler@usa.xerox.com 3762 10 Full Copyright Statement 3764 Copyright (C) The Internet Society (1999). All Rights Reserved 3766 This document and translations of it may be copied and furnished to 3767 others, and derivative works that comment on or otherwise explain it 3768 or assist in its implementation may be prepared, copied, published 3769 and distributed, in whole or in part, without restriction of any 3770 kind, provided that the above copyright notice and this paragraph are 3771 included on all such copies and derivative works. However, this 3772 document itself may not be modified in any way, such as by removing 3773 the copyright notice or references to the Internet Society or other 3774 Internet organizations, except as needed for the purpose of 3775 developing Internet standards in which case the procedures for 3776 copyrights defined in the Internet Standards process must be 3777 followed, or as required to translate it into languages other than 3778 English. 3780 The limited permissions granted above are perpetual and will not be 3781 revoked by the Internet Society or its successors or assigns. 3783 This document and the information contained herein is provided on an 3784 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3785 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3786 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3787 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3788 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3790 Acknowledgement 3792 Funding for the RFC Editor function is currently provided by the 3793 Internet Society.