Example 2: "Auto-Cut", a device cutting the roll paper at multiples of fixed-size media width data height: A1 height data width (shaded): A1 width < data width < (A1 width) x 2 specified value: 'auto-fixed-size-white' | | |<--- data width --->| | | | | | | |<- A1 width ->|<- A1 width ->| | | | | cross ^ | | | | feed | +--------------------------------------------/ direction | |//////////////|/////| | ^ / | |//////////////|/////| | | / | |//////////////|/////| | | / | |//////////////|/////| | | \ <-----------+- |//////////////|/////| | A1 \ roll feed | |//////////////|/////| | height \ paper direction |//////////////|/////| | | \ |//////////////|/////| | | / |//////////////|/////| | v / +------------------------------------------/ | | |<--- CUT HERE | (to synchronize | with data width)
Example 3: the 'iso-a4x4-white' fixed size paper paper height: A4 height paper width: (A4 width) x 4 specified value: 'iso-a4x4-white' | | | | | |<- A4 width ->|<- A4 width ->|<- A4 width ->|<- A4 width ->| | | | | | | | | | | +-----------------------------------------------------------+ | ^ | | | | | | | | | | | | | | | | | A4 | | | | | height | | | | | | | | | | | | | | | | | | | | | | | v | | | | +-----------------------------------------------------------+
Example 4: "Synchro-Cut", a device cutting the fixed size paper in synchronization with the data data height: A4 height data width (shaded): (A4 width) x 2 < data width < (A4 width) x 3 specified value: 'iso-a4xsynchro-white' | | |<---------- data width ----------->| | | | | | | | |<- A4 width ->|<- A4 width ->|<- A4 width ->| | | | | | cross ^ | | | | | feed | +--------------------------------------------+ direction | |//////////////|//////////////|/////| ^ | | |//////////////|//////////////|/////| | | | |//////////////|//////////////|/////| | | | |//////////////|//////////////|/////| | | <-----------+- |//////////////|//////////////|/////| A4 | feed | |//////////////|//////////////|/////| height | direction |//////////////|//////////////|/////| | | |//////////////|//////////////|/////| | | |//////////////|//////////////|/////| v | +--------------------------------------------+ | CUT HERE ---->| (to synchronize | with data width) |
The following sections describe how these two types of conflicts are handled in the IPP model.
- If the client supplies 'false' or does not supply the attribute, the Printer object MUST always accept the request by ignoring unsupported Job Template attributes and by substituting unsupported values of supported Job Template attributes with supported values. - If the client supplies 'true', the Printer object MUST reject the request if the client supplies unsupported Job Template attributes. Since a client can always query a Printer to find out exactly what is and is not supported, "ipp-attribute-fidelity" set to 'false' is useful when: 1) The End-User uses a command line interface to request attributes that might not be supported. 2) In a GUI context, if the End User expects the job might be moved to another printer and prefers a sub-optimal result to nothing at all. 3) The End User just wants something reasonable in lieu of nothing at all.
This REQUIRED Printer attribute takes on the following values: - 'attempted': This value indicates that the Printer object attempts to make the IPP attribute values take precedence over embedded instructions in the document data, however there is no guarantee. - 'not-attempted': This value indicates that the Printer object makes no attempt to make the IPP attribute values take precedence over embedded instructions in the document data. At job processing time, an implementation that supports the value of 'attempted' might do one of several different actions: 1) Generate an output device specific command sequence to realize the feature represented by the IPP attribute value. 2) Parse the document data itself and replace the conflicting embedded instruction with a new embedded instruction that matches the intent of the IPP attribute value. 3) Indicate to the Printer that external supplied attributes take precedence over embedded instructions and then pass the external IPP attribute values to the document data interpreter. 4) Anything else that allows for the semantics that IPP attributes override embedded document data instructions. Since 'attempted' does not offer any type of guarantee, even though a given Printer object might not do a very "good" job of attempting to ensure that IPP attributes take a higher precedence over instructions embedded in the document data, it would still be a conforming implementation. At job processing time, an implementation that supports the value of 'not-attempted' might do one of the following actions: 1) Simply pre-pend the document data with the PDL instruction that corresponds to the client-supplied PDL attribute, such that if the document data also has the same PDL instruction, it will override what the Printer object pre-pended. In other words, this implementation is using the same implementation semantics for the client-supplied IPP attributes as for the Printer object defaults. 2) Parse the document data and replace the conflicting embedded instruction with a new embedded instruction that approximates, but does not match, the semantic intent of the IPP attribute value. Note: The "ipp-attribute-fidelity" attribute applies to the Printer's ability to either accept or reject other unsupported Job
Template attributes. In other words, if "ipp-attribute-fidelity" is set to 'true', a Job is accepted if and only if the client supplied Job Template attributes and values are supported by the Printer. Whether these attributes actually affect the processing of the Job when the document data contains embedded instructions depends on the ability of the Printer to override the instructions embedded in the document data with the semantics of the IPP attributes. If the document data attributes can be overridden ("pdl-override-supported" set to 'attempted'), the Printer makes an attempt to use the IPP attributes when processing the Job. If the document data attributes can not be overridden ("pdl-override-supported" set to 'not- attempted'), the Printer makes no attempt to override the embedded document data instructions with the IPP attributes when processing the Job, and hence, the IPP attributes may fail to affect the Job processing and output when the corresponding instruction is embedded in the document data. section 4.2.10 for the details. 2. The document data is in the form of a print-stream in a known media type. The "page-ranges" attribute is used to select, as specified in section 4.2.7, a sub-sequence of the pages in the print-stream that are to be processed and images. 3. The input to this step is a sequence of print-stream pages. This step is controlled by the "number-up" attribute. If the
value of "number-up" is N, then during the processing of the print-stream pages, each N print-stream pages are positioned, as specified in section 4.2.9, to create a single impression. If a given document does not have N more print-stream pages, then the completion of the impression is controlled by the "multiple-document-handling" attribute as described in section 4.2.4; when the value of this attribute is 'single-document' or 'single-document-new-sheet', the print-stream pages of document data from subsequent documents is used to complete the impression. The size(scaling), position(translation) and rotation of the print-stream pages on the impression is implementation defined. Note that during this process the print-stream pages may be rendered to a form suitable for placing on the impression; this rendering is controlled by the values of the "printer- resolution" and "print-quality" attributes as described in sections 4.2.12 and 4.2.13. In the case N=1, the impression is nearly the same as the print-stream page; the differences would only be in the size, position and rotation of the print-stream page and/or any decoration, such as a frame to the page, that is added by the implementation. 4. The collection of impressions is placed, in sequence, onto sides of the media sheets. This placement is controlled by the "sides" attribute and the orientation of the print-stream page, as described in section 4.2.8. The orientation of the print- stream pages affects the orientation of the impression; for example, if "number-up" equals 2, then, typically, two portrait print-stream pages become one landscape impression. Note that the placement of impressions onto media sheets is also controlled by the "multiple-document-handling" attribute as described in section 4.2.4. 5. The "copies" and "multiple-document-handling" attributes are used to determine how many copies of each media instance are created and in what order. See sections 4.2.5 and 4.2.4 for the details. 6. When the correct number of copies are created, the media instances are finished according to the values of the "finishings" attribute as described in 4.2.6. Note that sometimes finishing operations may require manual intervention to perform the finishing operations on the copies, especially uncollated copies. This document allows any or all of the processing steps to be performed automatically or manually at the discretion of the Printer object.
sections 4.2 and 4.4). These attributes are identified as either RECOMMENDED or OPTIONAL for the directory entry itself. This conformance labeling is NOT the same conformance labeling applied to the attributes of IPP Printers objects. The conformance labeling in this Appendix is intended to apply to directory templates and to IPP Printer implementations that subscribe by adding one or more entries to a directory. RECOMMENDED attributes SHOULD be associated with each directory entry. OPTIONAL attributes MAY be associated with the directory entry (if known or supported). In addition, all directory entry attributes SHOULD reflect the current attribute values for the corresponding Printer object. The names of attributes in directory schema and entries SHOULD be the same as the IPP Printer attribute names as shown, as much as possible. In order to bridge between the directory service and the IPP Printer object, one of the RECOMMENDED directory entry attributes is the Printer object's "printer-uri-supported" attribute. The directory client queries the "printer-uri-supported" attribute (or its equivalent) in the directory entry and then the IPP client addresses
the IPP Printer object using one of its URIs. The "uri-security- supported" attribute identifies the protocol (if any) used to secure a channel. The following attributes define the generic schema for directory entries of type PRINTER: printer-uri-supported RECOMMENDED Section 4.4.1 uri-authentication-supported RECOMMENDED Section 4.4.2 uri-security-supported RECOMMENDED Section 4.4.3 printer-name RECOMMENDED Section 4.4.4 printer-location RECOMMENDED Section 4.4.5 printer-info OPTIONAL Section 4.4.6 printer-more-info OPTIONAL Section 4.4.7 printer-make-and-model RECOMMENDED Section 4.4.9 ipp-versions-supported RECOMMENDED Section 4.4.14 multiple-document-jobs-supported OPTIONAL Section 4.4.16 charset-supported OPTIONAL Section 4.4.18 generated-natural-language- supported OPTIONAL Section 4.4.20 document-format-supported RECOMMENDED Section 4.4.22 color-supported RECOMMENDED Section 4.4.26 compression-supported RECOMMENDED Section 4.4.32 pages-per-minute OPTIONAL Section 4.4.36 pages-per-minute-color OPTIONAL Section 4.4.37 finishings-supported OPTIONAL Section 4.2.6 number-up-supported OPTIONAL Section 4.2.7 sides-supported RECOMMENDED Section 4.2.8 media-supported RECOMMENDED Section 4.2.11 printer-resolution-supported OPTIONAL Section 4.2.12 print-quality-supported OPTIONAL Section 4.2.13 RFC2566]. The section numbers refer to the numbers in this document which in some cases have changed from RFC 2566. When a change affects multiple sections, the item is listed once in the order of the first section affected and the remaining affected section numbers are indicated.
The first list contains extensions and clarifications and the second list contains changes in semantics or conformance. However, client and IPP object implementations of IPP/1.0 MAY implement any of the extensions and clarifications in this document. The following extensions and clarifications have been incorporated into this document: 1. Section 2.1 - clarified that the term "client" can be either contained in software controlled by an end user or a part of a print server that controls devices. 2. Section 2 - clarified that the term "IPP object" and "Printer object" can either be embedded in a device object or part of a print server that accepts IPP requests. 3. Section 2.4 - added the description of the new "uri- authentication-supported" Printer Description attribute. 4. Section 3.1.3, 3.1.6, 22.214.171.124, and 126.96.36.199 - clarified the error handling for operation attributes that have their own status code. 5. Section 3.1.3 - clarified that multiple occurrences of the same attribute in an attribute group is mal-formed. An IPP Printer MAY reject the request or choose one of the attributes. 6. Section 3.1.6 - reorganized this section into sub-sections to separately describe "status-code", "status-message", "detailed-status-message", and "document-access-error" attributes. 7. Section 188.8.131.52 - clarified the error status codes and their relationship to operation attributes. 8. Section 184.108.40.206 - Added the OPTIONAL "detailed-status-message (text(MAX))" operation attribute to provide additional more detailed information about a response. 9. Section 220.127.116.11 and 3.2.2 - Added the OPTIONAL "document- access-error (text(MAX))" operation attribute for use with Print-URI and Send-URI responses. 10. Sections 3.1.7 - Added this new section to clarify returning Unsupported Attributes for all operations, including only returning attributes that were in the request. Moved the text from section 18.104.22.168 Unsupported Attributes to this section. 11. Sections 3.1.7 and 4.1 - clarified the encoding of the "out- of-band" 'unsupported' and 'unknown' values. 12. Section 3.1.8 - clarified that only the version number parameter will be carried forward into future major or minor versions of the protocol. 13. Section 3.1.8 - relaxed the requirements to increment the major version number in future versions of the Model and Semantics document.
14. Section 3.1.9, and 3.2.5 - added the 'processing' state to the list of job states that a job can be in after a Create-Job operation. 15. Section 3.1.9 - clarified that a non-spooling Printer MAY accept zero or more subsequent jobs while processing a job and flow control them down. Subsequent create requests are rejected with the 'server-error-busy' error status. 16. Section 22.214.171.124 - clarified the validation of the "compression" operation attribute and its relationship to the validation of the "document-format" attribute and returning Unsupported Attributes. 17. Sections 126.96.36.199, 4.3.8, 188.8.131.52, and 184.108.40.206 - added the 'client-error-compression-not-supported', 'client-error- compression-error' status codes and the 'unsupported- compression' and 'compression-error' job-state-reasons. 18. Sections 220.127.116.11 and 4.3.8 - added 'unsupported-document- format' and 'document-format-error' job-state-reasons. 19. Sections 3.2.2, 4.3.8 and 18.104.22.168 - added 'client-error- document-access-error' status code and 'document-access-error' job state reason. 20. Section 22.214.171.124 and 126.96.36.199 - clarified that the Unsupported Attributes group MUST NOT include attributes not requested in the Get-Printer-Attributes request. 21. Section 3.2.6 - clarified that "limit" takes precedence over "which-jobs" and "my-jobs'. 22. Section 188.8.131.52 - clarified that Get-Jobs returns 'successful-ok' when no jobs to return. 23. Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause- Printer, Resume-Printer, and Purge-Jobs operations 24. Section 3.3.1 - clarified that the authorization required for a Send-Document request MUST be the same user as the Create- Job or an operator. 25. Section 184.108.40.206 - clarified that a Create-Job Send-Document with "last-document" = 'true' and no data is not an error; its a job with no documents. 26. Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold- Job, Release-Job, and Restart-Job operations. Clarified the Restart-Job operation so that the Printer MUST re-fetch any documents passed by-reference (Print-URI or Send-URI). 27. Section 4.1 - clarified that the encoding of the out-of-band values are specified in the Encoding and Transport" document. 28. Section 4.1 - Clarified that the requirement that clients MUST NOT send "out-of-band" values in requests applies only to operations defined in this document. Other operations are allowed to define "out-of-band" values that clients can supply.
29. Sections 4.1.1 and 4.1.2 - clarified that the maximum 'text' and 'name' values of 1023 and 255 are for the 'textWithoutLanguage' portion of the 'textWithLanguage' form, so that the maximum number of octets for the actual text and name data is the same for the without and with language forms; the 'naturalLanguage' part is in addition. 30. Section 4.1.9 - clarified that 'mimeMediaType' values can include any parameters from the IANA Registry, not just charset parameters. 31. Section 220.127.116.11 - clarified that 'application/octet-stream' auto-sensing can happen at create request time and/or job/document processing time. 32. Section 18.104.22.168 - clarified that auto-sensing involves the Printer examining some number of octets of document data using an implementation-dependent method. 33. Section 4.1.14 - clarified that the localization of dateTime by the client includes the time zone. 34. Section 4.2 - clarified that xxx-supported have multiple keywords and/or names by adding parentheses to the table to give: (1setOf (type3 keyword | name)) 35. Section 4.2.2 - added the 'indefinite' keyword value to the "job-hold-until" attribute for use with the create operations and Hold-Job and Restart-Job operations. 36. Section 4.2.6 - added more enum values to the "finishings" Job Template attribute. 37. Section 4.2.6 - clarified that the landscape definition is a rotation of the image with respect to the medium. 38. Section 4.3.7 - added that a forwarding server that cannot get any job state MAY return the job's state as 'completed', provided that it also return the new 'queued-in-device' job state reason. 39. Section 22.214.171.124 - added the Partitioning of Job States section to clarify the concepts of Job Retention, Job History, and Job Removal. 40. Section 4.3.8 - added 'job-data-insufficient' job state reason to indicate whether sufficient data has arrived for the document to start to be processed. 41. Section 4.3.8 - added 'document-access-error' job state reason to indicate an access error of any kind. 42. Section 4.3.8 - added 'job-queued-for-marker' job state reason to indicate whether the job has completed some processing and is waiting for the marker. 43. Section 4.3.8 - added 'unsupported-compression' and 'compression-error' job state reasons to indicate compression not supported or compression processing error after the create has been accepted.
44. Section 4.3.8 - added 'unsupported-document-format' and 'document-format-error' job state reasons to indicate document not supported or document format processing error after the create has been accepted. 45. Section 4.3.8 - added 'queued-in-device' job state reason to indicate that a job as been forwarded to a print system or device that does not provide any job status. 46. Section 4.3.10 - added "job-detailed-status-messages (1setOf text(MAX)) for returning detailed error messages. 47. Section 4.3.11 - added the "job-document-access-errors (1setOf text(MAX)) 48. Section 126.96.36.199 - clarified that the time recorded is the first time processing since the create operation or the Restart-Job operation. 49. Section 188.8.131.52 and 184.108.40.206 - clarified that the out-of-band value 'no-value' is returned if the job has not started processing or has not completed, respectively. 50. Section 4.3.14 - Added the OPTIONAL "date-time-at-creation", "date-time-at-processing", and "date-time-at-completed" Event Time Job Description attributes 51. Section 4.4.3 - added the 'tls' value to "uri-security- supported" attribute. 52. Section 4.4.3 - clarified "uri-security-supported" is orthogonal to Client Authentication so that 'none' does not exclude Client Authentication. 53. Section 4.4.11 - simplified the "printer-state" descriptions while generalizing to allow high end devices that interpret one or more jobs while marking another. Indicated that 'spool-area-full' and 'stopped-partly' "printer-state-reasons" may be used to provide further state information. 54. Section 4.4.12 - added the 'moving-to-paused' keyword value to the "printer-state-reasons" attribute for use with the Pause- Printer operation. 55. Section 4.4.12 - replaced the duplicate 'marker-supply-low' keyword with the missing 'toner-empty' keyword for the "printer-state-reasons" attribute. (This correction was also made before RFC 2566 was published). 56. Section 4.4.12 - clarified 'spool-area-full' "printer-state- reasons" to include non-spooling printers to indicate when it can and cannot accept another job. 57. Section 4.4.15 - added the enum values to the "operations- supported" attribute for the new operations. Clarified that the values of this attribute are encoded as any enum, namely 32-bit values. 58. Section 4.4.30 - clarified that the dateTime value of "printer-current-time" is on a "best efforts basis". If a proper date-time cannot be obtained, the implementation returns the 'no-value' out-of-band value. Also clarified that
the time zone NEED NOT be the time zone that the people near the device use and that the client SHOULD display the dateTime attributes in the user's local time. 59. Sections 4.4.36 and 4.4.37 - added the OPTIONAL "pages-per- minute" and "pages-per-minute-color" Printer Description attributes. 60. Section 5.1 - clarified that the client conformance requirements apply to clients controlled by an end user and clients in servers. 61. Section 5.1 - clarified that any response MAY contain additional attribute groups, attributes, attribute syntaxes, or attribute values. 62. Section 5.1 - clarified that a client SHOULD do its best to prevent a channel from being closed by a lower layer when the channel is flow controlled off by the IPP Printer. 63. Section 5.2 - clarified that the IPP object requirements apply to objects embedded in devices or that are parts of servers. 64. Section 5.2.2 - clarified that IPP objects MAY return operation responses that contain attribute groups, attribute names, attribute syntaxes, attribute values, and status codes that are extensions to this standard. 65. Section 6 - changed the terminology of "private extensions" to "vendor extensions" and indicated that they are registered with IANA along with IETF standards track extensions. 66. Section 6.7 - inserted this section on registering out-of-band attribute values with IANA as extensions. 67. Section 8.3 - clarified the use of URIs for each Client Authentication mechanism. 68. Section 8.5 - added the security discussion around the new operator/administrator operations. 69. Section 220.127.116.11 - added client-error-compression-not- supported (0x040F) 70. Section 18.104.22.168 - added client-error-compression-error (0x0410) 71. Section 22.214.171.124 - added client-error-document-format-error (0x0411) 72. Section 126.96.36.199 - added client-error-document-access-error (0x0412) 73. Section 188.8.131.52 - added server-error-multiple-document- jobs-not-supported (0x0509) 74. Section 14 - added 'a-white', 'b-white', 'c-white', 'd-white', and 'e-white' and clarified that the existing 'a', 'b', 'c', 'd', and 'e' values are size values. Added American, Japanese, and European Engineering sizes, filled out -transparent and - translucent media names and drawings for the synchro cut sizes.
75. Section 16 - softened the RECOMMENDATION for IPP Printer attributes in a Directory schema so that they can have equivalents. 76. Section 16 - added the OPTIONAL "pages-per-minute" and "pages-per-minute-color" Printer attributes to the Directory schema. 77. Section 16 - added OPTIONAL "multiple-document-jobs-supported" to the Directory schema. 78. Section 16 - added RECOMMENDED "uri-authentication-supported", "ipp-versions-supported", and "compression-supported" to the Directory schema. The following changes in semantics and/or conformance have been incorporated into this document: 1. Section 184.108.40.206 - allowed a Printer to localize the "detailed-status-message" operation response attribute, but indicated that such localization might obscure the technical meaning of such messages. 2. Section 3.1.8, 5.2.4, and 220.127.116.11 - Clients and IPP objects MUST support version 1.1 conformance requirements. It is recommended that they interoperate with 1.0. Also clarified that IPP Printers MUST accept '1.1' requests. It is recommended that they also accept '1.x' requests. 3. Section 18.104.22.168 and section 4.4.32 - changed the "compression" operation and the "compression-supported" Printer Description attribute from OPTIONAL to REQUIRED. 4. Sections 22.214.171.124 and 4.3.8 - changed "job-state-reasons" from RECOMMENDED to REQUIRED, so that "job-state-reasons" MUST be returned in create operation responses. 5. Sections 3.2.4, 3.3.1, 4.4.16, and 16 - changed Create- Job/Send-Document so that they MAY be implemented while only supporting one document jobs. Added the "multiple-document- jobs-supported" boolean Printer Description attribute to indicate whether Create-Job/Send-Document support multiple document jobs or not. Added to the Directory schema. 6. Section 4.1.9 - deleted 'text/plain; charset=iso-10646-ucs-2', since binary is not legal with the 'text' type. 7. Section 126.96.36.199 - added the RECOMMENDATION that a Printer indicate by printing on the job's job-start-sheet that auto- sensing has occurred and what document format was auto-sensed. 8. Section 4.2.4 - indicated that the "multiple-document- handling" Job Template attribute MUST be supported with at least one value if the Printer supports multiple documents per job
9. Section 188.8.131.52 - indicated that the 'job-restartable' job state reason SHOULD be supported if the Restart-Job operation is supported. 10. Section 4.3.8 - changed "job-state-reasons" from RECOMMENDED to REQUIRED. 11. Section 4.3.8 - clarified the conformance of the values of the "job-state-reasons" attribute by copying conformance requirements from other sections of the document so that it is clear from reading the definition of "job-state-reasons" which values MUST or SHOULD be supported. The 'none', 'unsupported-compression', and 'unsupported-document-format' values MUST be supported. The 'job-hold-until-specified' SHOULD be specified if the "job-hold-until" Job Template is supported. The following values SHOULD be supported: 'job- canceled-by-user', 'aborted-by-system', and 'job-completed- successfully'. The 'job-canceled-by-operator' SHOULD be supported if the implementation permits canceling by other than the job owner. The 'job-canceled-at-device' SHOULD be supported if the device supports canceling jobs at the console. The 'job-completed- with-warnings' SHOULD be supported, if the implementation detects warnings. The 'job-completed-with-errors' SHOULD be supported if the implementation detects errors. The 'job- restartable' SHOULD be supported if the Restart-Job operation is supported. 12. Section 4.3.10 - allowed a Printer to localize the "job- detailed-status-message" Job Description attribute, but indicated that such localization might obscure the technical meaning of such messages. 13. Section 4.3.14 - changed the "time-at-creation", "time-at- processing", and "time-at-completed" Event Time Job Description attributes from OPTIONAL to REQUIRED. 14. Section 184.108.40.206 - added the REQUIRED "job-printer-up-time (integer(1:MAX))" Job Description attribute as an alias for "printer-up-time" to reduce number of operations to get job times. 15. Section 4.4.2 - added the REQUIRED "uri-authentication- supported (1setOf type2 keyword)" Printer Description attribute to describe the Client Authentication used by each Printer URI. 16. Section 4.4.12 - changed "printer-state-reasons" Printer Description attribute from OPTIONAL to REQUIRED. 17. Section 4.4.12 - changed 'paused' value of "printer-state- reasons" to MUST if Pause-Printer operation is supported.
18. Section 4.4.14 - added the REQUIRED "ipp-versions-supported (1setOf keyword)" Printer Description attribute, since IPP/1.1 Printers do not have to support version '1.0' conformance requirements. Section 4.4.16 - added the "multiple-document- jobs-supported (boolean)" Printer Description attribute so that a client can tell whether a Printer that supports Create-Job/Send-Document supports multiple document jobs or not. This attribute is REQUIRED if the Create-Job operation is supported. 19. Section 4.4.24 - changed the "queued-job-count" Printer Description attribute from RECOMMENDED to REQUIRED. 20. Section 4.4.32 - changed "compression-supported (1setOf type3 keyword)" Printer Description attribute from OPTIONAL to REQUIRED. 21. Section 5.1 - changed the client security requirements from RECOMMENDED non-standards track SSL3 to MUST support Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A client SHOULD support Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. 22. Section 5.2.7 - changed the IPP object security requirements from OPTIONAL non-standards track SSL3 to SHOULD contain support for Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the Printer so that all, some, or none of the users are authenticated. An IPP Printer implementation SHOULD contain support for Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the degree of support for Operation Privacy and Server Authentication. Security MUST NOT be compromised when the client supplies a lower version-number in a request. 23. Section 14 (Appendix C): Corrected typo, changing the keyword 'iso-10-white' to 'iso-a10-white'. See also the "IPP/1.1 Encoding and Transport" [RFC2910] document for differences between IPP/1.0 [RFC2565] and IPP/1.1 [RFC2910].
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.