idnits 2.17.00 (12 Aug 2021) /tmp/idnits2093/draft-ietf-ipp-implementers-guide-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 58 longer pages, the longest (page 6) being 80 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** The abstract seems to contain references ([IPP-PRO], [IPP-RAT], [IPP-MOD], [IPP-REQ], [IPPLPD]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 29 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 106: '...he values of the REQUIRED Operation at...' RFC 2119 keyword, line 107: '...he values of the OPTIONAL Operation at...' RFC 2119 keyword, line 148: '...ueued-job-count" RECOMMENDED (Issue 1....' RFC 2119 keyword, line 209: '...ontain the terminology MUST, MUST NOT,...' RFC 2119 keyword, line 210: '...MAY, NEED NOT, SHOULD, SHOULD NOT, REQ...' (120 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 257 has weird spacing: '...Attribu tions...' == Line 304 has weird spacing: '...RI Job r- ...' == Line 401 has weird spacing: '... Attrib ions...' == Line 1311 has weird spacing: '...tribute att...' == Line 1420 has weird spacing: '...(1setOf range...' == (32 more instances...) == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: OPTIONAL Operation attributes are those that an IPP object MAY or MAY NOT support. An IPP object validates the values of the OPTIONAL attributes supplied by the client. The IPP object performs the same syntactic validation checks for each OPTIONAL attribute value as in Section 2.2.1.5. As in Section 2.2.1.5, if any fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or the 'client-error-request-value-too-long' status code. -- 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 (February 12, 1999) is 8492 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: 'RFC2119' is mentioned on line 215, but not defined == Missing Reference: 'RFC2044' is mentioned on line 2230, but not defined ** Obsolete undefined reference: RFC 2044 (Obsoleted by RFC 2279) == Missing Reference: 'IANA-CS' is mentioned on line 2231, but not defined == Unused Reference: 'RFC2396' is defined on line 2909, but no explicit reference was found in the text == Unused Reference: 'SSL' is defined on line 2917, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CGI' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP' == Outdated reference: draft-ietf-ipp-lpd-ipp-map has been published as RFC 2569 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-lpd-ipp-map (ref. 'IPP LPD') == Outdated reference: draft-ietf-ipp-model has been published as RFC 2566 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-model (ref. 'IPP-MOD') == Outdated reference: draft-ietf-ipp-protocol has been published as RFC 2565 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-protocol (ref. 'IPP-PRO') == Outdated reference: draft-ietf-ipp-rat has been published as RFC 2568 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-rat (ref. 'IPP-RAT') == Outdated reference: draft-ietf-ipp-req has been published as RFC 2567 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-req (ref. 'IPP-REQ') ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'Servlet' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' Summary: 18 errors (**), 0 flaws (~~), 22 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 draft-ietf-ipp-implementers-guide-01.txt 4 T. Hastings 5 Xerox Corporation 6 C. Manros 7 Xerox Corporation 8 February 12, 1999 10 Internet Printing Protocol/1.0: Implementer's Guide 12 Copyright (C) The Internet Society (1999). All Rights Reserved. 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed as 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document is one of a set of documents, which together describe all 36 aspects of a new Internet Printing Protocol (IPP). IPP is an 37 application level protocol that can be used for distributed printing 38 using Internet tools and technologies. This document contains 39 information that supplements the IPP Model and Semantics [IPP-MOD] and 40 the IPP Transport and Encoding [IPP-PRO] documents. It is intended to 41 help implementers understand IPP/1.0 and some of the considerations that 42 may assist them in the design of their client and/or IPP object 43 implementations. For example, a typical order of processing requests is 44 given, including error checking. Motivation for some of the 45 specification decisions is also included. 47 Expires August 12, 1999 48 The full set of IPP documents includes: 50 Design Goals for an Internet Printing Protocol [IPP-REQ] 51 Rationale for the Structure and Model and Protocol for the Internet 52 Printing Protocol [IPP-RAT] 53 Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD] 54 Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO] 55 Mapping between LPD and IPP Protocols [IPP LPD] 57 The document, "Design Goals for an Internet Printing Protocol", takes a 58 broad look at distributed printing functionality, and it enumerates 59 real-life scenarios that help to clarify the features that need to be 60 included in a printing protocol for the Internet. It identifies 61 requirements for three types of users: end users, operators, and 62 administrators. The design goals document calls out a subset of end 63 user requirements that are satisfied in IPP/1.0. Operator and 64 administrator requirements are out of scope for version 1.0. 66 The document, "Rationale for the Structure and Model and Protocol for 67 the Internet Printing Protocol", describes IPP from a high level view, 68 defines a roadmap for the various documents that form the suite of IPP 69 specifications, and gives background and rationale for the IETF working 70 group's major decisions. 72 The document, "Internet Printing Protocol/1.0: Model and Semantics", 73 describes a simplified model with abstract objects, their attributes, 74 and their operations. The model introduces a Printer and a Job. The 75 Job supports multiple documents per Job. The model document also 76 addresses how security, internationalization, and directory issues are 77 addressed. 79 The document, "Internet Printing Protocol/1.0: Encoding and Transport", 80 is a formal mapping of the abstract operations and attributes defined in 81 the model document onto HTTP/1.1. It also defines the encoding rules 82 for a new Internet media type called "application/ipp". 84 The document, "Mapping between LPD and IPP Protocols", gives some advice 85 to implementers of gateways between IPP and LPD (Line Printer Daemon) 86 implementations. 88 Expires August 12, 1999 89 TABLE OF CONTENTS 91 1 Introduction.......................................................5 93 1.1 Conformance language............................................5 94 1.2 Other terminology...............................................5 96 2 Model and Semantics................................................5 98 2.1 Summary of Operation Attributes.................................5 99 2.2 Suggested Operation Processing Steps for IPP Objects (Issue 1.21)9 100 2.2.1 Suggested Operation Processing Steps for all Operations....10 101 2.2.1.1 Validate version number................................10 102 2.2.1.2 Validate operation identifier..........................11 103 2.2.1.3 Validate the request identifier........................11 104 2.2.1.4 Validate attribute group and attribute presence and order 105 11 106 2.2.1.5 Validate the values of the REQUIRED Operation attributes18 107 2.2.1.6 Validate the values of the OPTIONAL Operation attributes22 108 2.2.2 Suggested Additional Processing Steps for Operations that 109 Create/Validate Jobs and Add Documents...........................24 110 2.2.2.1 Default "ipp-attribute-fidelity" if not supplied.......24 111 2.2.2.2 Check that the Printer object is accepting jobs........24 112 2.2.2.3 Validate the values of the Job Template attributes.....24 113 2.2.3 Algorithm for job validation...............................25 114 2.2.3.1 Check for conflicting Job Template attributes values...30 115 2.2.3.2 Decide whether to REJECT the request...................30 116 2.2.3.3 For the Validate-Job operation, RETURN one of the success 117 status codes....................................................31 118 2.2.3.4 Create the Job object with attributes to support.......31 119 2.2.3.5 Return one of the success status codes.................33 120 2.2.3.6 Accept appended Document Content.......................33 121 2.2.3.7 Scheduling and Starting to Process the Job.............33 122 2.2.3.8 Completing the Job.....................................33 123 2.2.3.9 Destroying the Job after completion....................34 124 2.2.3.10 Interaction with "ipp-attribute-fidelity"..............34 125 2.3 Status codes returned by operation (Issue 1.50)................34 126 2.3.1 Printer Operations.........................................34 127 2.3.1.1 Print-Job..............................................34 128 2.3.1.2 Print-URI..............................................36 129 2.3.1.3 Validate-Job...........................................37 130 2.3.1.4 Create-Job.............................................37 131 2.3.1.5 Get-Printer-Attributes.................................37 132 2.3.1.6 Get-Jobs...............................................38 133 2.3.2 Job Operations.............................................38 134 2.3.2.1 Send-Document..........................................38 135 2.3.2.2 Send-URI...............................................39 136 2.3.2.3 Cancel-Job.............................................39 137 2.3.2.4 Get-Job-Attributes.....................................40 138 2.4 Validate-Job...................................................41 139 2.5 Case Sensitivity in URIs (issue 1.6)...........................41 140 2.6 Character Sets, natural languages, and internationalization....41 141 2.6.1 Character set code conversion support (Issue 1.5)..........41 142 2.6.2 What charset to return when an unsupported charset is 143 requested (Issue 1.19)?..........................................42 145 Expires August 12, 1999 146 2.6.3 Natural Language Override (NLO) (Issue 1.45)...............43 147 2.7 The "queued-job-count" Printer Description attribute...........44 148 2.7.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?........44 149 2.7.2 Is "queued-job-count" a good measure of how busy a printer is 150 (Issue 1.15)?....................................................45 151 2.8 Sending empty attribute groups (Issue 1.16)....................45 152 2.9 Returning unsupported attributes in Get-Xxxx responses (Issue 153 1.18)..............................................................45 154 2.10Returning job-state in Print-Job response (Issue 1.30).........46 155 2.11Flow controlling the data portion of a Print-Job request (Issue 156 1.22)..............................................................46 157 2.12Multi-valued attributes (Issue 1.31)...........................47 158 2.13Querying jobs with IPP that were submitted using other job 159 submission protocols (Issue 1.32)..................................47 160 2.14The 'none' value for empty sets (Issue 1.37)...................48 161 2.15Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 1.39)? 162 48 163 2.16The "multiple-document-handling" Job Template attribute and 164 support of multiple document jobs..................................48 166 3 Encoding and Transport............................................49 168 3.1 General Headers................................................50 169 3.2 Request Headers...............................................50 170 3.3 Response Headers...............................................52 171 3.4 Entity Headers................................................52 172 3.5 Optional support for HTTP/1.0..................................53 173 3.6 HTTP/1.1 Chunking..............................................53 174 3.6.1 Disabling IPP Server Response Chunking.....................53 175 3.6.2 Warning About the Support of Chunked Requests..............54 177 4 References........................................................54 179 4.1 Authors. Address...............................................55 181 5 Notices.................................Error! Bookmark not defined. 183 6 Change History....................................................56 185 6.1 Changes to produce the February 12, 1999 version from the January 186 8, 1999 version:...................................................57 187 6.2 Changes to produce the January 8, 1999 version from the December 188 6, 1998 version:...................................................57 189 6.3 Changes to produce the December 6, 1998 version from the November 190 16, 1998 version:..................................................57 192 Expires August 12, 1999 194 1 Introduction 196 This document contains information that supplements the IPP Model and 197 Semantics [IPP-MOD] and the IPP Transport and Encoding [IPP-PRO] 198 documents. As such this information is not part of the formal 199 specifications. Instead information is presented to help implementers 200 understand the specification, including some of the motivation for 201 decisions taken by the committee in developing the specification. Some 202 of the implementation considerations are intended to help implementers 203 design their client and/or IPP object implementations. If there are any 204 contradictions between this document and [IPP-MOD] or [IPP-PRO], those 205 documents take precedence over this document. 207 1.1 Conformance language 209 Usually, this document does not contain the terminology MUST, MUST NOT, 210 MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. However, 211 when those terms do appear in this document, their intent is to repeat 212 what the [IPP-MOD] and [IPP-PRO] documents require and allow, rather 213 than specifying additional conformance requirements. These terms are 214 defined in section 13 on conformance terminology in [IPP-MOD], most of 215 which is taken from RFC 2119 [RFC2119]. 217 Implementers should read section 13 in [IPP-MOD] in order to understand 218 these capitalized words. The words MUST, MUST NOT, and REQUIRED 219 indicate what implementations are required to support in a client or IPP 220 object in order to be conformant to [IPP-MOD] and [IPP-PRO]. MAY, NEED 221 NOT, and OPTIONAL indicate was is merely allowed as an implementer 222 option. The verbs SHOULD and SHOULD NOT indicate suggested behavior, 223 but which is not required or disallowed, respectively, in order to 224 conform to the specification. 226 1.2 Other terminology 228 The term "sender" refers to the client that sends a request or an IPP 229 object that returns a response. The term "receiver" refers to the IPP 230 object that receives a request and to a client that receives a response. 232 2 Model and Semantics 234 This section discusses various aspects of IPP/1.0 Model and Semantics 235 [IPP-MOD]. 237 2.1 Summary of Operation Attributes 239 Legend for the following table: 241 Expires August 12, 1999 242 R indicates a REQUIRED operation or attribute for an implementation 243 to support 245 O indicates an OPTIONAL operation or attribute for an 246 implementation to support 248 Table 1. Summary of operation attributes 250 Job Operations 252 Requests Respo 253 nses 255 Operation Send- Send- Cancel Get- All 256 Attributes Documen URI -Job Job- Opera 257 t (O) Attribu tions 258 (O) tes 260 Operation parameters--REQUIRED to be supplied by the sender 262 operation-id R R R R 264 status-code R 266 request-id R R R R R 268 version-number R R R R R 270 Operation attributes.REQUIRED to be supplied by the sender 272 attributes- R R R R R 273 charset 275 attributes- R R R R R 276 natural-language 278 document-uri R 280 job-id* R R R R 282 job-uri* R R R R 284 last-document R R 286 printer-uri R R R R 288 Operation attributes.RECOMMENDED to be supplied by the 289 sender 291 job-name 293 requesting-user- R R R R 294 name 296 Expires August 12, 1999 297 Printer Operations 299 Requests Respon 300 ses 302 Operation Print- Pri Crea Get- Get- All 303 Attributes Job, nt- te- Printe Jobs Operat 304 Valida URI Job r- ions 305 te-Job (O) (O) Attrib 306 utes 308 Operation attributes.OPTIONAL to be supplied by the sender 310 status-message O 312 compression O O 314 document-format R R O 316 document-name O O 318 document-natural- O O 319 language 321 ipp-attribute- R R R 322 fidelity 324 job-impressions O O O 326 job-k-octets O O O 328 job-media-sheets O O O 330 limit R 332 message 334 my-jobs R 336 requested- R R 337 attributes 339 which-jobs R 341 * "job-id" is REQUIRED only if used together with 342 "printer-uri" to identify the target job; otherwise, "job- 343 uri" is REQUIRED. 345 Expires August 12, 1999 347 Table 2. Summary of operation attributes 349 Printer Operations 351 Requests Respo 352 nses 354 Operation Print- Pri Crea Get- Get- All 355 Attributes Job, nt- te- Printer- Jobs Opera 356 Validate URI Job Attribut tions 357 -Job (O) (O) es 359 Operation parameters--REQUIRED to be supplied by the sender 361 operation-id R R R R R 363 status-code R 365 request-id R R R R R R 367 version-number R R R R R R 369 Operation attributes.REQUIRED to be supplied by the sender 371 attributes-charset R R R R R R 373 attributes- R R R R R R 374 natural-language 376 document-uri R 378 job-id* 380 job-uri* 382 last-document 384 printer-uri R R R R R 386 Operation attributes.RECOMMENDED to be supplied by the sender 388 job-name R R R 390 requesting-user- R R R R R 391 name 393 Expires August 12, 1999 394 Job Operations 396 Requests Respon 397 ses 399 Operation Attributes Send- Send- Cance Get- All 400 Documen URI l-Job Job- Operat 401 t (O) Attrib ions 402 (O) utes 404 Operation attributes.OPTIONAL to be supplied by the sender 406 status-message O 408 compression O O 410 document-format R R 412 document-name O O 414 document-natural- O O 415 language 417 ipp-attribute- 418 fidelity 420 job-impressions 422 job-k-octets 424 job-media-sheets 426 limit 428 message O 430 my-jobs 432 requested-attributes R 434 which-jobs 436 * "job-id" is REQUIRED only if used together with "printer- 437 uri" to identify the target job; otherwise, "job-uri" is 438 REQUIRED. 440 2.2 Suggested Operation Processing Steps for IPP Objects (Issue 1.21) 442 This section suggests the steps and error checks that an IPP object MAY 443 perform when processing requests and returning responses. An IPP object 444 MAY perform some or all of the error checks. However, some 445 implementations MAY choose to be more forgiving than the error checks 446 shown here, in order to be able to accept requests from non-conforming 447 clients. Not performing all of these error checks is a so-called 448 "forgiving" implementation. On the other hand, clients that 449 successfully submit requests to IPP objects that do perform all the 450 error checks will be more likely to be able to interoperate with other 451 IPP object implementations. Thus an implementer of an IPP object needs 452 to decide whether to be a "forgiving" or a "strict" implementation. 453 Therefore, the error status codes returned may differ between 454 implementations. Consequentially, client SHOULD NOT expect exactly the 455 error code processing described in this section. 457 When an IPP object receives a request, the IPP object either accepts or 458 rejects the request. In order to determine whether or not to accept or 459 reject the request, the IPP object SHOULD execute the following steps. 461 Expires August 12, 1999 462 The order of the steps may be rearranged and/or combined, including 463 making one or multiple passes over the request. 465 A client MUST supply requests that would pass all of the error checks 466 indicated here in order to be a conforming client. Therefore, a client 467 SHOULD supply requests that are conforming, in order to avoid being 468 rejected by some IPP object implementations and/or risking different 469 semantics by different implementations of forgiving implementations. 470 For example, a forgiving implementation that accepts multiple 471 occurrences of the same attribute, rather than rejecting the request 472 might use the first occurrences, while another might use the last 473 occurrence. Thus such a non-conforming client would get different 474 results from the two forgiving implementations. 476 In the following, processing continues step by step until a "RETURNS the 477 xxx status code ." statement is encountered. Error returns are 478 indicated by the verb: "REJECTS". Since clients have difficulty getting 479 the status code before sending all of the document data in a Print-Job 480 request, clients SHOULD use the Validate-Job operation before sending 481 large documents to be printed, in order to validate whether the IPP 482 Printer will accept the job or not. 484 It is assumed that security authentication and authorization has already 485 taken place at a lower layer. 487 2.2.1Suggested Operation Processing Steps for all Operations 489 This section is intended to apply to all operations. The next section 490 contains the additional steps for the Print-Job, Validate-Job, Print- 491 URI, Create-Job, Send-Document, and Send-URI operations that create 492 jobs, adds documents, and validates jobs. 494 2.2.1.1 Validate version number 496 Every request and every response contains the "version-number" 497 attribute. The value of this attribute is the major and minor version 498 number of the syntax and semantics that the client and IPP object is 499 using, respectively. The "version-number" attribute remains in a fixed 500 position across all future versions so that all clients and IPP object 501 that support future versions can determine which version is being used. 502 The IPP object checks to see if the major version number supplied in the 503 request is supported. If not, the Printer object REJECTS the request 504 and RETURNS the 'server-error-version-not-supported' status code in the 505 response. The IPP object returns in the "version-number" response 506 attribute the major and minor version for the error response. Thus the 507 client can learn at least one major and minor version that the IPP 508 object supports. The IPP object is encouraged to return the closest 509 version number to the one supplied by the client. 511 The checking of the minor version number is implementation dependent, 512 however if the client supplied minor version is explicitly supported, 513 the IPP object MUST respond using that identical minor version number. 514 If the requested minor version is not supported (the requested minor 516 Expires August 12, 1999 517 version is either higher or lower) than a supported minor version, the 518 IPP object SHOULD return the closest supported minor version. 520 2.2.1.2 Validate operation identifier 522 The Printer object checks to see if the "operation-id" attribute 523 supplied by the client is supported as indicated in the Printer object's 524 "operations-supported" attribute. If not, the Printer REJECTS the 525 request and returns the 'server-error-operation-not-supported' status 526 code in the response. 528 2.2.1.3 Validate the request identifier 530 The Printer object SHOULD NOT check to see if the "request-id" attribute 531 supplied by the client is in range: between 1 and 2**31 - 1 (inclusive), 532 but copies all 32 bits. 534 Note: The "version-number", "operation-id", and the "request-id" 535 parameters are in fixed octet positions in the IPP/1.0 encoding. The 536 "version-number" parameter will be the same fixed octet position in all 537 versions of the protocol. These fields are validated before proceeding 538 with the rest of the validation. 540 2.2.1.4 Validate attribute group and attribute presence and order 542 The order of the following validation steps depends on implementation. 544 2.2.1.4.1 Validate the presence and order of attribute groups 546 Client requests and IPP object responses contain attribute groups that 547 Section 3 requires to be present and in a specified order. An IPP 548 object verifies that the attribute groups are present and in the correct 549 order in requests supplied by clients (attribute groups without an * in 550 the following tables). 552 If an IPP object receives a request with (1) required attribute groups 553 missing, or (2) the attributes groups are out of order, or (3) the 554 groups are repeated, the IPP object REJECTS the request and RETURNS the 555 'client-error-bad-request' status code. For example, it is an error for 556 the Job Template Attributes group to occur before the Operation 557 Attributes group, for the Operation Attributes group to be omitted, or 558 for an attribute group to occur more than once, except in the Get-Jobs 559 response. 561 Since this kind of attribute group error is most likely to be an error 562 detected by a client developer rather than by a customer, the IPP object 563 NEED NOT return an indication of which attribute group was in error in 564 either the Unsupported Attributes group or the Status Message. Also, 565 the IPP object NEED NOT find all attribute group errors before returning 566 this error. 568 Expires August 12, 1999 569 2.2.1.4.2 Ignore unknown attribute groups in the expected position 571 Future attribute groups may be added to the specification at the end of 572 requests just before the Document Content and at the end of response, 573 except for the Get-Jobs response, where it maybe there or before the 574 first job attributes returned. If an IPP object receives an unknown 575 attribute group in these positions, it ignores the entire group, rather 576 than returning an error, since that group may be a new group in a later 577 minor version of the protocol that can be ignored. (If the new 578 attribute group cannot be ignored without confusing the client, the 579 major version number would have been increased in the protocol document 580 and in the request). If the unknown group occurs in a different 581 position, the IPP object REJECTS the request and RETURNS the 'client- 582 error-bad-request' status code. 584 Clients also ignore unknown attribute groups returned in a response. 586 Note: By validating that requests are in the proper form, IPP objects 587 force clients to use the proper form which, in turn, increases the 588 chances that customers will be able to use such clients from multiple 589 vendors with IPP objects from other vendors. 591 2.2.1.4.3 Validate the presence of a single occurrence of required 592 Operation attributes 594 Client requests and IPP object responses contain Operation attributes 595 that [IPP-MOD] Section 3 requires to be present. Attributes within a 596 group may be in any order, except for the ordering of target, charset, 597 and natural languages attributes. These attributes MUST be first, and 598 MUST be supplied in the following order: charset, natural language, and 599 then target. An IPP object verifies that the attributes that Section 4 600 requires to be supplied by the client have been supplied in the request 601 (attributes without an * in the following tables). An asterisk (*) 602 indicates groups and Operation attributes that the client may omit in a 603 request or an IPP object may omit in a response. 605 If an IPP object receives a request with required attributes missing or 606 repeated from a group or in the wrong position, the behavior of the IPP 607 object is IMPLEMENTATION DEPENDENT. Some of the possible 608 implementations are: 610 1.REJECTS the request and RETURNS the 'client-error-bad-request' 611 status code 613 2.accepts the request and uses the first occurrence of the 614 attribute no matter where it is 616 3.accepts the request and uses the last occurrence of the 617 attribute no matter where it is 619 4.accept the request and assume some default value for the missing 620 attribute 622 Expires August 12, 1999 624 Therefore, client MUST send conforming requests, if they want to receive 625 the same behavior from all IPP object implementations. For example, it 626 is an error for the "attributes-charset" or "attributes-natural- 627 language" attribute to be omitted in any operation request, or for an 628 Operation attribute to be supplied in a Job Template group or a Job 629 Template attribute to be supplied in an Operation Attribute group in a 630 create request. It is also an error to supply the "attributes-charset" 631 attribute twice. 633 Since these kinds of attribute errors are most likely to be detected by 634 a client developer rather than by a customer, the IPP object NEED NOT 635 return an indication of which attribute was in error in either the 636 Unsupported Attributes group or the Status Message. Also, the IPP 637 object NEED NOT find all attribute errors before returning this error. 639 The following tables list all the attributes for all the operations by 640 attribute group in each request and each response. The order of the 641 groups is the order that the client supplies the groups as specified in 642 [IPP-MOD] Section 3. The order of the attributes within a group is 643 arbitrary, except as noted for some of the special operation attributes 644 (charset, natural language, and target). The tables below use the 645 following notation: 647 R indicates a REQUIRED attribute that an IPP object MUST support 648 O indicates an OPTIONAL attribute that an IPP object NEED NOT 649 support 650 * indicates that a client MAY omit the attribute in a request 651 and that an IPP object MAY omit the attribute in a 652 response. The absence of an * means that a client MUST 653 supply the attribute in a request and an IPP object MUST 654 supply the attribute in a response. 656 Operation Requests 658 The tables below show the attributes in their proper attribute groups 659 for operation requests: 661 Note: All operation requests contain "version-number", "operation-id", 662 and "request-id" parameters. 664 Expires August 12, 1999 665 Print-Job Request: 666 Group 1: Operation Attributes (R) 667 attributes-charset (R) 668 attributes-natural-language (R) 669 printer-uri (R) 670 requesting-user-name (R*) 671 job-name (R*) 672 ipp-attribute-fidelity (R*) 673 document-name (R*) 674 document-format (R*) 675 document-natural-language (O*) 676 compression (O*) 677 job-k-octets (O*) 678 job-impressions (O*) 679 job-media-sheets (O*) 680 Group 2: Job Template Attributes (R*) 681 (O*) 682 (see [IPP-MOD] Section 4.2) 683 Group 3: Document Content (R) 684 686 Validate-Job Request: 687 Group 1: Operation Attributes (R) 688 attributes-charset (R) 689 attributes-natural-language (R) 690 printer-uri (R) 691 requesting-user-name (R*) 692 job-name (R*) 693 ipp-attribute-fidelity (R*) 694 document-name (R*) 695 document-format (R*) 696 document-natural-language (O*) 697 compression (O*) 698 job-k-octets (O*) 699 job-impressions (O*) 700 job-media-sheets (O*) 701 Group 2: Job Template Attributes (R*) 702 (O*) 703 (see [IPP-MOD] Section 4.2) 705 Create-Job Request: 706 Group 1: Operation Attributes (R) 707 attributes-charset (R) 708 attributes-natural-language (R) 709 printer-uri (R) 710 requesting-user-name (R*) 711 job-name (R*) 712 ipp-attribute-fidelity (R*) 713 job-k-octets (O*) 714 job-impressions (O*) 715 job-media-sheets (O*) 716 Group 2: Job Template Attributes (R*) 717 (O*) (see 718 (see [IPP-MOD] Section 4.2) 720 Expires August 12, 1999 722 Print-URI Request: 723 Group 1: Operation Attributes (R) 724 attributes-charset (R) 725 attributes-natural-language (R) 726 printer-uri (R) 727 document-uri (R) 728 requesting-user-name (R*) 729 job-name (R*) 730 ipp-attribute-fidelity (R*) 731 document-name (R*) 732 document-format (R*) 733 document-natural-language (O*) 734 compression (O*) 735 job-k-octets (O*) 736 job-impressions (O*) 737 job-media-sheets (O*) 738 Group 2: Job Template Attributes (R*) 739 (O*) (see 740 (see [IPP-MOD] Section 4.2) 742 Send-Document Request: 743 Group 1: Operation Attributes (R) 744 attributes-charset (R) 745 attributes-natural-language (R) 746 (printer-uri & job-id) | job-uri (R) 747 last-document (R) 748 requesting-user-name (R*) 749 document-name (R*) 750 document-format (R*) 751 document-natural-language (O*) 752 compression (O*) 753 Group 2: Document Content (R*) 754 756 Send-URI Request: 757 Group 1: Operation Attributes (R) 758 attributes-charset (R) 759 attributes-natural-language (R) 760 (printer-uri & job-id) | job-uri (R) 761 last-document (R) 762 document-uri (R) 763 requesting-user-name (R*) 764 document-name (R*) 765 document-format (R*) 766 document-natural-language (O*) 767 compression (O*) 769 Cancel-Job Request: 770 Group 1: Operation Attributes (R) 771 attributes-charset (R) 772 attributes-natural-language (R) 773 (printer-uri & job-id) | job-uri (R) 774 requesting-user-name (R*) 776 Expires August 12, 1999 777 message (O*) 779 Get-Printer-Attributes Request: 780 Group 1: Operation Attributes (R) 781 attributes-charset (R) 782 attributes-natural-language (R) 783 printer-uri (R) 784 requesting-user-name (R*) 785 requested-attributes (R*) 786 document-format (R*) 788 Get-Job-Attributes Request: 789 Group 1: Operation Attributes (R) 790 attributes-charset (R) 791 attributes-natural-language (R) 792 (printer-uri & job-id) | job-uri (R) 793 requesting-user-name (R*) 794 requested-attributes (R*) 796 Get-Jobs Request: 797 Group 1: Operation Attributes (R) 798 attributes-charset (R) 799 attributes-natural-language (R) 800 printer-uri (R) 801 requesting-user-name (R*) 802 limit (R*) 803 requested-attributes (R*) 804 which-jobs (R*) 805 my-jobs (R*) 807 Operation Responses 809 The tables below show the response attributes in their proper attribute 810 groups for responses. 812 Note: All operation responses contain "version-number", "status-code", 813 and "request-id" parameters. 815 Expires August 12, 1999 816 Print-Job Response: 817 Print-URI Response: 818 Create-Job Response: 819 Send-Document Response: 820 Send-URI Response: 821 Group 1: Operation Attributes (R) 822 attributes-charset (R) 823 attributes-natural-language (R) 824 status-message (O*) 825 Group 2: Unsupported Attributes (R*) (see Note 3) 826 (R*) 827 Group 3: Job Object Attributes(R*) (see Note 2) 828 job-uri (R) 829 job-id (R) 830 job-state (R) 831 job-state-reasons (O*) 832 job-state-message (O*) 833 number-of-intervening-jobs (O*) 835 Validate-Job Response: 836 Cancel-Job Response: 837 Group 1: Operation Attributes (R) 838 attributes-charset (R) 839 attributes-natural-language (R) 840 status-message (O*) 841 Group 2: Unsupported Attributes (R*) (see Note 3) 842 (R*) 844 Note 2 - the Job Object Attributes and Printer Object Attributes are 845 returned only if the IPP object returns one of the success status codes. 847 Note 3 - the Unsupported Attributes Group is present only if the client 848 included some Operation and/or Job Template attributes or values that 849 the Printer doesn't support whether a success or an error return. 851 Get-Printer-Attributes Response: 852 Group 1: Operation Attributes (R) 853 attributes-charset (R) 854 attributes-natural-language (R) 855 status-message (O*) 856 Group 2: Unsupported Attributes (R*) (see Note 4) 857 (R*) 858 Group 3: Printer Object Attributes(R*) (see Note 2) 859 (R*) 861 Note 4 - the Unsupported Attributes Group is present only if the client 862 included some Operation attributes that the Printer doesn't support 863 whether a success or an error return. 865 Expires August 12, 1999 866 Get-Job-Attributes Response: 867 Group 1: Operation Attributes (R) 868 attributes-charset (R) 869 attributes-natural-language (R) 870 status-message (O*) 871 Group 2: Unsupported Attributes (R*) (see Note 4) 872 (R*) 873 Group 3: Job Object Attributes(R*) (see Note 2) 874 (R*) 876 Get-Jobs Response: 877 Group 1: Operation Attributes (R) 878 attributes-charset (R) 879 attributes-natural-language (R) 880 status-message (O*) 881 Group 2: Unsupported Attributes (R*) (see Note 4) 882 (R*) 883 Group 3: Job Object Attributes(R*) (see Note 2, 5) 884 (R*) 886 Note 5: for the Get-Jobs operation the response contains a separate Job 887 Object Attributes group 3 to N containing requested-attributes for each 888 job object in the response. 890 2.2.1.5 Validate the values of the REQUIRED Operation attributes 892 An IPP object validates the values supplied by the client of the 893 REQUIRED Operation attribute that the IPP object MUST support. The next 894 section specifies the validation of the values of the OPTIONAL Operation 895 attributes that IPP objects MAY support. 897 The IPP object performs the following syntactic validation checks of 898 each Operation attribute value: 900 a)that the length of each Operation attribute value is correct for 901 the attribute syntax tag supplied by the client according to 902 [IPP-MOD] Section 4.1, 904 b)that the attribute syntax tag is correct for that Operation 905 attribute according to [IPP-MOD] Section 3, 907 c)that the value is in the range specified for that Operation 908 attribute according to [IPP-MOD] Section 3, 910 d)that multiple values are supplied by the client only for 911 operation attributes that are multi-valued, i.e., that are 912 1setOf X according to [IPP-MOD] Section 3. 914 If any of these checks fail, the IPP object REJECTS the request and 915 RETURNS the 'client-error-bad-request' or the 'client-error-request- 916 value-too-long' status code. Since such an error is most likely to be 917 an error detected by a client developer, rather than by an end-user, the 919 Expires August 12, 1999 920 IPP object NEED NOT return an indication of which attribute had the 921 error in either the Unsupported Attributes Group or the Status Message. 922 The description for each of these syntactic checks is explicitly 923 expressed in the first IF statement in the following table. 925 In addition, the IPP object checks each Operation attribute value 926 against some Printer object attribute or some hard-coded value if there 927 is no "xxx-supported" Printer object attribute defined. If its value is 928 not among those supported or is not in the range supported, then the IPP 929 object REJECTS the request and RETURNS the error status code indicated 930 in the table by the second IF statement. If the value of the Printer 931 object's "xxx-supported" attribute is 'no-value' (because the system 932 administrator hasn't configured a value), the check always fails. 934 ----------------------------------------------- 936 attributes-charset (charset) 938 IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client- 939 error-request-bad-request'. 940 IF the value length is greater than 63 octets, REJECT/RETURN 'client- 941 error-request-value-too-long'. 942 IF NOT in the Printer object's "charset-supported" attribute, 943 REJECT/RETURN "client-error-charset-not-supported". 945 attributes-natural-language(naturalLanguage) 947 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 948 'client-error-request-bad-request'. 949 IF the value length is greater than 63 octets, REJECT/RETURN 'client- 950 error-request-value-too-long'. 951 ACCEPT the request even if not a member of the set in the Printer 952 object's "generated-natural-language-supported" attribute. If the 953 supplied value is not a member of the Printer object's "generated- 954 natural-language-supported" attribute, use the Printer object's 955 "natural-language-configured" value. 957 requesting-user-name 959 IF NOT a single 'name' value, REJECT/RETURN 'client-error-request- 960 bad-request'. 961 IF the value length is greater than 255 octets, REJECT/RETURN 962 'client-error-request-value-too-long'. 963 IF the IPP object can obtain a better authenticated name, use it 964 instead. 966 job-name(name) 968 IF NOT a single 'name' value, REJECT/RETURN 'client-error-request- 969 bad-request'. 970 IF the value length is greater than 255 octets, REJECT/RETURN 971 'client-error-request-value-too-long'. 972 IF NOT supplied by the client, the Printer object creates a name from 973 the document-name or document-uri. 975 Expires August 12, 1999 977 document-name (name) 979 IF NOT a single 'name' value, REJECT/RETURN 'client-error-request- 980 bad-request'. 981 IF the value length is greater than 255 octets, REJECT/RETURN 982 'client-error-request-value-too-long'. 984 ipp-attribute-fidelity (boolean) 986 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, 987 REJECT/RETURN 'client-error-bad-request'. 988 IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client- 989 error-request-value-too-long' 990 IF NOT supplied by the client, the IPP object assumes the value 991 'false'. 993 document-format (mimeMediaType) 995 IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN 996 'client-error-request-bad-request'. 997 IF the value length is greater than 255 octets, REJECT/RETURN 998 'client-error-request-value-too-long'. 999 IF NOT in the Printer object's "document-format-supported" attribute, 1000 REJECT/RETURN 'client-error-document-format-not-supported' 1001 IF NOT supplied by the client, the IPP object assumes the value of 1002 the Printer object's "document-format-default" attribute. 1004 document-uri (uri) 1006 IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-error- 1007 request-bad-request'. 1008 IF the value length is greater than 1023 octets, REJECT/RETURN 1009 'client-error-request-value-too-long'. 1010 IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad- 1011 request'. 1012 IF scheme is NOT in the Printer object's "reference-uri-schemes- 1013 supported" attribute, REJECT/RETURN 'client-error-uri-scheme-not- 1014 supported'. 1015 The Printer object MAY check to see if the document exists and is 1016 accessible. If the document is not found or is not accessible, 1017 REJECT/RETURN 'client-error-not found'. 1019 last-document (boolean) 1021 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, 1022 REJECT/RETURN 'client-error-bad-request'. 1023 IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client- 1024 error-request-value-too-long' 1026 job-id (integer(1:MAX)) 1028 IF NOT an single 'integer' value equal to 4 octets AND in the range 1 1029 to MAX, REJECT/RETURN 'client-error-bad-request'. 1031 Expires August 12, 1999 1033 IF NOT a job-id of an existing Job object, REJECT/RETURN 'client- 1034 error-not-found' or 'client-error-gone' status code, if keep track 1035 of recently deleted jobs. 1037 requested-attributes (1setOf keyword) 1039 IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error- 1040 request-bad-request'. 1041 IF the value length is greater than 255 octets, REJECT/RETURN 1042 'client-error-request-value-too-long'. 1043 Ignore unsupported values which are the keyword names of unsupported 1044 attributes. Don't bother to copy such requested (unsupported) 1045 attributes to the Unsupported Attribute response group since the 1046 response will not return them. 1048 which-jobs (type2 keyword) 1050 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-request- 1051 bad-request'. 1052 IF the value length is greater than 255 octets, REJECT/RETURN 1053 'client-error-request-value-too-long'. 1054 IF NEITHER 'completed' NOR 'not-completed', copy the attribute and 1055 the unsupported value to the Unsupported Attributes response group 1056 and REJECT/RETURN 'client-error-attributes-or-values-not- 1057 supported'. 1058 Note: a Printer still supports the 'completed' value even if it keeps 1059 no completed/canceled/aborted jobs: by returning no jobs when so 1060 queried. 1061 IF NOT supplied by the client, the IPP object assumes the 'not- 1062 completed' value. 1064 my-jobs (boolean) 1066 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, 1067 REJECT/RETURN 'client-error-bad-request'. 1068 IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client- 1069 error-request-value-too-long' 1070 IF NOT supplied by the client, the IPP object assumes the 'false' 1071 value. 1073 limit (integer(1:MAX)) 1075 IF NOT a single 'integer' value equal to 4 octets AND in the range 1 1076 to MAX, REJECT/RETURN 'client-error-bad-request'. 1077 IF NOT supplied by the client, the IPP object returns all jobs, no 1078 matter how many. 1080 ----------------------------------------------- 1082 Expires August 12, 1999 1083 2.2.1.6 Validate the values of the OPTIONAL Operation attributes 1085 OPTIONAL Operation attributes are those that an IPP object MAY or MAY 1086 NOT support. An IPP object validates the values of the OPTIONAL 1087 attributes supplied by the client. The IPP object performs the same 1088 syntactic validation checks for each OPTIONAL attribute value as in 1089 Section 2.2.1.5. As in Section 2.2.1.5, if any fail, the IPP object 1090 REJECTS the request and RETURNS the 'client-error-bad-request' or the 1091 'client-error-request-value-too-long' status code. 1093 In addition, the IPP object checks each Operation attribute value 1094 against some Printer attribute or some hard-coded value if there is no 1095 "xxx-supported" Printer attribute defined. If its value is not among 1096 those supported or is not in the range supported, then the IPP object 1097 REJECTS the request and RETURNS the error status code indicated in the 1098 table. If the value of the Printer object's "xxx-supported" attribute 1099 is 'no-value' (because the system administrator hasn't configured a 1100 value), the check always fails. 1102 If the IPP object doesn't recognize/support an attribute, the IPP object 1103 treats the attribute as an unknown or unsupported attribute (see the 1104 last row in the table below). 1106 ----------------------------------------------- 1108 document-natural-language (naturalLanguage) 1110 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN 1111 'client-error-request-bad-request'. 1112 IF the value length is greater than 63 octets, REJECT/RETURN 'client- 1113 error-request-value-too-long'. 1114 IF NOT a value that the Printer object supports in document formats, 1115 (no corresponding "xxx-supported" Printer attribute), REJECT/RETURN 1116 'client-error-natural-language-not-supported'. 1118 compression (type3 keyword) 1120 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-request- 1121 bad-request'. 1122 IF the value length is greater than 255 octets, REJECT/RETURN 1123 'client-error-request-value-too-long'. 1124 IF NOT in the Printer object's "compression-supported" attribute, 1125 copy the attribute and the unsupported value to the Unsupported 1126 Attributes response group and REJECT/RETURN 'client-error- 1127 attributes-or-values-not-supported'. 1129 job-k-octets (integer(0:MAX)) 1131 IF NOT a single 'integer' value equal to 4 octets, 1132 REJECT/RETURN 'client-error-bad-request'. 1133 IF NOT in the range of the Printer object's "job-k-octets-supported" 1134 attribute, copy the attribute and the unsupported value to the 1135 Unsupported Attributes response group and REJECT/RETURN 'client- 1136 error-attributes-or-values-not-supported'. 1138 Expires August 12, 1999 1140 job-impressions (integer(0:MAX)) 1142 IF NOT a single 'integer' value equal to 4 octets, 1143 REJECT/RETURN 'client-error-bad-request'. 1144 IF NOT in the range of the Printer object's "job-impressions- 1145 supported" attribute, copy the attribute and the unsupported value 1146 to the Unsupported Attributes response group and REJECT/RETURN 1147 'client-error-attributes-or-values-not-supported'. 1149 job-media-sheets (integer(0:MAX)) 1151 IF NOT a single 'integer' value equal to 4 octets, 1152 REJECT/RETURN 'client-error-bad-request'. 1153 IF NOT in the range of the Printer object's "job-media-sheets- 1154 supported" attribute, copy the attribute and the unsupported value 1155 to the Unsupported Attributes response group and REJECT/RETURN 1156 'client-error-attributes-or-values-not-supported'. 1158 message (text(127)) 1160 IF NOT a single 'text' value, REJECT/RETURN 'client-error-request- 1161 bad-request'. 1162 IF the value length is greater than 127 octets, 1163 REJECT/RETURN 'client-error-request-value-too-long'. 1165 unknown or unsupported attribute 1167 IF the attribute syntax supplied by the client is supported but the 1168 length is not legal for that attribute syntax, REJECT/RETURN 1169 'client-error-request-value-too-long'. 1170 ELSE copy the attribute and value to the Unsupported Attributes 1171 response group and change the attribute value to the "out-of-band" 1172 'unsupported' value, but otherwise ignore the attribute. 1174 Note: Future Operation attributes may be added to the protocol 1175 specification that may occur anywhere in the specified group. When 1176 the operation is otherwise successful, the IPP object returns the 1177 'successful-ok-ignored-or-substituted-attributes' status code. 1178 Ignoring unsupported Operation attributes in all operations is 1179 analogous to the handling of unsupported Job Template attributes in 1180 the create and Validate-Job operations when the client supplies the 1181 "ipp-attribute-fidelity" Operation attribute with the 'false' value. 1182 This last rule is so that we can add OPTIONAL Operation attributes to 1183 future versions of IPP so that older clients can inter-work with new 1184 IPP objects and newer clients can inter-work with older IPP objects. 1185 (If the new attribute cannot be ignored without performing 1186 unexpectedly, the major version number would have been increased in 1187 the protocol document and in the request). This rule for Operation 1188 attributes is independent of the value of the "ipp-attribute- 1189 fidelity" attribute. For example, if an IPP object doesn't support 1190 the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-k- 1191 octets" as an unknown attribute and only checks the length for the 1192 'integer' attribute syntax supplied by the client. If it is not four 1194 Expires August 12, 1999 1195 octets, the IPP object REJECTS the request and RETURNS the 'client- 1196 error-bad-request' status code, else the IPP object copies the 1197 attribute to the Unsupported Attribute response group, setting the 1198 value to the "out-of-band" 'unsupported' value, but otherwise ignores 1199 the attribute. 1201 2.2.2Suggested Additional Processing Steps for Operations that 1202 Create/Validate Jobs and Add Documents 1204 This section in combination with the previous section recommends the 1205 processing steps for the Print-Job, Validate-Job, Print-URI, Create-Job, 1206 Send-Document, and Send-URI operations that IPP objects SHOULD use. 1207 These are the operations that create jobs, validate a Print-Job request, 1208 and add documents to a job. 1210 2.2.2.1 Default "ipp-attribute-fidelity" if not supplied 1212 The Printer object checks to see if the client supplied an "ipp- 1213 attribute-fidelity" Operation attribute. If the attribute is not 1214 supplied by the client, the IPP object assumes that the value is 1215 'false'. 1217 2.2.2.2 Check that the Printer object is accepting jobs 1219 If the value of the Printer object's "printer-is-accepting-jobs" is 1220 'false', the Printer object REJECTS the request and RETURNS the 'server- 1221 error-not-accepting-jobs' status code. 1223 2.2.2.3 Validate the values of the Job Template attributes 1225 An IPP object validates the values of all Job Template attribute 1226 supplied by the client. The IPP object performs the analogous syntactic 1227 validation checks of each Job Template attribute value that it performs 1228 for Operation attributes (see Section 2.2.1.5.): 1230 a)that the length of each value is correct for the attribute 1231 syntax tag supplied by the client according to [IPP-MOD] Section 1232 4.1. 1234 b)that the attribute syntax tag is correct for that attribute 1235 according to [IPP-MOD] Sections 4.2 to 4.4. 1237 c)that multiple values are supplied only for multi-valued 1238 attributes, i.e., that are 1setOf X according to [IPP-MOD] 1239 Sections 4.2 to 4.4. 1241 As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP 1242 object REJECTS the request and RETURNS the 'client-error-bad-request' or 1243 'client-error-request-value-too-long' status code as appropriate, 1244 independent of the value of the "ipp-attribute-fidelity". Since such an 1245 error is most likely to be an error detected by a client developer, 1246 rather than by an end-user, the IPP object NEED NOT return an indication 1248 Expires August 12, 1999 1249 of which attribute had the error in either the Unsupported Attributes 1250 Group or the Status Message. The description for each of these 1251 syntactic checks is explicitly expressed in the first IF statement in 1252 the following table. 1254 Each Job Template attribute MUST occur no more than once. If an IPP 1255 Printer receives a create request with multiple occurrences of a Job 1256 Template attribute, it MAY: 1258 1.reject the operation and return the 'client-error-bad syntax' 1259 error status code 1261 2.accept the operation and use the first occurrence of the 1262 attribute 1264 3.accept the operation and use the last occurrence of the 1265 attribute 1267 depending on implementation. Therefore, clients MUST NOT supply 1268 multiple occurrences of the same Job Template attribute in the Job 1269 Attributes group in the request. 1271 2.2.3Algorithm for job validation 1273 The process of validating a Job-Template attribute "xxx" against a 1274 Printer attribute "xxx-supported" can use the following validation 1275 algorithm (see section 3.2.1.2 in [ipp-mod]). 1277 To validate the value U of Job-Template attribute "xxx" against the 1278 value V of Printer "xxx-supported", perform the following algorithm: 1280 1.If U is multi-valued, validate each value X of U by performing 1281 the algorithm in Table 3 with each value X. Each validation is 1282 separate from the standpoint of returning unsupported values. 1284 Example: If U is "finishings" that the client supplies with 1285 'staple', 'bind' values, then X takes on the successive values: 1286 'staple', then 'bind' 1288 2.If V is multi-valued, validate X against each Z of V by 1289 performing the algorithm in Table 3 with each value Z. If a 1290 value Z validates, the validation for the attribute value X 1291 succeeds. If it fails, the algorithm is applied to the next 1292 value Z of V. If there are no more values Z of V, validation 1293 fails. 1295 Example" If V is "sides-supported" with values: 'one-sided', 1296 'two-sided-long', and 'two-sided-short', then Z takes on the 1297 successive values: 'one-sided', 'two-sided-long', and 'two- 1298 sided-short'. If the client supplies "sides" with 'two-sided- 1299 long', the first comparison fails ('one-sided' is not equal to 1300 'two-sided-long'), the second comparison succeeds ('two-sided- 1302 Expires August 12, 1999 1303 long' is equal to 'two-sided-long"), and the third comparison 1304 ('two-sided-short' with 'two-sided-long') is not even performed. 1306 3.If both U and V are single-valued, let X be U and Z be V and use 1307 the validation rules in Table 3. 1309 Table 3 - Rules for validating single values X against Z 1311 attribute attribute validated if: 1312 syntax of X syntax of Z 1314 integer rangeOfInteger X is within the range of 1315 Z 1317 uri uriScheme the uri scheme in X is 1318 equal to Z 1320 any boolean the value of Z is TRUE 1322 any any X and Z are of the same 1323 type and are equal. 1325 If the value of the Printer object's "xxx-supported" attribute is 'no- 1326 value' (because the system administrator hasn't configured a value), the 1327 check always fails. If the check fails, the IPP object copies the 1328 attribute to the Unsupported Attributes response group with its 1329 unsupported value. If the attribute contains more than one value, each 1330 value is checked and each unsupported value is separately copied, while 1331 supported values are not copied. If an IPP object doesn't 1332 recognize/support a Job Template attribute, i.e., there is no 1333 corresponding Printer object "xxx-supported" attribute, the IPP object 1334 treats the attribute as an unknown or unsupported attribute (see the 1335 last row in the table below). 1337 If some Job Template attributes are supported for some document formats 1338 and not for others or the values are different for different document 1339 formats, the IPP object SHOULD take that into account in this validation 1340 using the value of the "document-format" supplied by the client (or 1341 defaulted to the value of the Printer's "document-format-default" 1342 attribute, if not supplied by the client). For example, if "number-up" 1343 is supported for the 'text/plain' document format, but not for the 1344 'application/postscript' document format, the check SHOULD (though it 1345 NEED NOT) depend on the value of the "document-format" operation 1346 attribute. See "document-format" in [IPP-MOD] section 3.2.1.1 and 1347 3.2.5.1. 1349 Note: whether the request is accepted or rejected is determined by the 1350 value of the "ipp-attribute-fidelity" attribute in a subsequent step, so 1351 that all Job Template attribute supplied are examined and all 1352 unsupported attributes and/or values are copied to the Unsupported 1353 Attributes response group. 1355 ----------------------------------------------- 1357 job-priority (integer(1:100)) 1359 Expires August 12, 1999 1360 IF NOT a single 'integer' value with a length equal to 4 octets, 1361 REJECT/RETURN 'client-error-bad-request'. 1362 IF NOT supplied by the client, use the value of the Printer object's 1363 "job-priority-default" attribute at job submission time. 1364 IF NOT in the range 1 to 100, inclusive, copy the attribute and the 1365 unsupported value to the Unsupported Attributes response group. 1366 Map the value to the nearest supported value in the range 1:100 as 1367 specified by the number of discrete values indicated by the value 1368 of the Printer's "job-priority-supported" attribute. See the 1369 formula in [IPP-MOD] Section 4.2.1. 1371 job-hold-until (type3 keyword | name) 1373 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- 1374 error-request-bad-request'. 1375 IF the value length is greater than 255 octets, REJECT/RETURN 1376 'client-error-request-value-too-long'. 1377 IF NOT supplied by the client, use the value of the Printer object's 1378 "job-hold-until" attribute at job submission time. 1379 IF NOT in the Printer object's "job-hold-until-supported" attribute, 1380 copy the attribute and the unsupported value to the Unsupported 1381 Attributes response group. 1383 job-sheets (type3 keyword | name) 1385 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- 1386 error-request-bad-request'. 1387 IF the value length is greater than 255 octets, REJECT/RETURN 1388 'client-error-request-value-too-long'. 1389 IF NOT in the Printer object's "job-sheets-supported" attribute, copy 1390 the attribute and the unsupported value to the Unsupported 1391 Attributes response group. 1393 multiple-document-handling (type2 keyword) 1395 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-request- 1396 bad-request'. 1397 IF the value length is greater than 255 octets, REJECT/RETURN 1398 'client-error-request-value-too-long'. 1399 IF NOT in the Printer object's "multiple-document-handling-supported" 1400 attribute, copy the attribute and the unsupported value to the 1401 Unsupported Attributes response group. 1403 copies (integer(1:MAX)) 1405 IF NOT a single 'integer' value with a length equal to 4 octets, 1406 REJECT/RETURN 'client-error-bad-request'. 1407 IF NOT in range of the Printer object's "copies-supported" attribute 1408 copy the attribute and the unsupported value to the Unsupported 1409 Attributes response group. 1411 finishings (1setOf type2 enum) 1413 Expires August 12, 1999 1414 IF NOT an 'enum' value(s) each with a length equal to 4 octets, 1415 REJECT/RETURN 'client-error-bad-request'. 1416 IF NOT in the Printer object's "finishings-supported" attribute, copy 1417 the attribute and the unsupported value(s), but not any supported 1418 values, to the Unsupported Attributes response group. 1420 page-ranges (1setOf rangeOfInteger(1:MAX)) 1422 IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8 1423 octets, REJECT/RETURN 'client-error-bad-request'. 1424 IF first value is greater than second value in any range, the ranges 1425 are not in ascending order, or ranges overlap, REJECT/RETURN 1426 'client-error-bad-request'. 1427 IF the value of the Printer object's "page-ranges-supported" 1428 attribute is 'false', copy the attribute to the Unsupported 1429 Attributes response group and set the value to the "out-of-band" 1430 'unsupported' value. 1432 sides (type2 keyword) 1434 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-request- 1435 bad-request'. 1436 IF the value length is greater than 255 octets, REJECT/RETURN 1437 'client-error-request-value-too-long'. 1438 IF NOT in the Printer object's "sides-supported" attribute, copy the 1439 attribute and the unsupported value to the Unsupported Attributes 1440 response group. 1442 number-up (integer(1:MAX)) 1444 IF NOT a single 'integer' value with a length equal to 4 octets, 1445 REJECT/RETURN 'client-error-bad-request'. 1446 IF NOT a value or in the range of one of the values of the Printer 1447 object's "number-up-supported" attribute, copy the attribute and 1448 value to the Unsupported Attribute response group. 1450 orientation-requested (type2 enum) 1452 IF NOT a single 'enum' value with a length equal to 4 octets, 1453 REJECT/RETURN 'client-error-bad-request'. 1454 IF NOT in the Printer object's "orientation-requested-supported" 1455 attribute, copy the attribute and the unsupported value to the 1456 Unsupported Attributes response group. 1458 media (type3 keyword | name) 1460 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- 1461 error-request-bad-request'. 1462 IF the value length is greater than 255 octets, REJECT/RETURN 1463 'client-error-request-value-too-long'. 1464 IF NOT in the Printer object's "media-supported" attribute, copy the 1465 attribute and the unsupported value to the Unsupported Attributes 1466 response group. 1468 Expires August 12, 1999 1470 printer-resolution (resolution) 1472 IF NOT a single 'resolution' value with a length equal to 9 octets, 1473 REJECT/RETURN 'client-error-bad-request'. 1474 IF NOT in the Printer object's "printer-resolution-supported" 1475 attribute, copy the attribute and the unsupported value to the 1476 Unsupported Attributes response group. 1478 print-quality (type2 enum) 1480 IF NOT a single 'enum' value with a length equal to 4 octets, 1481 REJECT/RETURN 'client-error-bad-request'. 1482 IF NOT in the Printer object's "print-quality-supported" attribute, 1483 copy the attribute and the unsupported value to the Unsupported 1484 Attributes response group. 1486 unknown or unsupported attribute (i.e., there is no corresponding 1487 Printer object "xxx-supported" attribute) 1489 IF the attribute syntax supplied by the client is supported but the 1490 length is not legal for that attribute syntax, 1491 REJECT/RETURN 'client-error-bad-request' if the length of the 1492 attribute syntax is fixed or 'client-error-request-value-too-long' 1493 if the length of the attribute syntax is variable. 1494 ELSE copy the attribute and value to the Unsupported Attributes 1495 response group and change the attribute value to the "out-of-band" 1496 'unsupported' value. Any remaining Job Template Attributes are 1497 either unknown or unsupported Job Template attributes and are 1498 validated algorithmically according to their attribute syntax for 1499 proper length (see below). 1501 ----------------------------------------------- 1503 If the attribute syntax is supported AND the length check fails, the IPP 1504 object REJECTS the request and RETURNS the 'client-error-bad-request' if 1505 the length of the attribute syntax is fixed or the 'client-error- 1506 request-value-too-long' status code if the length of the attribute 1507 syntax is variable. Otherwise, the IPP object copies the unsupported Job 1508 Template attribute to the Unsupported Attributes response group and 1509 changes the attribute value to the "out-of-band" 'unsupported' value. 1510 The following table shows the length checks for all attribute syntaxes. 1511 In the following table: "<=" means less than or equal, "=" means equal 1512 to: 1514 Expires August 12, 1999 1515 Name Octet length check for read-write attributes 1516 ----------- -------------------------------------------- 1517 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63 1518 'textWithoutLanguage' <= 1023 1519 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 1520 'nameWithoutLanguage' <= 255 1521 'keyword' <= 255 1522 'enum' = 4 1523 'uri' <= 1023 1524 'uriScheme' <= 63 1525 'charset' <= 63 1526 'naturalLanguage' <= 63 1527 'mimeMediaType' <= 255 1528 'octetString' <= 1023 1529 'boolean' = 1 1530 'integer' = 4 1531 'rangeOfInteger' = 8 1532 'dateTime' = 11 1533 'resolution' = 9 1534 '1setOf X' 1536 2.2.3.1 Check for conflicting Job Template attributes values 1538 Once all the Operation and Job Template attributes have been checked 1539 individually, the Printer object SHOULD check for any conflicting values 1540 among all the supported values supplied by the client. For example, a 1541 Printer object might be able to staple and to print on transparencies, 1542 however due to physical stapling constraints, the Printer object might 1543 not be able to staple transparencies. The IPP object copies the 1544 supported attributes and their conflicting attribute values to the 1545 Unsupported Attributes response group. The Printer object only copies 1546 over those attributes that the Printer object either ignores or 1547 substitutes in order to resolve the conflict, and it returns the 1548 original values which were supplied by the client. For example suppose 1549 the client supplies "finishings" equals 'staple' and "media" equals 1550 'transparency', but the Printer object does not support stapling 1551 transparencies. If the Printer chooses to ignore the stapling request 1552 in order to resolve the conflict, the Printer objects returns 1553 "finishings" equal to 'staple' in the Unsupported Attributes response 1554 group. If any attributes are multi-valued, only the conflicting values 1555 of the attributes are copied. 1557 Note: The decisions made to resolve the conflict (if there is a choice) 1558 is implementation dependent. 1560 2.2.3.2 Decide whether to REJECT the request 1562 If there were any unsupported Job Template attributes or 1563 unsupported/conflicting Job Template attribute values and the client 1564 supplied the "ipp-attribute-fidelity" attribute with the 'true' value, 1565 the Printer object REJECTS the request and return the status code: 1567 Expires August 12, 1999 1568 (1) 'client-error-conflicting-attributes' status code, if there were 1569 any conflicts between attributes supplied by the client. 1570 (2) 'client-error-attributes-or-values-not-supported' status code, 1571 otherwise. 1573 Note: Unsupported Operation attributes or values that are returned do 1574 not affect the status returned in this step. If the unsupported 1575 Operation attribute was a serious error, the above already rejected the 1576 request in a previous step. If control gets to this step with 1577 unsupported Operation attributes being returned, they are not serious 1578 errors. 1580 2.2.3.3 For the Validate-Job operation, RETURN one of the success 1581 status codes 1583 If the requested operation is the Validate-Job operation, the Printer 1584 object returns: 1586 (1) the "successful-ok" status code, if there are no unsupported or 1587 conflicting Job Template attributes or values. 1588 (2) the "successful-ok-conflicting-attributes, if there are any 1589 conflicting Job Template attribute or values. 1590 (3) the "successful-ok-ignored-or-substituted-attributes, if there 1591 are only unsupported Job Template attributes or values. 1593 Note: Unsupported Operation attributes or values that are returned do 1594 not affect the status returned in this step. If the unsupported 1595 Operation attribute was a serious error, the above already rejected the 1596 request in a previous step. If control gets to this step with 1597 unsupported Operation attributes being returned, they are not serious 1598 errors. 1600 2.2.3.4 Create the Job object with attributes to support 1602 If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied by 1603 the client), the Printer object: 1605 (1) creates a Job object, assigns a unique value to the job's "job- 1606 uri" and "job-id" attributes, and initializes all of the job's 1607 other supported Job Description attributes. 1608 (2) removes all unsupported attributes from the Job object. 1609 (3) for each unsupported value, removes either the unsupported value 1610 or substitutes the unsupported attribute value with some supported 1611 value. If an attribute has no values after removing unsupported 1612 values from it, the attribute is removed from the Job object (so 1613 that the normal default behavior at job processing time will take 1614 place for that attribute). 1615 (4) for each conflicting value, removes either the conflicting value 1616 or substitutes the conflicting attribute value with some other 1617 supported value. If an attribute has no values after removing 1618 conflicting values from it, the attribute is removed from the Job 1620 Expires August 12, 1999 1621 object (so that the normal default behavior at job processing time 1622 will take place for that attribute). 1624 If there were no attributes or values flagged as unsupported, or the 1625 value of 'ipp-attribute-fidelity" was 'false', the Printer object is 1626 able to accept the create request and create a new Job object. If the 1627 "ipp-attribute-fidelity" attribute is set to 'true', the Job Template 1628 attributes that populate the new Job object are necessarily all the Job 1629 Template attributes supplied in the create request. If the "ipp- 1630 attribute-fidelity" attribute is set to 'false', the Job Template 1631 attributes that populate the new Job object are all the client supplied 1632 Job Template attributes that are supported or that have value 1633 substitution. Thus, some of the requested Job Template attributes may 1634 not appear in the Job object because the Printer object did not support 1635 those attributes. The attributes that populate the Job object are 1636 persistently stored with the Job object for that Job. A Get-Job- 1637 Attributes operation on that Job object will return only those 1638 attributes that are persistently stored with the Job object. 1640 Note: All Job Template attributes that are persistently stored with the 1641 Job object are intended to be "override values"; that is, they that take 1642 precedence over whatever other embedded instructions might be in the 1643 document data itself. However, it is not possible for all Printer 1644 objects to realize the semantics of "override". End users may query the 1645 Printer's "pdl-override-supported" attribute to determine if the Printer 1646 either attempts or does not attempt to override document data 1647 instructions with IPP attributes. 1649 There are some cases, where a Printer supports a Job Template attribute 1650 and has an associated default value set for that attribute. In the case 1651 where a client does not supply the corresponding attribute, the Printer 1652 does not use its default values to populate Job attributes when creating 1653 the new Job object; only Job Template attributes actually in the create 1654 request are used to populate the Job object. The Printer's default 1655 values are only used later at Job processing time if no other IPP 1656 attribute or instruction embedded in the document data is present. 1658 Note: If the default values associated with Job Template attributes that 1659 the client did not supply were to be used to populate the Job object, 1660 then these values would become "override values" rather than defaults. 1661 If the Printer supports the 'attempted' value of the "pdl-override- 1662 supported" attribute, then these override values could replace values 1663 specified within the document data. This is not the intent of the 1664 default value mechanism. A default value for an attribute is used only 1665 if the create request did not specify that attribute (or it was ignored 1666 when allowed by "ipp-attribute-fidelity" being 'false') and no value was 1667 provided within the content of the document data. 1669 If the client does not supply a value for some Job Template attribute, 1670 and the Printer does not support that attribute, as far as IPP is 1671 concerned, the result of processing that Job (with respect to the 1672 missing attribute) is undefined. 1674 Expires August 12, 1999 1675 2.2.3.5 Return one of the success status codes 1677 Once the Job object has been created, the Printer object accepts the 1678 request and returns to the client: 1680 (1) the 'successful-ok' status code, if there are no unsupported or 1681 conflicting Job Template attributes or values. 1682 (2) the 'successful-ok-conflicting-attributes' status code, if there 1683 are any conflicting Job Template attribute or values. 1684 (3) the 'successful-ok-ignored-or-substituted-attributes' status 1685 code, if there are only unsupported Job Template attributes or 1686 values. 1688 Note: Unsupported Operation attributes or values that are returned do 1689 not affect the status returned in this step. If the unsupported 1690 Operation attribute was a serious error, the above already rejected the 1691 request in a previous step. If control gets to this step with 1692 unsupported Operation attributes being returned, they are not serious 1693 errors. 1695 The Printer object also returns Job status attributes that indicate the 1696 initial state of the Job ('pending', 'pending-held', 'processing', 1697 etc.), etc. See Print-Job Response, [IPP-MOD] section 3.2.1.2. 1699 2.2.3.6 Accept appended Document Content 1701 The Printer object accepts the appended Document Content data and either 1702 starts it printing, or spools it for later processing. 1704 2.2.3.7 Scheduling and Starting to Process the Job 1706 The Printer object uses its own configuration and implementation 1707 specific algorithms for scheduling the Job in the correct processing 1708 order. Once the Printer object begins processing the Job, the Printer 1709 changes the Job's state to 'processing'. If the Printer object supports 1710 PDL override (the "pdl-override-supported" attribute set to 1711 'attempted'), the implementation does its best to see that IPP 1712 attributes take precedence over embedded instructions in the document 1713 data. 1715 2.2.3.8 Completing the Job 1717 The Printer object continues to process the Job until it can move the 1718 Job into the 'completed' state. If an Cancel-Job operation is received, 1719 the implementation eventually moves the Job into the 'canceled' state. 1720 If the system encounters errors during processing that do not allow it 1721 to progress the Job into a completed state, the implementation halts all 1722 processing, cleans up any resources, and moves the Job into the 1723 'aborted' state. 1725 Expires August 12, 1999 1726 2.2.3.9 Destroying the Job after completion 1728 Once the Job moves to the 'completed', 'aborted', or 'canceled' state, 1729 it is an implementation decision as to when to destroy the Job object 1730 and release all associated resources. Once the Job has been destroyed, 1731 the Printer would return either the "client-error-not-found" or "client- 1732 error-gone" status codes for operations directed at that Job. 1734 Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" 1735 value for a sufficiently long time after a job has been destroyed, so 1736 that stale references kept by clients are less likely to access the 1737 wrong (newer) job. 1739 2.2.3.10 Interaction with "ipp-attribute-fidelity" 1741 Some Printer object implementations may support "ipp-attribute-fidelity" 1742 set to 'true' and "pdl-override-supported" set to 'attempted' and yet 1743 still not be able to realize exactly what the client specifies in the 1744 create request. This is due to legacy decisions and assumptions that 1745 have been made about the role of job instructions embedded within the 1746 document data and external job instructions that accompany the document 1747 data and how to handle conflicts between such instructions. The 1748 inability to be 100% precise about how a given implementation will 1749 behave is also compounded by the fact that the two special attributes, 1750 "ipp-attribute-fidelity" and "pdl-override-supported", apply to the 1751 whole job rather than specific values for each attribute. For example, 1752 some implementations may be able to override almost all Job Template 1753 attributes except for "number-up". 1755 2.3 Status codes returned by operation (Issue 1.50) 1757 This section lists all status codes once in the first operation (Print- 1758 Job). Then it lists the status codes that are different or specialized 1759 for subsequent operations under each operation. 1761 2.3.1Printer Operations 1763 2.3.1.1 Print-Job 1765 The Printer object MUST return one of the following "status-code" values 1766 for the indicated reason. Whether all of the document data has been 1767 accepted or not before returning the success or error response depends 1768 on implementation. See Section 14 for a more complete description of 1769 each status code. 1771 For the following success status codes, the Job object has been created 1772 and the "job-id", and "job-uri" assigned and returned in the response: 1774 successful-ok: no request attributes were substituted or ignored. 1775 successful-ok-ignored-or-substituted-attributes: some supplied (1) 1776 attributes were ignored or (2) unsupported attribute syntaxes or 1777 values were substituted with supported values or were ignored. 1779 Expires August 12, 1999 1780 Unsupported attributes, attribute syntaxes, or values MUST be 1781 returned in the Unsupported Attributes group of the response. 1782 successful-ok-conflicting-attributes: some supplied attribute values 1783 conflicted with the values of other supplied attributes and were 1784 either substituted or ignored. Attributes or values which conflict 1785 with other attributes and have been substituted or ignored MUST be 1786 returned in the Unsupported Attributes group of the response as 1787 supplied by the client. 1789 [ipp-mod] section 3.1.6 Operation Status Codes and Messages states 1790 (Issue 1.19): 1792 If the Printer object supports the "status-message" operation 1793 attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a 1794 status message for the following error status codes (see section 1795 14): 'client-error-bad-request', 'client-error-charset-not- 1796 supported', 'server-error-internal-error', 'server-error-operation- 1797 not-supported', and 'server-error-version-not-supported'. In this 1798 case, it MUST set the value of the "attributes-charset" operation 1799 attribute to 'utf-8' in the error response. 1801 For the following error status codes, no job is created and no "job-id" 1802 or "job-uri" is returned: 1804 client-error-bad-request: The request syntax does not conform to the 1805 specification. 1806 client-error-forbidden: The request is being refused for 1807 authorization or authentication reasons. The implementation 1808 security policy is to not reveal whether the failure is one of 1809 authentication or authorization. 1810 client-error-not-authenticated: Either the request requires 1811 authentication information to be supplied or the authentication 1812 information is not sufficient for authorization. 1813 client-error-not-authorized: The requester is not authorized to 1814 perform the request on the target object. 1815 client-error-not-possible: The request cannot be carried out because 1816 of the state of the system. See also 'server-error-not-accepting- 1817 jobs' status code which MUST take precedence if the Printer 1818 object's "printer-accepting-jobs" attribute is 'false'. 1819 client-error-timeout: not applicable. 1820 client-error-not-found: the target object does not exist. 1821 client-error-gone: the target object no longer exists and no 1822 forwarding address is known. 1823 client-error-request-entity-too-large: the size of the request 1824 and/or print data exceeds the capacity of the IPP Printer to 1825 process it. 1826 client-error-request-value-too-long: the size of request variable 1827 length attribute values, such as 'text' and 'name' attribute 1828 syntaxes, exceed the maximum length specified in [IPP-MOD] for the 1829 attribute and MUST be returned in the Unsupported Attributes Group. 1830 client-error-document-format-not-supported: the document format 1831 supplied is not supported. The "document-format" attribute with 1832 the unsupported value MUST be returned in the Unsupported 1833 Attributes Group. This error SHOULD take precedence over any other 1835 Expires August 12, 1999 1836 'xxx-not-supported' error, except 'client-error-charset-not- 1837 supported'. 1838 client-error-attributes-or-values-not-supported: one or more 1839 supplied attributes, attribute syntaxes, or values are not 1840 supported and the client supplied the "ipp-attributes-fidelity" 1841 operation attribute with a 'true' value. They MUST be returned in 1842 the Unsupported Attributes Group as explained below. 1843 client-error-uri-scheme-not-supported: not applicable. 1844 client-error-charset-not-supported: the charset supplied in the 1845 "attributes-charset" operation attribute is not supported. The 1846 Printer's "configured-charset" MUST be returned in the response as 1847 the value of the "attributes-charset" operation attribute and used 1848 for any 'text' and 'name' attributes returned in the error 1849 response. This error SHOULD take precedence over any other error, 1850 unless the request syntax is so bad that the client's supplied 1851 "attributes-charset" cannot be determined. 1852 client-error-conflicting-attributes: one or more supplied attribute 1853 values conflicted with each other and the client supplied the "ipp- 1854 attributes-fidelity" operation attribute with a 'true' value. They 1855 MUST be returned in the Unsupported Attributes Group as explained 1856 below. 1857 server-error-internal-error: an unexpected condition prevents the 1858 request from being fulfilled. 1859 server-error-operation-not-supported: not applicable (since Print- 1860 Job is REQUIRED). 1861 server-error-service-unavailable: the service is temporarily 1862 overloaded. 1863 server-error-version-not-supported: the version in the request is 1864 not supported. The "closest" version number supported MUST be 1865 returned in the response. 1866 server-error-device-error: a device error occurred while receiving 1867 or spooling the request or document data or the IPP Printer object 1868 can only accept one job at a time. 1869 server-error-temporary-error: a temporary error such as a buffer 1870 full write error, a memory overflow, or a disk full condition 1871 occurred while receiving the request and/or the document data. 1872 server-error-not-accepting-jobs: the Printer object's "printer-is- 1873 not-accepting-jobs" attribute is 'false'. 1874 server-error-busy: the Printer is too busy processing jobs to accept 1875 another job at this time. 1876 server-error-job-canceled: the job has been canceled by an operator 1877 or the system while the client was transmitting the document data. 1879 2.3.1.2 Print-URI 1881 All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 1882 Response are applicable to Print-URI with the following specializations 1883 and differences. See Section 14 for a more complete description of each 1884 status code. 1886 server-error-uri-scheme-not-supported: the URI scheme supplied in 1887 the "document-uri" operation attribute is not supported and is 1888 returned in the Unsupported Attributes group. 1890 Expires August 12, 1999 1892 2.3.1.3 Validate-Job 1894 All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 1895 Response are applicable to Validate-Job. See Section 14 for a more 1896 complete description of each status code. 1898 2.3.1.4 Create-Job 1900 All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 1901 Response are applicable to Create-Job with the following specializations 1902 and differences. See Section 14 for a more complete description of each 1903 status code. 1905 server-error-operation-not-supported: the Create-Job operation is 1906 not supported. 1908 2.3.1.5 Get-Printer-Attributes 1910 All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 1911 Response are applicable to the Get-Printer-Attributes operation with the 1912 following specializations and differences. See Section 14 for a more 1913 complete description of each status code. 1915 For the following success status codes, the requested attributes are 1916 returned in Group 3 in the response: 1918 successful-ok: no request attributes were substituted or ignored 1919 (same as Print-Job) and no requested attributes were unsupported. 1920 successful-ok-ignored-or-substituted-attributes: same as Print-Job, 1921 except the "requested-attributes" operation attribute MAY, but NEED 1922 NOT, be returned with the unsupported values. 1923 successful-ok-conflicting-attributes: same as Print-Job. 1925 For the error status codes, Group 3 is returned containing no attributes 1926 or is not returned at all: 1928 client-error-not-possible: Same as Print-Job, in addition the 1929 Printer object is not accepting any requests. 1930 client-error-request-entity-too-large: same as Print-job, except 1931 that no print data is involved. 1932 client-error-attributes-or-values-not-supported: not applicable, 1933 since unsupported operation attributes MUST be ignored and 1934 'successful-ok-ignored-or-substituted-attributes' returned. 1935 client-error-conflicting-attributes: same as Print-Job, except that 1936 "ipp-attribute-fidelity" is not involved. 1937 server-error-operation-not-supported: not applicable (since Get- 1938 Printer-Attributes is REQUIRED). 1939 server-error-device-error: same as Print-Job, except that no 1940 document data is involved. 1941 server-error-temporary-error: same as Print-Job, except that no 1942 document data is involved. 1943 server-error-not-accepting-jobs: not applicable.. 1944 server-error-busy: same as Print-Job, except the IPP object is too 1945 busy to accept even query requests. 1946 server-error-job-canceled: not applicable.. 1948 Expires August 12, 1999 1950 2.3.1.6 Get-Jobs 1952 All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 1953 Response are applicable to the Get-Jobs operation with the following 1954 specializations and differences. See Section 14 for a more complete 1955 description of each status code. 1957 For the following success status codes, the requested attributes are 1958 returned in Group 3 in the response: 1960 successful-ok: no request attributes were substituted or ignored 1961 (same as Print-Job) and no requested attributes were unsupported. 1962 successful-ok-ignored-or-substituted-attributes: same as Print-Job, 1963 except the "requested-attributes" operation attribute MAY, but NEED 1964 NOT, be returned with the unsupported values. 1965 successful-ok-conflicting-attributes: same as Print-Job. 1967 For any error status codes, Group 3 is returned containing no attributes 1968 or is not returned at all. The following brief error status code 1969 descriptions contain unique information for use with Get-Jobs operation. 1970 See section 14 for the other error status codes that apply uniformly to 1971 all operations: 1973 client-error-not-possible: Same as Print-Job, in addition the 1974 Printer object is not accepting any requests. 1975 client-error-request-entity-too-large: same as Print-job, except 1976 that no print data is involved. 1977 client-error-document-format-not-supported: not applicable. 1978 client-error-attributes-or-values-not-supported: not applicable, 1979 since unsupported operation attributes MUST be ignored and 1980 'successful-ok-ignored-or-substituted-attributes' returned. 1981 client-error-conflicting-attributes: same as Print-Job, except that 1982 "ipp-attribute-fidelity" is not involved. 1983 server-error-operation-not-supported: not applicable (since Get-Jobs 1984 is REQUIRED). 1985 server-error-device-error: same as Print-Job, except that no 1986 document data is involved. 1987 server-error-temporary-error: same as Print-Job, except that no 1988 document data is involved. 1989 server-error-not-accepting-jobs: not applicable. 1990 server-error-job-canceled: not applicable. 1992 2.3.2Job Operations 1994 2.3.2.1 Send-Document 1996 All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 1997 Response are applicable to the Get-Printer-Attributes operation with the 1998 following specializations and differences. See Section 14 for a more 1999 complete description of each status code. 2001 For the following success status codes, the document has been added to 2002 the specified Job object and the job's "number-of-documents" attribute 2003 has been incremented: 2005 Expires August 12, 1999 2006 successful-ok: no request attributes were substituted or ignored 2007 (same as Print-Job). 2008 successful-ok-ignored-or-substituted-attributes: same as Print-Job. 2009 successful-ok-conflicting-attributes: same as Print-Job. 2011 For the error status codes, no document has been added to the Job object 2012 and the job's "number-of-documents" attribute has not been incremented: 2014 client-error-not-possible: Same as Print-Job, except that the 2015 Printer's "printer-is-accepting-jobs" attribute is not involved, so 2016 that the client is able to finish submitting a multi-document job 2017 after this attribute has been set to 'true'. Another condition is 2018 that the state of the job precludes Send-Document, i.e., the job 2019 has already been closed out by the client. However, if the IPP 2020 Printer closed out the job due to timeout, the 'client-error- 2021 timeout' error status SHOULD be returned instead. 2022 client-error-timeout: This request was sent after the Printer closed 2023 the job, because it has not received a Send-Document or Send-URI 2024 operation within the Printer's "multiple-operation-time-out" period 2025 . 2026 client-error-request-entity-too-large: same as Print-Job. 2027 client-error-conflicting-attributes: same as Print-Job, except that 2028 "ipp-attributes-fidelity" operation attribute is not involved.. 2029 server-error-operation-not-supported: the Send-Document request is 2030 not supported. 2031 server-error-not-accepting-jobs: not applicable. 2032 server-error-job-canceled: the job has been canceled by an operator 2033 or the system while the client was transmitting the data. 2035 2.3.2.2 Send-URI 2037 All of the Print-Job status code descriptions in Section 3.2.1.2 Print- 2038 Job Response with the specializations described for Send-Document are 2039 applicable to Send-URI. See Section 14 for a more complete description 2040 of each status code. 2042 server-error-uri-scheme-not-supported: the URI scheme supplied in 2043 the "document-uri" operation attribute is not supported and the 2044 "document-uri" attribute MUST be returned in the Unsupported 2045 Attributes group. 2047 2.3.2.3 Cancel-Job 2049 All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 2050 Response are applicable to Cancel-Job with the following specializations 2051 and differences. See Section 14 for a more complete description of each 2052 status code. 2054 For the following success status codes, the Job object is being canceled 2055 or has been canceled: 2057 successful-ok: no request attributes were substituted or ignored 2058 (same as Print-Job). 2059 successful-ok-ignored-or-substituted-attributes: same as Print-Job. 2060 successful-ok-conflicting-attributes: same as Print-Job. 2062 Expires August 12, 1999 2064 For any of the error status codes, the Job object has not been canceled 2065 or was previously canceled. 2067 client-error-not-possible: The request cannot be carried out because 2068 of the state of the Job object ('completed', 'canceled', or 2069 'aborted') or the state of the system. 2070 client-error-not-found: the target Printer and/or Job object does 2071 not exist. 2072 client-error-gone: the target Printer and/or Job object no longer 2073 exists and no forwarding address is known. 2074 client-error-request-entity-too-large: same as Print-Job, except no 2075 document data is involved. 2076 client-error-document-format-not-supported: not applicable. 2077 client-error-attributes-or-values-not-supported: not applicable, 2078 since unsupported operation attributes and values MUST be ignored. 2079 client-error-conflicting-attributes: same as Print-Job, except that 2080 the Printer's "printer-is-accepting-jobs" attribute is not 2081 involved. 2082 server-error-operation-not-supported: not applicable (Cancel-Job is 2083 REQUIRED). 2084 server-error-device-error: same as Print-Job, except no document 2085 data is involved. 2086 server-error-temporary-error: same as Print-Job, except no document 2087 data is involved. 2088 server-error-not-accepting-jobs: not applicable.. 2089 server-error-job-canceled: not applicable. 2091 2.3.2.4 Get-Job-Attributes 2093 All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 2094 Response are applicable to Get-Job-Attributes with the following 2095 specializations and differences. See Section 14 for a more complete 2096 description of each status code. 2098 For the following success status codes, the requested attributes are 2099 returned in Group 3 in the response: 2101 successful-ok: no request attributes were substituted or ignored 2102 (same as Print-Job) and no requested attributes were unsupported. 2103 successful-ok-ignored-or-substituted-attributes: same as Print-Job, 2104 except the "requested-attributes" operation attribute MAY, but NEED 2105 NOT, be returned with the unsupported values. 2106 successful-ok-conflicting-attributes: same as Print-Job. 2108 For the error status codes, Group 3 is returned containing no attributes 2109 or is not returned at all. 2111 client-error-not-possible: Same as Print-Job, in addition the 2112 Printer object is not accepting any requests. 2113 client-error-document-format-not-supported: not applicable. 2114 client-error-attributes-or-values-not-supported: not applicable. 2115 client-error-uri-scheme-not-supported: not applicable. 2116 client-error-conflicting-attributes: not applicable 2117 server-error-operation-not-supported: not applicable (since Get-Job- 2118 Attributes is REQUIRED). 2120 Expires August 12, 1999 2122 server-error-device-error: same as Print-Job, except no document 2123 data is involved. 2124 server-error-temporary-error: sane as Print-Job, except no document 2125 data is involved.. 2126 server-error-not-accepting-jobs: not applicable. 2127 server-error-job-canceled: not applicable. 2129 2.4 Validate-Job 2131 The Validate-Job operation has been designed so that its implementation 2132 may be a part of the Print-Job operation. Therefore, requiring 2133 Validate-Job is not a burden on implementers. Also it is useful for 2134 client's to be able to count on its presence in all conformance 2135 implementations, so that the client can determine before sending a long 2136 document, whether the job will be accepted by the IPP Printer or not. 2138 2.5 Case Sensitivity in URIs (issue 1.6) 2140 IPP client and server implementations must be aware of the diverse 2141 uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and 2142 Host names as case insensitive but reminds us that the rest of the URL 2143 may well demonstrate case sensitivity. When creating URL's for fields 2144 where the choice is completely arbitrary, it is probably best to select 2145 lower case. However, this cannot be guaranteed and implementations MUST 2146 NOT rely on any fields being case-sensitive or case-insensitive in the 2147 URL beyond the URL scheme and host name fields. 2149 The reason that the IPP specification does not make any restrictions on 2150 URIs, is so that implementations of IPP may use off-the-shelf components 2151 that conform to the standards that define URIs, such as RFC 2396 and the 2152 HTTP/1.1 specifications [RFC2068]. See these specifications for rules 2153 of matching, comparison, and case-sensitivity. 2155 It is also recommended that System Administrators and implementations 2156 avoid creating URLs for different printers that differ only in their 2157 case. For example, don't have Printer1 and printer1 as two different 2158 IPP Printers. 2160 The HTTP/1.1 specification [RFC2068] contains more details on comparing 2161 URLs. 2163 2.6 Character Sets, natural languages, and internationalization 2165 This section discusses character set support, natural language support 2166 and internationalization. 2168 2.6.1Character set code conversion support (Issue 1.5) 2170 IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY 2171 support additional charsets. It is RECOMMENDED that an IPP object also 2172 support US-ASCII, since many clients support US-ASCII, and indicate that 2174 Expires August 12, 1999 2175 UTF-8 and US-ASCII are supported by populating the Printer's "charset- 2176 supported" with 'utf-8' and 'us-ascii' values. An IPP object is 2177 required to code covert with as little loss as possible between the 2178 charsets that it supports, as indicated in the Printer's "charsets- 2179 supported" attribute. 2181 How should the server handle the situation where the "attributes- 2182 charset" of the response itself is "us-ascii", but one or more 2183 attributes in that response is in the "utf-8" format? 2185 Example: Consider a case where a client sends a Print-Job request with 2186 "utf-8" as the value of "attributes-charset" and with the "job-name" 2187 attribute supplied. Later another client submits a Get-Job-Attribute or 2188 Get-Jobs request. This second request contains the "attributes-charset" 2189 with value "us-ascii" and "requested-attributes" attribute with exactly 2190 one value "job-name". 2192 According to the IPP-Mod document (section 3.1.4.2), the value of the 2193 "attributes-charset" for the response of the second request must be "us- 2194 ascii" since that is the charset specified in the request. The "job- 2195 name" value, however, is in "utf-8" format. Should the request be 2196 rejected even though both "utf-8" and "us-ascii" charsets are supported 2197 by the server? or should the "job-name" value be converted to "us-ascii" 2198 and return "successful-ok-conflicting-attributes" (0x0002) as the 2199 status code? 2201 Answer: An IPP object that supports both utf-8 (REQUIRED) and us-ascii, 2202 the second paragraph of section 3.1.4.2 applies so that the IPP object 2203 MUST accept the request, perform code set conversion between these two 2204 charsets with "the highest fidelity possible" and return 'successful- 2205 ok', rather than a warning 'successful-ok-conflicting-attributes, or an 2206 error. The printer will do the best it can to convert between each of 2207 the character sets that it supports--even if that means providing a 2208 string of question marks because none of the characters are 2209 representable in US ASCII. If it can't perform such conversion, it MUST 2210 NOT advertise us-ascii as a value of its "attributes-charset-supported" 2211 and MUST reject any request that requests 'us-ascii'. 2213 One IPP object implementation strategy is to convert all request text 2214 and name values to a Unicode internal representation. This is 16-bit 2215 and virtually universal. Then convert to the specified operation 2216 attributes-charset on output. 2218 Also it would be smarter for a client to ask for 'utf-8', rather than 2219 'us-ascii' and throw away characters that it doesn't understand, rather 2220 than depending on the code conversion of the IPP object. 2222 2.6.2What charset to return when an unsupported charset is requested 2223 (Issue 1.19)? 2225 Section 3.1.4.1 Request Operation attributes was clarified in November 2226 1998 as follows: 2228 Expires August 12, 1999 2229 All clients and IPP objects MUST support the 'utf-8' charset 2230 [RFC2044] and MAY support additional charsets provided that they 2231 are registered with IANA [IANA-CS]. If the Printer object does not 2232 support the client supplied charset value, the Printer object MUST 2233 reject the request, set the "attributes-charset" to 'utf-8' in the 2234 response, and return the 'client-error-charset-not-supported' 2235 status code and any 'text' or 'name' attributes using the 'utf-8' 2236 charset. 2238 Since the client and IPP object MUST support UTF-8, returning any text 2239 or name attributes in UTF-8 when the client requests a charset that is 2240 not supported should allow the client to display the text or name. 2242 Since such an error is a client error, rather than a user error, the 2243 client should check the status code first so that it can avoid 2244 displaying any other returned 'text' and 'name' attributes that are not 2245 in the charset requested. 2247 Furthermore, [ipp-mod] section 14.1.4.14 client-error-charset-not- 2248 supported (0x040D) was clarified in November 1998 as follows: 2250 For any operation, if the IPP Printer does not support the charset 2251 supplied by the client in the "attributes-charset" operation 2252 attribute, the Printer MUST reject the operation and return this 2253 status and any 'text' or 'name' attributes using the 'utf-8' 2254 charset (see Section 3.1.4.1). 2256 2.6.3Natural Language Override (NLO) (Issue 1.45) 2258 The 'text' and 'name' attributes each have two forms. One has an 2259 implicit natural language, and the other has an explicit natural 2260 language. The 'textWithoutLanguage' and 'textWithoutLanguage' are the 2261 two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage are 2262 the two 'name' forms. If a receiver (IPP object or IPP client) supports 2263 an attribute with attribute syntax 'text', it MUST support both forms in 2264 a request and a response. A sender (IPP client or IPP object) MAY send 2265 either form for any such attribute. When a sender sends a 2266 WithoutLanguage form, the implicit natural language is specified in the 2267 "attributes-natural-language" operation attribute which all senders MUST 2268 include in every request and response. 2270 When a sender sends a WithLanguage form, it MAY be different from the 2271 implicit natural language supplied by the sender or it MAY be the same. 2272 The receiver MUST treat either form equivalently. 2274 There is an implementation decision for senders, whether to always send 2275 the WithLanguage forms or use the WithoutLanguage form when the 2276 attribute's natural language is the same as the request or response. 2277 The former approach makes the sender implementation simpler. The latter 2278 approach is more efficient on the wire and allows inter-working with 2279 non-conforming receivers that fail to support the WithLanguage forms. 2280 As each approach have advantages, the choice is completely up to the 2281 implementer of the sender. 2283 Expires August 12, 1999 2284 Furthermore, when a client receives a 'text' or 'name' job attribute 2285 that it had previously supplied, that client MUST NOT expect to see the 2286 attribute in the same form, i.e., in the same WithoutLanguage or 2287 WithLanguage form as the client supplied when it created the job. The 2288 IPP object is free to transform the attribute from the WithLanguage form 2289 to the WithoutLanguage form and vice versa, as long as the natural 2290 language is preserved. However, in order to meet this latter 2291 requirement, it is usually simpler for the IPP object implementation to 2292 store the natural language explicitly with the attribute value, i.e., to 2293 store using an internal representation that resembles the WithLanguage 2294 form. 2296 The IPP Printer MUST copy the natural language of a job, i.e., the value 2297 of the "attributes-natural-language" operation attribute supplied by the 2298 client in the create operation, to the Job object as a Job Description 2299 attribute, so that a client is able to query it. In returning a Get- 2300 Job-Attributes response, the IPP object MAY return one of three natural 2301 language values in the response's "attributes-natural-language" 2302 operation attribute: (1) that requested by the requester, (2) the 2303 natural language of the job, or (3) the configured natural language of 2304 the IPP Printer, if the requested language is not supported by the IPP 2305 Printer. 2307 This "attributes-natural-language" Job Description attribute is useful 2308 for an IPP object implementation that prints start sheets in the 2309 language of the user who submitted the job. This same Job Description 2310 attribute is useful to a multi-lingual operator who has to communicate 2311 with different job submitters in different natural languages. This same 2312 Job Description attribute is expected to be used in the future to 2313 generate notification messages in the natural language of the job 2314 submitter. 2316 Early drafts of [IPP-MOD] contained a job-level natural language 2317 override (NLO) for the Get-Jobs response. A job-level (NLO) is an 2318 (unrequested) Job Attribute which then specified the implicit natural 2319 language for any other WithoutLanguage job attributes returned in the 2320 response for that job. Interoperability testing of early 2321 implementations showed that no one was implementing the job-level NLO in 2322 Get-Job responses. So the job-level NLO was eliminated from the Get- 2323 Jobs response. This simplification makes all requests and responses 2324 consistent in that the implicit natural language for any WithoutLanguage 2325 'text' or 'name' form is always supplied in the request's or response's 2326 "attributes-natural-language" operation attribute. 2328 2.7 The "queued-job-count" Printer Description attribute 2330 2.7.1Why is "queued-job-count" RECOMMENDED (Issue 1.14)? 2332 The reason that "queued-job-count" is RECOMMENDED, is that some clients 2333 look at that attribute alone when summarizing the status of a list of 2334 printers, instead of doing a Get-Jobs to determine the number of jobs in 2335 the queue. Implementations that fail to support the "queued-job-count" 2337 Expires August 12, 1999 2338 will cause that client to display 0 jobs when there are actually queued 2339 jobs. 2341 We would have made it a REQUIRED Printer attribute, but some 2342 implementations had already been completed before the issue was raised, 2343 so making it a SHOULD was a compromise. 2345 2.7.2Is "queued-job-count" a good measure of how busy a printer is 2346 (Issue 1.15)? 2348 The "queued-job-count" is not a good measure of how busy the printer is 2349 when there are held jobs. A future registration could be to add a 2350 "held-job-count" (or an "active-job-count") Printer Description 2351 attribute if experience shows that such an attribute (combination) is 2352 needed to quickly indicate how busy a printer really is. 2354 2.8 Sending empty attribute groups (Issue 1.16) 2356 The [IPP-MOD] and [IPP-PRO] specifications RECOMMEND that a sender not 2357 send an empty attribute group in a request or a response. However, they 2358 REQUIRE a receiver to accept an empty attribute group as equivalent to 2359 the omission of that group. So a client SHOULD omit the Job Template 2360 Attributes group entirely in a create operation that is not supplying 2361 any Job Template attributes. Similarly, an IPP object SHOULD omit an 2362 empty Unsupported Attributes group if there are no unsupported 2363 attributes to be returned in a response. 2365 The [IPP-PRO] specification REQUIRES a receiver to be able to receive 2366 either an empty attribute group or an omitted attribute group and treat 2367 them equivalently. The term "receiver" means an IPP object for a 2368 request and a client for a response. The term "sender' means a client 2369 for a request and an IPP object for a response. 2371 There is an exception to the rule for Get-Jobs when there are no 2372 attributes to be returned. [ipp-pro] contains the following paragraph: 2374 The syntax allows an xxx-attributes-tag to be present when the xxx- 2375 attribute-sequence that follows is empty. The syntax is defined 2376 this way to allow for the response of Get-Jobs where no attributes 2377 are returned for some job-objects. Although it is RECOMMENDED that 2378 the sender not send an xxx-attributes-tag if there are no 2379 attributes (except in the Get-Jobs response just mentioned), the 2380 receiver MUST be able to decode such syntax. 2382 2.9 Returning unsupported attributes in Get-Xxxx responses (Issue 1.18) 2384 In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes 2385 responses, the client cannot depend on getting unsupported attributes 2386 returned in the Unsupported Attributes group that the client requested, 2387 but are not supported by the IPP object. However, such unsupported 2388 requested attributes will not be returned in the Job Attributes or 2390 Expires August 12, 1999 2391 Printer Attributes group (since they are unsupported). Furthermore, the 2392 IPP object is REQUIRED to return the 'successful-ok-ignored-or- 2393 substituted-attributes' status code, so that the client knows that not 2394 all that was requested has been returned. 2396 2.10Returning job-state in Print-Job response (Issue 1.30) 2398 An IPP client submits a small job via Print-Job. By the time the IPP 2399 printer/print server is putting together a response to the operation, 2400 the job has finished printing and been removed as an object from the 2401 print system. What should the job-state be in the response? 2403 The Model suggests that the Printer return a response before it even 2404 accepts the document content. The Job Object Attributes are returned 2405 only if the IPP object returns one of the success status codes. Then the 2406 job-state would always be "pending" or "pending-held". 2408 This issue comes up for the implementation of an IPP Printer object as a 2409 server that forwards jobs to devices that do not provide job status back 2410 to the server. If the server is reasonably certain that the job 2411 completed successfully, then it should return the job-state as 2412 'completed'. Also the server can keep the job in its "job history" long 2413 after the job is no longer in the device. Then a user could query the 2414 server and see that the job was in the 'completed' state and completed 2415 as specified by the job's "time-at-completed" time which would be the 2416 same as the server submitted the job to the device. 2418 An alternative is for the server to respond to the client before or 2419 while sending the job to the device, instead of waiting until the server 2420 has finished sending the job to the device. In this case, the server 2421 can return the job's state as 'pending' with the 'job-outgoing' value in 2422 the job's "job-state-reasons" attribute. 2424 If the server doesn't know for sure whether the job completed 2425 successfully (or at all), it could return the (out-of-band) 'unknown' 2426 value. 2428 On the other hand, if the server is able to query the device and/or 2429 setup some sort of event notification that the device initiates when the 2430 job makes state transitions, then the server can return the current job 2431 state in the Print-Job response and in subsequent queries because the 2432 server knows what the job state is in the device (or can query the 2433 device). 2435 All of these alternatives depend on implementation of the server and the 2436 device. 2438 2.11Flow controlling the data portion of a Print-Job request (Issue 2439 1.22) 2441 A paused printer (or one that is stopped due to paper out or jam or 2442 spool space full or buffer space full, may flow control the data of a 2444 Expires August 12, 1999 2445 Print-Job operation (at the TCP/IP layer), so that the client is not 2446 able to send all the document data. Consequently, the Printer will not 2447 return a response until the condition is changed. 2449 The Printer should not return a Print-Job response with an error code in 2450 any of these conditions, since either the printer will be resumed and/or 2451 the condition will be freed either by human intervention or as jobs 2452 print. 2454 In writing test scripts to test IPP Printers, the script must also be 2455 written not to expect a response, if the printer has been paused, until 2456 the printer is resumed, in order to work with all possible 2457 implementations. 2459 2.12Multi-valued attributes (Issue 1.31) 2461 What is the attribute syntax for a multi-valued attribute? Since some 2462 attributes support values in more than one data type, such as "media", 2463 "job-hold-until", and "job-sheets", IPP semantics associate the 2464 attribute syntax with each value, not with the attribute as a whole. 2465 The protocol associates the attribute syntax tag with each value. Don't 2466 be fooled, just because the attribute syntax tag comes before the 2467 attribute keyword. All attribute values after the first have a zero 2468 length attribute keyword as the indication of a subsequent value of the 2469 same attribute. 2471 2.13Querying jobs with IPP that were submitted using other job 2472 submission protocols (Issue 1.32) 2474 The following clarification was added to [ipp-mod] section 8.5: 2476 8.5 Queries on jobs submitted using non-IPP protocols 2478 If the device that an IPP Printer is representing is able to accept 2479 jobs using other job submission protocols in addition to IPP, it is 2480 RECOMMEND that such an implementation at least allow such "foreign" 2481 jobs to be queried using Get-Jobs returning "job-id" and "job-uri" 2482 as 'unknown'. Such an implementation NEED NOT support all of the 2483 same IPP job attributes as for IPP jobs. The IPP object returns 2484 the 'unknown' out-of-band value for any requested attribute of a 2485 foreign job that is supported for IPP jobs, but not for foreign 2486 jobs. 2488 It is further RECOMMENDED, that the IPP Printer generate "job-id" 2489 and "job-uri" values for such "foreign jobs", if possible, so that 2490 they may be targets of other IPP operations, such as Get-Job- 2491 Attributes and Cancel-Job. Such an implementation also needs to 2492 deal with the problem of authentication of such foreign jobs. One 2493 approach would be to treat all such foreign jobs as belonging to 2494 users other than the user of the IPP client. Another approach 2495 would be for the foreign job to belong to 'anonymous'. Only if the 2496 IPP client has been authenticated as an operator or administrator 2497 of the IPP Printer object, could the foreign jobs be queried by an 2499 Expires August 12, 1999 2500 IPP request. Alternatively, if the security policy is to allow 2501 users to query other users' jobs, then the foreign jobs would also 2502 be visible to an end-user IPP client using Get-Jobs and Get-Job- 2503 Attributes. 2505 Thus IPP MAY be implemented as a "universal" protocol that provides 2506 access to jobs submitted with any job submission protocol. As IPP 2507 becomes widely implemented, providing a more universal access makes 2508 sense. 2510 2.14The 'none' value for empty sets (Issue 1.37) 2512 [ipp-mod] states that the 'none' value should be used as the value of a 2513 1SetOf when the set is empty. In most cases, sets that are potentially 2514 empty contain keywords so the keyword 'none' is used, but for the 3 2515 finishings attributes, the values are enums and thus the empty set is 2516 represented by the enum 3. Currently there are no other attributes with 2517 1SetOf values which can be empty and can contain values that are not 2518 keywords. This exception requires special code and is a potential place 2519 for bugs. It would have been better if we had chosen an out-of-band 2520 value, either "no-value" or some new value, such as 'none'. Since we 2521 didn't, implementations have to deal with the different representations 2522 of 'none', depending on the attribute syntax. 2524 2.15Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 1.39)? 2526 In [ipp-mod] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my- 2527 jobs' is present and set to TRUE, MUST the 'requesting-user-name' 2528 attribute be there to, and if it's not present what should the IPP 2529 printer do? 2531 [ipp-mod] Section 8.3 describes the various cases of "requesting-user- 2532 name" being present or not for any operation. If the client does not 2533 supply a value for "requesting-user-name", the printer MUST assume that 2534 the client is supplying some anonymous name, such as "anonymous". 2536 2.16The "multiple-document-handling" Job Template attribute and support 2537 of multiple document jobs 2539 ISSUE: IPP/1.0 is silent on which of the four effects an implementation 2540 would perform if it supports Create-Job, but does not support "multiple- 2541 document-handling". 2543 A fix to IPP/1.0 would be to require implementing all four values of 2544 "multiple-document-handling" if Create-Job is supported at all. Or at 2545 least 'single-document-new-sheet' and 'separate-documents-uncollated- 2546 copies'. In any case, an implementation that supports Create-Job SHOULD 2547 also support "multiple-document-handling". Support for all four values 2548 is RECOMMENDED, but at least the 'single-document-new-sheet' and 2549 'separate-documents-uncollated-copies' values, along with the "multiple- 2550 document-handling-default" indicating the default behavior and 2552 Expires August 12, 1999 2553 "multiple-document-handling-supported" values. If an implementation 2554 spools the data, it should also support the 'separate-documents- 2555 collated-copies' value as well. 2557 3 Encoding and Transport 2559 This section discusses various aspects of IPP/1.0 Encoding and Transport 2560 [IPP-PRO]. 2562 A server is not required to send a response until after it has received 2563 the client.s entire request. Hence, a client must not expect a response 2564 until after it has sent the entire request. However, we recommend that 2565 the server return a response as soon as possible if an error is detected 2566 while the client is still sending the data, rather than waiting until 2567 all of the data is received. Therefore, we also recommend that a client 2568 listen for an error response that an IPP server MAY send before it 2569 receives all the data. In this case a client, if chunking the data, can 2570 send a premature zero-length chunk to end the request before sending all 2571 the data (and so the client can keep the connection open for other 2572 requests, rather than closing it). If the request is blocked for some 2573 reason, a client MAY determine the reason by opening another connection 2574 to query the server using Get-Printer-Attributes. 2576 In the following sections, there are a tables of all HTTP headers which 2577 describe their use in an IPP client or server. The following is an 2578 explanation of each column in these tables. 2580 @ the .header. column contains the name of a header 2581 @ the .request/client. column indicates whether a client sends the 2582 header. 2583 @ the .request/ server. column indicates whether a server supports 2584 the header when received. 2585 @ the .response/ server. column indicates whether a server sends the 2586 header. 2587 @ the .response /client. column indicates whether a client supports 2588 the header when received. 2589 @ the .values and conditions. column specifies the allowed header 2590 values and the conditions for the header to be present in a 2591 request/response. 2593 The table for .request headers. does not have columns for responses, and 2594 the table for .response headers. does not have columns for requests. 2596 The following is an explanation of the values in the .request/client. 2597 and .response/ server. columns. 2599 @ must: the client or server MUST send the header, 2600 @ must-if: the client or server MUST send the header when the 2601 condition described in the .values and conditions. column is met, 2602 @ may: the client or server MAY send the header 2603 @ not: the client or server SHOULD NOT send the header. It is not 2604 relevant to an IPP implementation. 2606 Expires August 12, 1999 2608 The following is an explanation of the values in the .response/client. 2609 and .request/ server. columns. 2611 @ must: the client or server MUST support the header, 2612 @ may: the client or server MAY support the header 2613 @ not: the client or server SHOULD NOT support the header. It is not 2614 relevant to an IPP implementation. 2616 3.1 General Headers 2618 The following is a table for the general headers. 2620 General- Request Response Values and Conditions 2621 Header 2623 Client Server Server Client 2625 Cache- must not must not .no-cache. only 2626 Control 2628 Connection must-if must must- must .close. only. Both 2629 if client and server 2630 SHOULD keep a 2631 connection for the 2632 duration of a sequence 2633 of operations. The 2634 client and server MUST 2635 include this header 2636 for the last operation 2637 in such a sequence. 2639 Date may may must may per RFC 1123 [RFC1123] 2640 from RFC 2068 2641 [RFC2068] 2643 Pragma must not must not .no-cache. only 2645 Transfer- must-if must must- must .chunked. only . 2646 Encoding if Header MUST be present 2647 if Content-Length is 2648 absent. 2650 Upgrade not not not not 2652 Via not not not not 2654 3.2 Request Headers 2656 The following is a table for the request headers. 2658 Request-Header Client Server Request Values and Conditions 2660 Accept may must .application/ipp. only. This 2661 value is the default if the 2663 Expires August 12, 1999 2665 Request-Header Client Server Request Values and Conditions 2667 client omits it 2669 Accept-Charset not not Charset information is within 2670 the application/ipp entity 2672 Accept-Encoding may must empty and per RFC 2068 [RFC2068] 2673 and IANA registry for content- 2674 codings 2676 Accept-Language not not language information is within 2677 the application/ipp entity 2679 Authorization must-if must per RFC 2068. A client MUST send 2680 this header when it receives a 2681 401 .Unauthorized. response and 2682 does not receive a .Proxy- 2683 Authenticate. header. 2685 >From not not per RFC 2068. Because RFC 2686 recommends sending this header 2687 only with the user.s approval, it 2688 is not very useful 2690 Host must must per RFC 2068 2692 If-Match not not 2694 If-Modified- not not 2695 Since 2697 If-None-Match not not 2699 If-Range not not 2701 If-Unmodified- not not 2702 Since 2704 Max-Forwards not not 2706 Proxy- must-if not per RFC 2068. A client MUST send 2707 Authorization this header when it receives a 2708 401 .Unauthorized. response and a 2709 .Proxy-Authenticate. header. 2711 Range not not 2713 Referer not not 2715 User-Agent not not 2717 Expires August 12, 1999 2718 3.3 Response Headers 2720 The following is a table for the request headers. 2722 Response- Server Client Response Values and Conditions 2723 Header 2725 Accept-Ranges not not 2727 Age not not 2729 Location must-if may per RFC 2068. When URI needs 2730 redirection. 2732 Proxy- not must per RFC 2068 2733 Authenticate 2735 Public may may per RFC 2068 2737 Retry-After may may per RFC 2068 2739 Server not not 2741 Vary not not 2743 Warning may may per RFC 2068 2745 WWW- must-if must per RFC 2068. When a server needs to 2746 Authenticate authenticate a client. 2748 3.4 Entity Headers 2750 The following is a table for the entity headers. 2752 Entity-Header Request Response Values and Conditions 2754 Client Server Server Client 2756 Allow not not not not 2758 Content-Base not not not not 2760 Content- may must must must per RFC 2068 and IANA 2761 Encoding registry for content 2762 codings. 2764 Content- not not not not Application/ipp 2765 Language handles language 2767 Content- must-if must must-if must the length of the 2768 Length message-body per RFC 2769 2068. Header MUST be 2770 present if Transfer- 2772 Expires August 12, 1999 2774 Entity-Header Request Response Values and Conditions 2776 Client Server Server Client 2778 Encoding is absent.. 2780 Content- not not not not 2781 Location 2783 Content-MD5 may may may may per RFC 2068 2785 Content-Range not not not not 2787 Content-Type must must must must .application/ipp. 2788 only 2790 ETag not not not not 2792 Expires not not not not 2794 Last-Modified not not not not 2796 3.5 Optional support for HTTP/1.0 2798 IPP implementations consist of an HTTP layer and an IPP layer. In the 2799 following discussion, the term "client" refers to the HTTP client layer 2800 and the term "server" refers to the HTTP server layer. The Encoding and 2801 Transport document [IPP-PRO] requires that HTTP 1.1 MUST be supported by 2802 all clients and all servers. However, a client and/or a server 2803 implementation may choose to also support HTTP 1.0. 2805 @ This option means that a server may choose to communicate with a 2806 (non-conforming) client that only supports HTTP 1.0. In such cases 2807 the server should not use any HTTP 1.1 specific parameters or 2808 features and should respond using HTTP version number 1.0. 2810 @ This option also means that a client may choose to communicate with a 2811 (non-conforming) server that only supports HTTP 1.0. In such cases, 2812 if the server responds with an HTTP .unsupported version number. to 2813 an HTTP 1.1 request, the client should retry using HTTP version 2814 number 1.0. 2816 3.6 HTTP/1.1 Chunking 2818 3.6.1Disabling IPP Server Response Chunking 2820 Clients MUST anticipate that the HTTP/1.1 server may chunk responses and 2821 MUST accept them in responses. However, a (non-conforming) HTTP client 2822 that is unable to accept chunked responses may attempt to request an 2823 HTTP 1.1 server not to use chunking in its response to an operation by 2824 using the following HTTP header: 2826 Expires August 12, 1999 2827 TE: identity 2829 This mechanism should not be used by a server to disable a client from 2830 chunking a request, since chunking of document data is an important 2831 feature for clients to send long documents. 2833 3.6.2Warning About the Support of Chunked Requests 2835 This section describes some problems with the use of chunked requests 2836 and HTTP/1.1 servers. 2838 The HTTP/1.1 standard [HTTP] requires that conforming servers support 2839 chunked requests for any method. However, in spite of this requirement, 2840 some HTTP/1.1 implementations support chunked responses in the GET 2841 method, but do not support chunked POST method requests. Some HTTP/1.1 2842 implementations that support CGI scripts [CGI] and/or servlets [Servlet] 2843 require that the client supply a Content-Length. These implementations 2844 might reject a chunked POST method and return a 411 status code (Length 2845 Required), might attempt to buffer the request and run out of room 2846 returning a 413 status code (Request Entity Too Large), or might 2847 successfully accept the chunked request. 2849 Because of this lack of conformance of HTTP servers to the HTTP/1.1 2850 standard, the IPP standard [IPP-PRO] REQUIRES that a conforming IPP 2851 Printer object implementation support chunked requests and that 2852 conforming clients accept chunked responses. Therefore, IPP object 2853 implementers are warned to seek HTTP server implementations that support 2854 chunked POST requests in order to conform to the IPP standard and/or use 2855 implementation techniques that support chunked POST requests. 2857 4 References 2859 [CGI] 2860 CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11- 2861 00.txt). 2863 [HTTP] 2864 HTTP/1.1 (http://www.ietf.org/internet-drafts/draft-ietf-http-v11- 2865 spec-rev-06.txt) 2867 [IPP LPD] 2868 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 2869 LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-04.txt, June 2870 1998. 2872 [IPP-MOD] 2873 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 2874 "Internet Printing Protocol/1.0: Model and Semantics", draft-ietf- 2875 ipp-model-11.txt, November, 1998. 2877 Expires August 12, 1999 2879 [IPP-PRO] 2880 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 2881 Protocol/1.0: Encoding and Transport", draft-ietf-ipp-protocol- 2882 07.txt, November, 1998. 2884 [IPP-RAT] 2885 Zilles, S., "Rationale for the Structure and Model and Protocol for 2886 the Internet Printing Protocol", draft-ietf-ipp-rat-03.txt, June, 2887 1998. 2889 [IPP-REQ] 2890 Wright, D., "Design Goals for an Internet Printing Protocol", 2891 draft-ietf-ipp-req-02.txt, June, 1998. 2893 [RFC1123] 2894 Braden, S., "Requirements for Internet Hosts - Application and 2895 Support", RFC 1123, October, 1989. 2897 [RFC2026] 2898 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2899 2026, October 1996. 2901 [RFC2068] 2902 R Fielding, et al, .Hypertext Transfer Protocol . HTTP/1.1. RFC 2903 2068, January 1997. 2905 [rfc2119] 2906 S. Bradner, "Key words for use in RFCs to Indicate Requirement 2907 Levels", RFC 2119 , March 1997. 2909 [RFC2396] 2910 Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 2911 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 2913 [Servlet] 2914 Servlet Specification Version 2.1 2915 (http://java.sun.com/products/servlet/2.1/index.html). 2917 [SSL] 2918 Netscape, The SSL Protocol, Version 3, (Text version 3.02), 2919 November 1996. 2921 4.1 Authors. Address 2923 Thomas N. Hastings 2924 Xerox Corporation 2925 701 Aviation Blvd. 2926 El Segundo, CA 90245 2927 hastings@cp10.es.xerox.com 2929 Carl-Uno Manros 2931 Expires August 12, 1999 2932 Xerox Corporation 2933 701 Aviation Blvd. 2934 El Segundo, CA 90245 2935 manros@cp10.es.xerox.com 2937 5 Notices 2939 The IETF takes no position regarding the validity or scope of any 2940 intellectual property or other rights that might be claimed to pertain 2941 to the implementation or use of the technology described in this 2942 document or the extent to which any license under such rights might or 2943 might not be available; neither does it represent that it has made any 2944 effort to identify any such rights. Information on the IETF's 2945 procedures with respect to rights in standards-track and standards- 2946 related documentation can be found in BCP-11[BCP-11]. Copies of claims 2947 of rights made available for publication and any assurances of licenses 2948 to be made available, or the result of an attempt made to obtain a 2949 general license or permission for the use of such proprietary rights by 2950 implementers or users of this specification can be obtained from the 2951 IETF Secretariat. 2953 The IETF invites any interested party to bring to its attention any 2954 copyrights, patents or patent applications, or other proprietary rights 2955 which may cover technology that may be required to practice this 2956 standard. Please address the information to the IETF Executive 2957 Director. 2959 Copyright (C) The Internet Society (1999). All Rights Reserved. 2961 This document and translations of it may be copied and furnished to 2962 others, and derivative works that comment on or otherwise explain it or 2963 assist in its implementation may be prepared, copied, published and 2964 distributed, in whole or in part, without restriction of any kind, 2965 provided that the above copyright notice and this paragraph are included 2966 on all such copies and derivative works. However, this document itself 2967 may not be modified in any way, such as by removing the copyright notice 2968 or references to the Internet Society or other Internet organizations, 2969 except as needed for the purpose of developing Internet standards in 2970 which case the procedures for copyrights defined in the Internet 2971 Standards process must be followed, or as required to translate it into 2972 languages other than English. 2974 The limited permissions granted above are perpetual and will not be 2975 revoked by the Internet Society or its successors or assigns. 2977 This document and the information contained herein is provided on an "AS 2978 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2979 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2980 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2981 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2982 FITNESS FOR A PARTICULAR PURPOSE. 2984 Expires August 12, 1999 2985 6 Change History 2987 The change history is in reverse chronological order: 2989 6.1 Changes to produce the February 12, 1999 version from the January 8, 2990 1999 version: 2992 1. Section 2.2.1.5: added check for document not found or accessible 2993 in Print-URI and Send-URI 2995 2. Section 3.6.2: Clarified that the IPP standard requires that 2996 servers MUST accept chunked requests and that clients MUST accept 2997 chunked responses, in spite of the lack of conformance of HTTP 2998 servers to the HTTP/1.1 requirement to support chunking. 3000 6.2 Changes to produce the January 8, 1999 version from the December 6, 3001 1998 version: 3003 1. Added section 3.6.2: Warning About the Use of Chunked Requests 3004 with CGI Script Implementations 3006 2. Section 2.2.1.2: changed "printer-operations-supported" to 3007 "operations-supported". 3009 3. Section 2.2.1.6: changed "job-media-supported" to "job-media- 3010 sheets-supported" 3012 4. Section 2.2.3: separated the validation checks for variable length 3013 attributes into two separate tests: one for correct attribute 3014 syntax and one for correct length. 3016 5. Section 2.2.3: changed "multiple-document-handling-supported" to 3017 "printer-resolution-supported" 3019 6. Section 2.6.1: recommended that an IPP object also support US- 3020 ASCII charset. 3022 7. Section 3: Clarified that a server is not required to send a 3023 response until after it has received the client.s entire request, 3024 but recommend that the server return a response as soon as possible 3025 if an error is detected while the client is still sending the data, 3026 rather than waiting until all of the data is received. Also 3027 recommended that a client listen for an error response that an IPP 3028 server MAY send before it receives all the data. 3030 6.3 Changes to produce the December 6, 1998 version from the November 3031 16, 1998 version: 3033 Included all of the remaining agreed issues raised before the November 3034 16, 1998 production of the Internet-Drafts for IPP/1.0 that included 3035 adding explanations to the Implementers Guide. 3037 Expires August 12, 1999 3038 Expires August 12, 1999