ftp.pwg.orgftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20150211-rev.docx · web view11.02.2015 · the...
TRANSCRIPT
The Printer Working Group
May 23, 2023Working Draft
IPP Implementor's Guide v2.0 (IG)(Updates RFC 3196)
Status: Stable
Abstract: This document updates and extends "Internet Printing Protocol/1.1: Implementor’s Guide" (RFC 3196) for all IPP protocol versions.
This document is a PWG Working Draft. For a definition of a "PWG Working Draft", see: ftp://ftp.pwg.org/pub/pwg/general/pwg-process30.pdf http://ftp.pwg.org/pub/pwg/general/pwg-process30.pdf
This document is available electronically at:
http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20150128.pdf
Copyright © 2014 The Printer Working Group. All rights reserved.
123456789
1011
12
13
14
15
1617
181920
21
22
The Printer Working Group
May 23, 2023Working Draft
http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20150211.pdf
Copyright © 2014 The Printer Working Group. All rights reserved.
23
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Copyright © 2015 The Printer Working Group. All rights reserved.
This document may be copied and furnished to others, and derivative works that comment on, or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice, this paragraph and the title of the Document as referenced below are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO.
Title: IPP Implementor's Guide v2.0 (IG)
The IEEE-ISTO and the Printer Working Group DISCLAIM ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED INCLUDING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The Printer Working Group, a program of the IEEE-ISTO, reserves the right to make changes to the document without further notice. The document may be updated, replaced or made obsolete by other documents at any time.
The IEEE-ISTO takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
The IEEE-ISTO invites any interested party to bring to its attention any copyrights, patents, or patent applications, or other proprietary rights which may cover technology that may be required to implement the contents of this document. The IEEE-ISTO and its programs shall not be responsible for identifying patents for which a license may be required by a document and/or IEEE-ISTO Industry Group Standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Inquiries may be submitted to the IEEE-ISTO by e-mail at: [email protected].
The Printer Working Group acknowledges that the IEEE-ISTO (acting itself or through its designees) is, and shall at all times, be the sole entity that may authorize the use of certification marks, trademarks, or other special designations to indicate compliance with these materials.
Use of this document is wholly voluntary. The existence of this document does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to its scope.
Page 3 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
12
24
2526272829303132
33
34353637
383940
4142434445
46474849505152
53545556
57585960
3
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
About the IEEE-ISTO
The IEEE-ISTO is a not-for-profit corporation offering industry groups an innovative and flexible operational forum and support services. The IEEE-ISTO provides a forum not only to develop standards, but also to facilitate activities that support the implementation and acceptance of standards in the marketplace. The organization is affiliated with the IEEE (http://www.ieee.org/ http://www.ieee.org/ ) and the IEEE Standards Association (http://standards.ieee.org/) http://standards.ieee.org/) .
For additional information regarding the IEEE-ISTO and its industry programs visit:
http://www.ieee-isto.orghttp://www.ieee-isto.org
About the IEEE-ISTO PWG
The Printer Working Group (or PWG) is a Program of the IEEE Industry Standards and Technology Organization (ISTO) with member organizations including printer manufacturers, print server developers, operating system providers, network operating systems providers, network connectivity vendors, and print management application developers. The group is chartered to make printers and the applications and operating systems supporting them work together better. All references to the PWG in this document implicitly mean “The Printer Working Group, a Program of the IEEE ISTO.” In order to meet this objective, the PWG will document the results of their work as open standards that define print related protocols, interfaces, procedures and conventions. Printer manufacturers and vendors of printer related software will benefit from the interoperability provided by voluntary conformance to these standards.
In general, a PWG standard is a specification that is stable, well understood, and is technically competent, has multiple, independent and interoperable implementations with substantial operational experience, and enjoys significant public support.
For additional information regarding the Printer Working Group visit:
http://www.pwg.org
Contact information:
The Printer Working Groupc/o The IEEE Industry Standards and Technology Organization445 Hoes LanePiscataway, NJ 08854USA
Page 4 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
45
61
626364656667
68
6970
71
7273747576777879808182
838485
86
87
88
899091929394
6
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
About the Internet Printing Protocol Work Group
The Internet Printing Protocol (IPP) working group has developed a modern, full-featured network printing protocol, which is now the industry standard. IPP allows a print client to query a printer for its supported capabilities, features, and parameters to allow the selection of an appropriate printer for each print job. IPP also provides Job information prior to, during, and at the end of Job processing.
For additional information regarding IPP visit:
http://www.pwg.org/ipp/
Implementers of this specification are encouraged to join the IPP mailing list in order to participate in any discussions of the specification. Suggested additions, changes, or clarification to this specification, should be sent to the IPP mailing list for consideration.
Page 5 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
78
95
96979899
100
101
102
103104105
9
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Table of Contents1. Introduction .......................................................................................................................92. Terminology ......................................................................................................................9
2.1 Conformance Terminology ..........................................................................................92.2 Imaging Terminology ..................................................................................................92.3 Other Terminology ....................................................................................................102.4 Acronyms and Organizations ....................................................................................11
3. Requirements .................................................................................................................123.1 Rationale ...................................................................................................................123.2 Use Cases ................................................................................................................12
3.2.1 Developer Implementing IPP Client Support ......................................................123.2.2 Developer Implementing IPP Printer Support .....................................................12
3.3 Out of Scope .............................................................................................................123.4 Design Requirements ...............................................................................................13
4. Client Tasks and Implementation Alternatives ................................................................134.1 Finding A Printer .......................................................................................................14
4.1.1 Discover And Select A Printer Via A Discovery Protocol ....................................144.1.2 Select A Printer Via Static Hostname Or Address ..............................................17
4.2 Validate Printer Reachability and User Access .........................................................194.3 Identify a Printer ........................................................................................................224.4 Get Printer Capabilities .............................................................................................244.5 Check Constraints Between Print Options ................................................................284.6 Submitting a Print Job ...............................................................................................31
4.6.1 Submitting a Job with document data .................................................................324.6.2 Submitting a Job with document references .......................................................354.6.3 Handling Print Job Creation Errors .....................................................................39
4.7 Submitting a FaxOut Job ..........................................................................................404.8 Performing a Scan Job .............................................................................................40
4.8.1 Performing a Pull Scan Job ................................................................................414.8.2 Performing a Push Scan Job ..............................................................................41
4.9 Monitoring Job Status ...............................................................................................414.10 Canceling a Print Job During Job or Document Creation ........................................464.11 Getting Printer Supplies Status ...............................................................................484.12 Error Handling .........................................................................................................50
5. Using and Evaluating IPP Attributes ...............................................................................505.1 Job Template Attributes And Value Binding ..............................................................51
5.1.1 IPP Client Recommendations .............................................................................515.1.2 IPP Printer Recommendations ...........................................................................51
5.2 Document Format Selection ......................................................................................525.2.1 IPP Client Recommendations .............................................................................525.2.2 IPP Printer Recommendations ...........................................................................52
5.3 Prefer "media-col" Attribute To "media" Attribute ......................................................525.3.1 IPP Client Recommendations .............................................................................535.3.2 IPP Printer Recommendations ...........................................................................53
5.4 Extended Finishings Options With "finishings-col-XXX" ............................................535.4.1 IPP Client Recommendations .............................................................................53
Page 6 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
1011
106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151
12
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
5.4.2 IPP Printer Recommendations ...........................................................................535.5 Controlling Intended Output Using "ipp-attribute-fidelity", "job-mandatory-attributes", and "pdl-override-supported" ..........................................................................................53
5.5.1 IPP Client Recommendations .............................................................................545.5.2 IPP Printer Recommendations ...........................................................................54
5.6 Prefer "multiple-document-handling" For Copies Collation .......................................555.6.1 IPP Client Recommendations .............................................................................555.6.2 IPP Printer Recommendations ...........................................................................55
5.7 Specify "orientation-requested" For Supported Document Types .............................555.7.1 IPP Client Recommendations .............................................................................555.7.2 IPP Printer Recommendations ...........................................................................55
5.8 Evaluating Printer Capability Attributes .....................................................................565.8.1 document-format-supported / document-format .................................................575.8.2 printer-get-attributes-supported ..........................................................................575.8.3 document-format-varying-attributes ....................................................................575.8.4 ipp-features-supported .......................................................................................585.8.5 printer-config-change-date-time and printer-config-change-time ........................585.8.6 xxx-supported and xxx-default ............................................................................585.8.7 xxx-supported vs. xxx-ready ...............................................................................595.8.8 job-creation-attributes-supported ........................................................................595.8.9 document-creation-attributes-supported .............................................................595.8.10 job-settable-attributes-supported ......................................................................595.8.11 media-col-ready vs. media-col-database ..........................................................59
5.9 Resolving Job Attribute Conflicts and Constraints ....................................................605.10 IPP Object Status Attributes ....................................................................................63
5.10.1 Printer Status ....................................................................................................635.10.2 Job Status ........................................................................................................635.10.3 Document Status ..............................................................................................63
5.11 IPP Notifications Attributes ......................................................................................636. IPP Document Page Order .............................................................................................647. IPP Printer Best Practices ..............................................................................................64
7.1 IPP Objects and URI Resource Paths ......................................................................647.2 Fax Destination URIs ................................................................................................657.3 Printer Resource URIs ..............................................................................................657.4 Error Reporting .........................................................................................................65
8. HTTP Protocol Use .........................................................................................................668.1 New HTTP/1.1 Specifications ...................................................................................66
8.1.1 HTTP Client ........................................................................................................668.1.2 HTTP Server ......................................................................................................66
8.2 HTTP/1.1 Expect Header ..........................................................................................668.2.1 HTTP Client ........................................................................................................678.2.2 HTTP Server ......................................................................................................67
8.3 "Host" Header Field ..................................................................................................688.3.1 HTTP Client ........................................................................................................688.3.2 HTTP Server ......................................................................................................68
8.4 If-Modified-Since, Last-Modified, and 304 Not Modified ...........................................68
Page 7 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
1314
152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197
15
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
8.4.1 HTTP Client ........................................................................................................688.4.2 HTTP Server ......................................................................................................68
8.5 Cache-Control ...........................................................................................................688.5.1 HTTP Client ........................................................................................................688.5.2 HTTP Server ......................................................................................................69
9. Security Considerations ..................................................................................................699.1 Client Security Considerations ..................................................................................69
9.1.1 HTTP/1.1 Expect Header ...................................................................................699.1.2 HTTP Upgrade ...................................................................................................699.1.3 Using The Validate-Job Operation .....................................................................699.1.4 Preferring The "ipps" URI Scheme .....................................................................69
9.2 Server Security Considerations .................................................................................709.2.1 HTTP/1.1 Expect Header ...................................................................................709.2.2 HTTP Upgrade ...................................................................................................709.2.3 Support For The "ipps" URI Scheme ..................................................................709.2.4 DNS Rebinding ...................................................................................................70
10. Important Implementation Options ................................................................................7010.1 Using "xxx-actual" attribute .....................................................................................7010.2 Printer Constraints Resolution via "preferred-attributes" .........................................71
11. Internationalization Considerations ...............................................................................7111.1 Client Considerations ..............................................................................................7111.2 Server Considerations ............................................................................................71
12. Conformance Requirements .........................................................................................7112.1 Client Conformance Requirements .........................................................................7112.2 Printer Conformance Requirements ........................................................................7112.3 Client Conditional Conformance Requirements ......................................................7112.4 Printer Conditional Conformance Requirements .....................................................72
13. References ...................................................................................................................7213.1 Informative References ...........................................................................................72
14. Annex A: HTTP/2.0 .......................................................................................................7515. Authors' Addresses .......................................................................................................7516. PlantUML Sequence Diagram Sources ........................................................................7617. Change History .............................................................................................................76
17.1 February 5, 2013 .....................................................................................................7617.2 March 20, 2013 .......................................................................................................7617.3 May 13, 2013 ..........................................................................................................7617.4 July 19, 2013 ...........................................................................................................7717.5 September 22, 2013 ...............................................................................................7717.6 October 2, 2013 ......................................................................................................7717.7 January 3, 2014 ......................................................................................................7817.8 January 24, 2014 ....................................................................................................7817.9 April 10, 2014 ..........................................................................................................7817.10 May 13, 2014 ........................................................................................................7917.11 August 14, 2014 ....................................................................................................7917.12 November 13, 2014 ..............................................................................................7917.13 January 27, 2015 ..................................................................................................80
Page 8 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
1617
198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243
18
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
1. Introduction .......................................................................................................................82. Terminology ......................................................................................................................8
2.1 Conformance Terminology ..........................................................................................82.2 Imaging Terminology ..................................................................................................82.3 Other Terminology ......................................................................................................92.4 Acronyms and Organizations ....................................................................................10
3. Requirements .................................................................................................................113.1 Rationale ...................................................................................................................113.2 Use Cases ................................................................................................................11
3.2.1 Developer Implementing IPP Client Support ......................................................113.2.2 Developer Implementing IPP Printer Support .....................................................11
3.3 Out of Scope .............................................................................................................113.4 Design Requirements ...............................................................................................12
4. Client Tasks and Implementation Alternatives ................................................................124.1 Finding A Printer .......................................................................................................13
4.1.1 Discover And Select A Printer Via A Discovery Protocol ....................................134.1.2 Select A Printer Via Static Hostname Or Address ..............................................16
4.2 Validate Printer Reachability and User Access .........................................................184.3 Identify a Printer ........................................................................................................214.4 Get Printer Capabilities .............................................................................................234.5 Check Constraints Between Print Options ................................................................274.6 Submitting a Print Job ...............................................................................................33
4.6.1 Submitting A Job With Document Data ..............................................................344.6.2 Submitting A Job With Document References ...................................................374.6.3 Handling Print Job Creation Errors .....................................................................41
4.7 Submitting a FaxOut Job ..........................................................................................424.8 Monitoring Job Status ...............................................................................................434.9 Canceling a Print Job During Job or Document Creation .........................................484.10 Getting Printer Supplies Status ...............................................................................514.11 Error Handling .........................................................................................................54
5. Using and Evaluating IPP Attributes ...............................................................................545.1 Job Template Attributes And Value Binding ..............................................................54
5.1.1 IPP Client Recommendations .............................................................................555.1.2 IPP Printer Recommendations ...........................................................................55
5.2 Document Format Selection ......................................................................................555.2.1 IPP Client Recommendations .............................................................................565.2.2 IPP Printer Recommendations ...........................................................................56
5.3 Prefer "media-col" Attribute To "media" Attribute ......................................................565.3.1 IPP Client Recommendations .............................................................................565.3.2 IPP Printer Recommendations ...........................................................................57
5.4 Extended Finishings Options With "finishings-col-XXX" ............................................575.4.1 IPP Client Recommendations .............................................................................575.4.2 IPP Printer Recommendations ...........................................................................57
5.5 Controlling Intended Output Using "ipp-attribute-fidelity", "job-mandatory-attributes", and "pdl-override-supported" ..........................................................................................57
5.5.1 IPP Client Recommendations .............................................................................58
Page 9 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
1920
244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289
21
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
5.5.2 IPP Printer Recommendations ...........................................................................585.6 Prefer "multiple-document-handling" For Copies Collation .......................................59
5.6.1 IPP Client Recommendations .............................................................................595.6.2 IPP Printer Recommendations ...........................................................................59
5.7 Specify "orientation-requested" For Supported Document Types .............................595.7.1 IPP Client Recommendations .............................................................................595.7.2 IPP Printer Recommendations ...........................................................................60
5.8 Evaluating Printer Capability Attributes .....................................................................605.8.1 document-format-supported / document-format .................................................615.8.2 printer-get-attributes-supported ..........................................................................615.8.3 document-format-varying-attributes ....................................................................625.8.4 ipp-features-supported .......................................................................................625.8.5 printer-config-change-date-time and printer-config-change-time ........................625.8.6 xxx-supported and xxx-default ............................................................................635.8.7 xxx-supported vs. xxx-ready ...............................................................................635.8.8 job-creation-attributes-supported ........................................................................635.8.9 document-creation-attributes-supported .............................................................645.8.10 job-settable-attributes-supported ......................................................................645.8.11 media-col-ready vs. media-col-database ..........................................................64
5.9 Resolving Job Attribute Conflicts and Constraints ....................................................645.10 IPP Object Status Attributes ....................................................................................67
5.10.1 Printer Status ....................................................................................................675.10.2 Job Status ........................................................................................................675.10.3 Document Status ..............................................................................................68
5.11 IPP Notifications Attributes ......................................................................................686. IPP Document Page Order .............................................................................................687. IPP Printer Best Practices ..............................................................................................69
7.1 IPP Objects and URI Resource Paths ......................................................................697.2 Fax Destination URIs ................................................................................................707.3 Printer Resource URIs ..............................................................................................707.4 Error Reporting .........................................................................................................70
8. HTTP Protocol Use .........................................................................................................708.1 New HTTP/1.1 Specifications ...................................................................................70
8.1.1 HTTP Client ........................................................................................................718.1.2 HTTP Server ......................................................................................................71
8.2 HTTP/1.1 Expect Header ..........................................................................................718.2.1 HTTP Client ........................................................................................................718.2.2 HTTP Server ......................................................................................................72
8.3 "Host" Header Field ..................................................................................................728.3.1 HTTP Client ........................................................................................................728.3.2 HTTP Server ......................................................................................................72
8.4 If-Modified-Since, Last-Modified, and 304 Not Modified ...........................................738.4.1 HTTP Client ........................................................................................................738.4.2 HTTP Server ......................................................................................................73
8.5 Cache-Control ...........................................................................................................738.5.1 HTTP Client ........................................................................................................73
Page 10 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
2223
290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335
24
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
8.5.2 HTTP Server ......................................................................................................739. Important Implementation Options ..................................................................................74
9.1 Job Receipts: The "xxx-actual" Attributes .................................................................749.2 Printer Constraints: The "preferred-attributes" Attribute ............................................74
10. Conformance Recommendations .................................................................................7410.1 Client Conformance Recommendations .................................................................7410.2 Printer Conformance Recommendations ................................................................74
11. Internationalization Considerations ...............................................................................7511.1 Client Considerations ..............................................................................................7511.2 Server Considerations ............................................................................................75
12. Security Considerations ................................................................................................7612.1 Client Security Considerations ................................................................................76
12.1.1 HTTP/1.1 Expect Header .................................................................................7612.1.2 HTTP Upgrade .................................................................................................7612.1.3 Using The Validate-Job Operation ...................................................................7612.1.4 Preferring The "ipps" URI Scheme ...................................................................76
12.2 Server Security Considerations ...............................................................................7612.2.1 HTTP/1.1 Expect Header .................................................................................7712.2.2 HTTP Upgrade .................................................................................................7712.2.3 Support For The "ipps" URI Scheme ................................................................7712.2.4 DNS Rebinding .................................................................................................77
13. References ...................................................................................................................7713.1 Informative References ...........................................................................................77
14. Annex A: HTTP/2.0 .......................................................................................................8115. Authors' Addresses .......................................................................................................8116. Change History .............................................................................................................81
16.1 February 5, 2013 .....................................................................................................8116.2 March 20, 2013 .......................................................................................................8216.3 May 13, 2013 ..........................................................................................................8216.4 July 19, 2013 ...........................................................................................................8216.5 September 22, 2013 ...............................................................................................8316.6 October 2, 2013 ......................................................................................................8316.7 January 3, 2014 ......................................................................................................8316.8 January 24, 2014 ....................................................................................................8416.9 April 10, 2014 ..........................................................................................................8416.10 May 13, 2014 ........................................................................................................8516.11 August 14, 2014 ....................................................................................................8516.12 November 13, 2014 ..............................................................................................8516.13 January 27, 2015 ..................................................................................................8516.14 February 11, 2015 .................................................................................................86
Page 11 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
2526
336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378
27
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
1. IntroductionIPP defines a rich set of operations and attributes to support the many tasks and features that exist in a networked printing ecosystem. With IPP, it is possible to perform some tasks in a few different ways. The quality of the user experience will be affected by how the tasks are performed. The goal of this specification is to provide IPP Client and Printer implementors with guidance on how to implement their system well from the start to ensure a quality user experience.
2. Terminology
2.1 Conformance Terminology
Capitalized terms, such as MUST, MUST NOT, RECOMMENDED, REQUIRED, SHOULD, SHOULD NOT, MAY, and OPTIONAL, have special meaning relating to conformance as defined in Key words for use in RFCs to Indicate Requirement Levels [RFC2119].[RFC2119]. The term CONDITIONALLY REQUIRED is additionally defined for a conformance requirement that applies to a particular capability or feature.
2.2 Imaging Terminology
Normative definitions and semantics of printing terms are imported from IETF Printer MIB v2 [RFC3805],[RFC3805], IETF Finisher MIB [RFC3806],[RFC3806], and IETF Internet Printing Protocol/1.1: Model and Semantics [RFC2911].[RFC2911].
This document also defines the following protocol roles in order to specify unambiguous conformance requirements:
Client: Initiator of outgoing IPP session requests and sender of outgoing IPP operation requests (Hypertext Transfer Protocol -- HTTP/1.1 [RFC7230][RFC7230] User Agent).
Device: A Logical or Physical Device associated with one or more Printers; also see section 2.3 of [RFC2911].[RFC2911].
Document: An object created and managed by a Printer that contains the description, processing, and status information. A Document object can have attached data and is bound to a single Job.
Logical Device: a print server, software service, or gateway that processes jobs and either forwards or stores the processed Job or uses one or more Physical Devices to render output.
Physical Device: a device that renders output (typically on paper.)
Page 12 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
2829
379
380381382383384385
386
387
388389390391392
393
394395396
397398
399400
401402
403404405
406407408
409
30
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Printer: Listener for incoming IPP session requests and receiver of incoming IPP operation requests (Hypertext Transfer Protocol -- HTTP/1.1 [RFC7230][RFC7230] Server) that represents one or more Physical Devices or a Logical Device.
Imaging Device: A printer or other device that acts as a Printer.
Job: An object created and managed by a Printer that contains description, processing, and status information. The Job also contains zero or more Document objects.
2.3 Other Terminology
Direct Imaging: Printing, facsimile, and scanning performed by direct communication from the Client to an Imaging Device or local print server.
Directory Service: A Service providing query and enumeration of information using names or other identifiers.
Discovery: Finding Printers by querying or browsing local network segments or Enumeration of Directory or Name Services.
Report An Error: An Action taken by an IPP Client that includes informing the User that an error has been detected, and logging the condition in a robust manner.
Enumeration: Listing Printers that are registered with a Directory or other Service.
Indirect Imaging: Printing, facsimile, and scanning performed by communication from the Client and/or Imaging Device to an intermediary service in a different administrative domain, for example when the Client communicates with a third-party print service or when an Imaging Device communicates with a Cloud service.
Network Accessible Device: A Device that can be directly accessed by a Client.
Network Accessible/Accessibility: Refers to the ability of one device to communicate directly with another, for example a Client is able to connect to a Device, query for supported attributes, submit Job creation requests, and so forth.
Operator: A person or automata that typically oversees the Printer. The Operator is allowed to query and manage the Printer, Jobs and Documents based on site policy.
Secure Print: A print Job using the "document-password", "job-password", and/or "job-password-encryption" operation attributes to provide document and/or physical security. See [PWG5100.11] [PWG5100.13], and [PWG5100.16].See [PWG5100.11], [PWG5100.13], and [PWG5100.16].
Service: Software providing access to physical, logical, or virtual resources assisting in the processing of queued Jobs.
Page 13 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
3132
410411412
413
414415
416
417418
419420
421422
423424
425
426427428429
430
431432433
434435
436437438439
440441
33
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
User: A person or automata using a Client to communicate with a Printer.
Zombie Job: A Job that was created using a Job Creation operation but that never had a Document associated with it, and that remains in a state of limbo.
2.4 Acronyms and Organizations
IANA: Internet Assigned Numbers Authority, http://www.iana.org/
IEEE: Institute of Electrical and Electronics Engineers, http://www.ieee.org/
IETF: Internet Engineering Task Force, http://www.ietf.org/
ISO: International Organization for Standardization, http://www.iso.org/
PWG: Printer Working Group, http://www.pwg.org/
Page 14 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
3435
442
443444
445
446
447
448
449
450
451
36
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
3. Requirements
3.1 Rationale
The "Internet Printing Protocol/1.1: Implementor's Guide" [RFC3196] was ratified in November 2001. Since that time many extensions to IPP have been ratified, and the scope of use of IPP has grown considerably. Given all these extensions to IPP, implementers will benefit from an updated best practices document that covers these extensions, as well as the core of IPP that has remained unchanged, to assist Client and Printer implementers in their efforts to provide the best possible user experience.
This specification defines a number ofasserts many normative requirements, but they are all recommendations using SHOULD. There are no MUST requirements in this specification.
3.2 Use Cases
3.2.1 Developer Implementing IPP Client Support
Garrett is a software engineer developing a new client platform that is adding system-level printing support. Many printers support IPP Everywhere [PWG5100.14],[PWG5100.14], so he plans to implement IPP Everywhere printing support in his client platform. But IPP Everywhere and its related standards don't describe how to best use IPP for the various tasks his software needs to perform to deliver a quality client user experience. He finds the "Internet Printing Protocol/1.1: Implementor's Guide" [RFC3196], but finds its Client recommendations insufficient. Using the IPPImplementor's Guide v2.0 (IG), he is able to avoid some common design pitfalls and quickly deliver a quality IPP client experience.
3.2.2 Developer Implementing IPP Printer Support
Duncan is a firmware engineer at a printer vendor creating a new printer, and that printer includes support for IPP Everywhere. In reading the IPP Implementor's Guidev2.0 (IG), he can more accurately anticipate how some segment of clients implemented according to these practices are likely to behave, and more rapidly understand how the various operations can be used with one another to achieve certain tasks.
3.3 Out of Scope
The following are out of scope for this specification:
Definition of extensions or modifications to the Internet Printing Protocol Normative MUST statements regarding user experience Definitions of new file formats or modifications of existing file formats
Page 15 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
3738
452
453
454455456457458459
460461462
463
464
465466467468469470471472473
474
475476477478479
480
481
482483484
39
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Definition of extensions or modifications to HyperTtext Transport Protocol [RFC7230][RFC7230]
3.4 Design Requirements
The design requirements for this specification are:
Identify common tasks performed by Clients and Printers Enumerate a series of implementation alternatives Rank those alternatives according to a qualitative grading scheme Discuss proper use of IPP attributes related to the implementation alternatives
and related implementation considerations, including security considerations
4. Client Tasks and Implementation AlternativesA user needs to do certain tasks in order to engage the user's computer with a printer. If that printer is an IPP Printer and the user's computer has an IPP Client, the IPP Client needs to perform certain tasks to provide a basic level of service to the user. A well-implemented Client also performs additional tasks to provide a high quality user experience. A fully featured and well-implemented IPP Client will support all the following tasks:
Find a Printer Validate Printer reachability and User accessibility Identify a Printer Get Printer capabilities Identify and resolve conflicts between a User's feature choices Submit a Job to a Printer, whether a Print Job, FaxOut Job, or Scan Job Monitor Job Status Cancel a Job Getting Printer Supplies Status
Each task is covered in this section, including descriptions of implementation alternatives. Each alternative will be labeled according to its perceived quality, using the following labels, which are listed in order from least desirable to most desirable:
BAD POOR FAIR GOOD BETTER BEST
The most preferred alternative for each task will always be labeled "BEST". Options labeled as "BAD", "POOR" or "FAIR" should be avoided.
Page 16 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
4041
485486
487
488
489490491492493
494
495496497498499500
501502503504505506507508509
510511512
513514515516517518
519520
42
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
The task implementations are described using UML sequence diagrams, which provide methods for describing parallel activity, asynchronous activity, iteration, logical branching, and similar constructs.
4.1 Finding A Printer
In order to use a Printer, the Client system needs to connect to it. For a connection to be established, the Client needs to first acquire the Printer's address.
Historically, setting up a printer on a client system included creating persistent local records for that printer to identify drivers needed to communicate at different levels. The number of printers or other devices the user’s system would encounter was small and fairly static. Network discovery protocols were not broadly used.
Recently, the relationship between Client and Printer has become more "dynamic". Clients discover available standardized print services matched to "universal" drivers rather than model-specific ones. These universal drivers acquire that print service instance's capabilities and other attributes by interrogating the chosen print service using sophisticated protocols such as IPP. Based on that, the universal driver provides a set of features based on device information rather than pre-distributed model information (model-specific drivers). This set of capabilities can be acquired at each time the User wishes to print, rather than once when the "print queue" has been created on the Client. In this paradigm, a persistent binding between a driver and a print service (what has historically been referred to as a "print queue") is more like a Web browser bookmark, and need not be persisted except as a "favorite" or "recently used printer" as a convenience to the User.
Even with the recent driver / printer interface standardization and widespread implementation, there are various use cases where the user acquires the Printer's DNS host name or network address and wishes to contact the Printer directly rather than looking it up via a service discovery or directory protocol. Examples of this include: the target printer does not reside within the scope that the discovery protocol service, or when the user has acquired a URI, host name or network address from a banner near the printer. These use cases will continue to be important for the foreseeable future.
4.1.1 Discover And Select A Printer Via A Discovery Protocol
Discovery protocols such as DNS-SD, SLP, WS-Discovery and UPnP SSDP, as well as directory protocols such as LDAP, allow a user to find instances of print services or printers without having to perform a survey in physical space to acquire devices' addresses. Service discovery queries are sent via broadcast or multicast to all hosts within scope, or unicast to a directory server. The query specifies the desired service types or device types. Replies to those queries are processed and presented to the user.
Page 17 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
4344
521522523
524
525526
527528529530
531532533534535536537538539540541542
543544545546547548549
550
551552553554555556557
45
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Regardless of the actual discovery protocol used, the APIs driving the protocols generally can be used in either a synchronous or asynchronous fashion. Unfortunately, many legacy software systems (as well as developers) are accustomed to the synchronous model, which is easily identified by the presence of a "refresh button". The synchronous model is not as user friendly as the asynchronous model, but it is somewhat easier to write programs in a synchronous way than an asynchronous way.
Alternatives
POOR:o Perform network discovery with a synchronous API; present static results
after short discovery process period; provide "Refresh" button to restart the process
Page 18 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
4647
558559560561562563
564
565566567568
569570
48
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 1: Discover and Select A Printer Via A Discovery Protocol - POOR
Page 19 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
4950
571
572
573
51
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BETTER:o Same as "POOR" above but user interface self-refreshes every few seconds
in a worker thread that refreshes the UI owned by the main thread (or equivalent).
Page 20 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
5253
574575576577578
579
54
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 2: Discover and Select A Printer Via A Discovery Protocol - BETTER
Page 21 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
5556
580
581
582
57
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST:o Perform network discovery with an asynchronous API for "live" results and
timely, responsive user experience
Page 22 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
5859
583584585
586587
60
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 3: Discover and Select A Printer Via A Discovery Protocol - BEST
4.1.2 Select A Printer Via Static Hostname Or Address
A Printer is identified in IPP by a URI. The URI identifies a specific resource that is relevant only on the host where the Printer resides. A URI is not typically provided directly to a User; a simple host name or network address is more common.
The "printer-uri-supported" Printer attribute enumerates the allowed URIs on the host system. This attribute can be retrieved via a Get-Printer-Attributes operation. This can be a circular problem since the Client must know at least one of the allowed resource paths to perform a Get-Printer-Attributes operation. If all Printers implement well-known resource paths, this problem can be avoided.
Page 23 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
6162
588
589
590
591
592593594
595596597598599600
63
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Alternatives
POOR: Each printer model chooses an arbitrary default resource path. The Client must depend on some mechanism out-of-band of IPP to get the resource path. This exposes too many protocol details to the User. Users need not be aware of which print protocol is being used.
Figure 4: Select A Printer Via Static Hostname Or Address - POOR
BETTER: Use a well-known, commonly specified resource path: "/ipp/print"o Not universally implemented
Page 24 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
6465
601
602603604605606
607
608
609
610611612
66
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
o Recommendation to be added to IPP Everywhere [PWG5100.14]
Figure 5: Select A Printer Via Static Hostname Or Address - BETTER
Page 25 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
6768
613
614615
616
617
618
69
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST: Get a list of all URIs supportedfor the default Print service, from a common, neutral resource path: "/"
o Allows variance and different Printer Objects to be foundo Not widely implemented, but recommended in IPP Everywhere
[PWG5100.14]
Figure 6: Select A Printer Via Static Hostname Or Address - BEST
4.2 Validate Printer Reachability and User Access
Once a Printer's address has been acquired, the Client ought to communicate with the Printer to confirm that the Printer is reachable by the Client. The Client SHOULD validate that the Printer is reachable via one of the IPP transports supported by the Client system. Once reachability has been validated, the Client SHOULD validate that the Printer would allow the User operating the Client to use it. The Client SHOULD validate reachability and user access as a precondition to acquiring the Printer's
Page 26 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
7071
619620621622623624
625
626
627
628
629630631632633634
72
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
capabilities, which can occur before submitting a Job or before creating a persistent queue or possibly both. If the User is allowed to set up the Client to use a particular Printer, but denied the use of that Printer, the User will most likely be disappointed. If the Printer implements IPPS [RFC-IPPS] and a self-signed TLS certificate, the Client user experience should be managed in such a way that it allows the user to establish trust with unfamiliar devices or credentials, without scaring them away or concealing important details.
Page 27 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
7374
635636637638639640641642
75
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Alternatives
BAD: Do Nothingo Reachability and access not checked; user could easily be disappointed
Figure 7: Validate Printer Reachability and User Access - BAD
FAIR: Validate reachability using a non-IPP protocol (ICMP echo, SNMP GET, etc.)o Validates reachabilityo No validation that IPP service is available on target hosto No validation that the user has access rights to the IPP Printer Object
Page 28 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
7677
643
644645646
647
648
649
650651652653654
78
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 8: Validate Printer Reachability and User Access - FAIR
BETTER: IPP Get-Printer-Attributeso Validates reachabilityo Validates IPP Printer object is available on target hosto No validation that the user has access rights to the IPP Printer Object
Page 29 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
7980
655
656
657
658659660661662
81
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 9: Validate Printer Reachability and User Access - BETTER
Page 30 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
8283
663
664
665
666
84
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST: IPP Get-Printer-Attributes + IPP Validate-Jobo Validates reachabilityo Validates IPP service is available on target hosto Validates user has access rights to the IPP Printer Object
Page 31 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
8586
667668669670
671672
87
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 10: Validate Printer Reachability and User Access - BEST
4.3 Identify a Printer
There are situations where a Client has discovered a Printer on a network, and the User would like to determine its location in physical space, so they can find where to retrieve their printed job. Or the user may want to confirm that the printer they are standing in front of is the printer found on the network. This is increasingly important for users who are printing from highly portable devices such as smartphones or tablets.
The Identify-Printer operation [PWG5100.13] provides a method for a Client to request that the Printer do something to identify itself. It is preferable for the Client to
Page 32 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
8889
673
674
675
676677678679680
681682683
90
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Alternatives
BAD: Client does nothing; User guesses which printero Subpar user experience
Figure 11: Identify a Printer - BAD
POOR: IPP Print-Job with special "identify page"o Only useful to validate the printer nearby is the printer discoveredo If it is the "wrong printer" the page will come out of an unexpected printero Printing throwaway pages for this purpose can annoy the Printer's owner
Page 33 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
9192
684
685686687
688
689
690
691692693694
93
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 12: Identify a Printer - POOR
Page 34 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
9495
695696
697
698
699
96
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST: IPP Identify-Printero Add audio indicators only if the user cannot find it using visual means alone,
to avoid causing audio disturbance to others nearby the Printer
Figure 13: Identify a Printer - BEST
4.4 Get Printer Capabilities
Once the user has selected a printer, the Client needs to determine the Printer's capabilities in order to whether and how it can produce Jobs the Printer can process. The Printer's capabilities will include supported Document formats, Job processing alternatives such as "number of copies", "2-sided printing", and perhaps other features. Some capabilities can vary depending on the Document format. It also includes other information about the device itself, such as its model type, location, and so forth.
Page 35 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
9798
700701702703
704
705
706
707
708709710711712713
99
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Traditionally, the Printer's capabilities would be acquired from the drivers bound to that Printer's print queue. A Client binds drivers by matching model identifiers in the driver with model identifiers acquired from the Printer. The Printer's capabilities were assumed to be relatively static; for the Client to get an up-to-date set of the Printer's capabilities the print queue would have to be destroyed and re-created. If driver matching fails because a driver was missing, the Client could not use the Printer because the queue would not get created. Deploying drivers before the user needed them was essential to avoid this problem.
Recently, "universal" printing systems such as IPP Everywhere have emerged that have enabled the Client / Printer relationship to become more dynamic. These systems define a base set of functionality along with methods to describe and use additional features that are agnostic to a particular Printer model. Clients that support these systems no longer depend on model-specific drivers to determine the Printer's capabilities if the Printer also supports the system. This also enables the Client to acquire a Printer's capabilities at the time the User indicates a desire to print. The Client can interrogate the Printer to determine its capabilities and present the available printing options in a just-in-time fashion. This enables more dynamic connection workflows that were impractical with the traditional model.
Alternatives
BAD: Assume all Printers have the same capabilitieso Example: a print queue using a "generic PPD"
Page 36 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
100101714715716717718719720721
722723724725726727728729730731
732
733734735
736
102
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 14: Get Printer Capabilities - BAD
Page 37 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
103104
737
738
739
105
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
POOR: Match model to matching driver (e.g. model-specific PPD file) to acquire list of options supported by the target device; match using non-IPP protocol(s)
o All "legacy style" model specific print drivers are an example of this alternative.
o Printer capability detection using feature identifiers is preferable to detection keying off a model identifier, especially in the case where the source is a statically authored knowledge such as a PPD
Figure 15: Get Printer Capabilities - POOR
Page 38 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
106107
740741742743744745746747
748
749
750
108
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Page 39 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
109110751
111
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
FAIR: Match model to matching driver (e.g. model-specific PPD file) to acquire list of options supported by the target device; match using IPP operations
o Using IPP rather than another protocol means only one protocol is used for printer capability evaluation and job submission, even with traditional driver use models
Page 40 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
112113
752753754755756757
758
114
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 16: Get Printer Capabilities - FAIR
Page 41 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
115116
759
760
761
117
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST (Option 1):: Perform 2a Get-Printer-Attributes operations. The firstoperation, sending "document-format" and other attributes that allow filtering. If needed, start with an initial Get-Printer-Attributes with no filtering attributes, or acquire Printer information via some other method, to get the liset of supported documents formats, and the second to filter the attributes to contain only those attributes and attribute values that specifically pertain to the document format.
BEST (Option 2): Detect whether the "printer-get-filterable attributes-supported" attribute is supported by the Printer, and if so, use its value to perform additional filtering from the Printer
Page 42 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
118119
762763764765766767768
769
770771772773
120
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Page 43 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
121122
774
123
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 17: Get Printer Capabilities - BEST
4.5 Check Constraints Between Print Options
Printer features and options are presented typically in a print dialog. Some of these have states that have relationships with other options' states, where one cannot be in a particular state if another one is too. These are known as "constraints". Constraints need to be re-evaluated any time a control changes state. There are a few different ways this can be done via IPP.
Page 44 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
124125
775
776
777
778779780781782
783
126
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Alternatives
BAD: Do nothing
Figure 18: Check Constraints Between Print Options - BAD
Page 45 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
127128
784
785786
787
788
789
790
129
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
POOR: Perform IPP Validate-Job every time a control changes Uses IPP but badly thrashes the network
Figure 19: Check Constraints Between Print Options - POOR
Page 46 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
130131
791792793
794
795
796
132
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
FAIR: Use local model-specific data (i.e. PPDs)o This is preferable because at least it doesn't thrash the network
Figure 20: Check Constraints Between Print Options - FAIR
Page 47 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
133134
797798799
800
801
802
803
135
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
GOOD:o IPP Validate-Job
When "Print" button is pressed, confirms the Job creation / submission will succeed (authentication, etc.)
Client depends on this operation to perform constraints validation printer-side, checking for errors along with "preferred-attributes"
Figure 21: Check Constraints Between Print Options - GOOD
Page 48 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
136137
804805806807808809810
811
812
813
814
138
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BETTER: Use "job-constraints-supported" and "job-resolvers-supported"
Figure 22: Check Constraints Between Print Options - BETTER
Page 49 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
139140
815816
817
818
819
820
141
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST: Use "job-constraints-supported" and "job-resolvers-supported" as well as IPP Validate-Job
Figure 23: Check Constraints Between Print Options - BEST
4.6 Submitting a Print Job
Once the user has selected the desired Job options, the print content is generated, and both the Job options and the content is made available to the printer so that it can be printed. There are several different ways this can be done with IPP.
Page 50 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
142143
821822823
824
825
826
827
828829830
144
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
The first set of alternatives a Client must consider involves how the Document content is conveyed to the Printer. The Client can submit document content via an IPP operation. Alternately, the Client can submit to the Printer a URI reference to a Document, with the expectation that the Printer will retrieve the Document itself at Job processing time.
IPP also provides two methods for requesting that a Printer create a new Job. They differ in the number of operations that are needed. The first method, supported by Print-Job and Print-URI, create the Job and provide the document content or reference all in one operation. The second method creates the Job using the Create-Job operation, submits Document content to the Job via separate Send-Document or Send-URI operations, and might conclude with a Close-Job operation. This second more verbose method is preferred because it provides more opportunities for the Printer to provide control over
[4.1.2] Submitting aA Job with document dataWith Document Data
This is the classical way that a print Job is sent from the Client to the print service: first a Job is created, and then the Job information and payload content are sent from the Client to the print service.
Alternatives
BADPOOR: Send the job with IPP Print-Jobo The printer can reject it but only after it has been transmitted. IPP would
never respond early; HTTP could respond early but that would be effectively a transport level exception outside the scope of IPP. Better to check ticket and content types first.
Page 51 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
145146831832833834835
836837838839840841842843
844
845
846847848
849
850851852853854855
147
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 24: Submitting A Job With Document Data - POOR
Page 52 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
148149
856
857
858
859
150
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
GOOD: Pre-flight the job with Validate-Job, then submit it using Print-Jobo Doesn’t work well with flow-controlled (low-end) printers
Page 53 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
151152
860861862
863
153
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 25: Submitting A Job with Document Data - GOOD
Page 54 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
154155
864
865
866
156
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BETTER: IPP Create-Job / IPP Send-Document
Figure 26: Submitting A Job with Document Data - BETTER
Page 55 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
157158
867868
869
870
871
872
159
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST: IPP Validate-Job / IPP Create-Job / IPP Send-Document / IPP Close-Job
Page 56 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
160161
873874
875
162
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 27: Submitting aA Job with document referencesDocument Data - BEST
4.6.1 Submitting A Job With Document References
This is a slightly different method for the Document content to be available to the Printer. The notion generally consists of creating a Job and then including in the Job references to documents that the Printer will itself "pull" into the Job. The documents might be on the Client but don't have to be.
This method can be potentially useful for working around certain network topology scenarios or limiting the need for the Client to be transmitting the content directly to the Printer across an expensive link. But there are risks to using this method. If the document is reachable by the Client system but not the Printer, the Job will fail. Reachability can be affected by network topology, authorization, or other factors. And since there can be a time delay between Job creation and Job processing, it could be that reachability problems are not discovered in a timely manner. Therefore, this Implementor's Guide generally advises against using this method unless robust mechanisms are in place to avoid such reachability issues; the Client SHOULD provide URIs that are stable for the life of the Job.
Page 57 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
163164
876
877
878
879880881882
883884885886887888889890891892
165
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Alternatives
POOR: IPP Print-URIo No pre-flight checkso Printer can reject it but only after it has been transmittedo Better to check ticket and content types first
Page 58 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
166167
893
894895896897898
899
168
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 28: Submitting A Job With Document References - POOR
Page 59 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
169170
900
901
902
171
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
GOOD: IPP Validate-Job / IPP Print-URIo URI might not be accessible at time of processing
Page 60 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
172173
903904905
906
174
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 29: Submitting A Job With Document References - GOOD
Page 61 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
175176
907
908
909
177
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BETTER: IPP Create-Job / IPP Send-URIo URI might not be accessible at time of processing
Page 62 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
178179
910911912
913
180
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 30: Submitting A Job With Document References - BETTER
Page 63 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
181182
914
915
916
183
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST: IPP Validate-Job / IPP Create-Job / IPP Send-URI / IPP Close-Jobo URI equivalent to §4.6.1; better to submit document data to avoid potential
URI accessibility issues
Page 64 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
184185
917918919920
921
186
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 31: Submitting A Job With Document References - BEST
4.6.2 Handling Print Job Creation Errors
If the IPP Printer reports an error during the process of creating the Job or submitting the Documents to that job, it is best if the Client takes action to ensure that the malformed Job doesn't turn into a "Zombie Job", which is a form of digital pollution.
Page 65 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
187188
922
923
924
925926927
928
189
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Alternatives
POOR: Do nothing; leave the malformed Job on the Printer
Figure 32: Handling Print Job Creation Errors - POOR
BEST: Use IPP Cancel-Job to cancel the job to clean up the malformed Job
Page 66 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
190191
929
930931
932
933
934
935936
192
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 334.6.3 Handling Print Job Creation Errors - BEST
4.7 Submitting a FaxOut Job
The process recommendations for submitting a Job to an IPP FaxOut service are identical to those in §4.6.1 and §4.6.2 for conventional Print Job submission.
[4.2] Performing a Scan Job
TBD - requesting contribution or remove
[4.2.1] Performing a Pull Scan Job
TBD - requesting contribution or remove
Page 67 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
193194
937
938
939
940
941942
943
944
945
946
195
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
[4.2.2] Performing a Push Scan Job
TBD - requesting contribution or remove
[4.3] Monitoring Job Status
While the Job is being processed, users might wish to know whether it is proceeding successfully, or whether there are conditions that they need to handle that are preventing processing from proceeding, such as a media jam, open covers, marking agents depleted, and so forth.
To provide this using IPP, a Client SHOULD monitor the status of the various IPP objects involved, including the Printer, the Job, and Documents within that Job. A Client SHOULD monitor the status of a Job submitted to a Printer and SHOULD continue to monitor it until it has been successfully printed.
The basic system for monitoring IPP object status is to periodically submit one or more IPP operations to retrieve these objects' status. Obviously, this is "polling", and as with most polling based systems, this doesn't scale well and causes frequent unnecessary updates to be communicated. Ideally, this would be avoided and replaced with a system based on asynchronous event notifications.
IPP has an event notification system ([RFC3995], [RFC3996], [RFC3997]). Unfortunately, this system has been largely overlooked. Both IPP Clients and Printers can support IPP notifications to minimize network traffic and monitoring overhead. Section 5.11 discusses this in more detail.
For those options below that involve polling the Printer Object, the degree to which the option is better or worse is due in no small part to the polling frequency. The interval SHOULD be tuned so that the frequency of queries is not so great that it burdens the Printer Object or Job Object or the network, but not so small that there is an undesirable lag between when an event occurs and when the user is notified. It is always a bad practice in any case if a Client is polling as fast as the network can handle traffic. When polling the Printer Object, the Client SHOULD NOT poll as fast as the network can handle traffic; it SHOULD instead tune its polling interval to achieve a suitable balance between user responsiveness and resource overuse.
In some cases the Client will cease monitoring the Job once the Job Creation or Document Creation operations have concluded. There are many scenarios where the User would prefer to be notified about Job status until the Job has finished being processed. For example, with a Job requesting 500 copies of a document containing 4 pages, the Job Creation operations most likely will conclude minutes before the Job has concluded being processed by the Printer. A well-implemented Client SHOULD monitor Job status until the Job has reached a terminal state. If IPP Subscriptions are used, these notifications can be monitored and received quite a long time after the Job Creation operations have been performed.
Page 68 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
196197947
948
949
950951952953
954955956957
958959960961962
963964965966
967968969970971972973974975
976977978979980981982983984
198
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Page 69 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
199200985
201
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Alternatives
BAD: Poll Printer for general Printer status instead of precise Job statuso Polling all status information needlessly uses a large number of resources
(network bandwidth, printer CPU)o Polling for status without the actual Job ID is imprecise
Figure 34: Monitoring Job Status - BAD
Page 70 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
202203
986
987988989990991
992
993
994
995
204
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
POOR: Poll for Job status using Get-Job-Attributeso Monitor the Job with ID acquired earlier, according to a polling interval
Figure 35: Monitoring Job Status - POOR
Page 71 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
205206
996997998
999
1000
1001
1002
207
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
GOOD: Monitor both Job and Printer status, but restricting Printer status to only attributes germane to status monitoring
o Monitor the value of "printer-state" attribute as well as targeted monitoring of a specific job's status
o Only ask for the attributes you need, to minimize the bandwidth needed for the information being used.
Page 72 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
208209
1003100410051006100710081009
1010
210
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 36: Monitoring Job Status - GOOD
Page 73 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
211212
1011
1012
1013
213
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BETTER: Use IPP Event Notifications and Subscriptions [RFC3995] Asynchronous / long running queries for notifications that don’t require
polling When Job has completed, query the state of that job Printer state changes will be provided by subscribing to the printer;
subscribing to the Job will provide less information and not be as useful
Page 74 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
214215
10141015101610171018101910201021
1022
216
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 37: Monitoring Job Status - BETTER
Page 75 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
217218
1023
1024
1025
219
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST: Create the Job using methods in section 4.6 and include the Subscriptions group in the Job Creation operation request; then monitor using the IPP Event Notifications and Subscriptions method [RFC3995]
o Most optimal if IPP Create-Job / IPP Send-Document is used so that the Job URI is positively sent by the Printer Object
Page 76 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
220221
102610271028102910301031
1032
222
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 38: Monitoring Job Status - BEST
4.8 Canceling a Print Job During Job or Document Creation
Situations arise where the user wants to terminate a Job before it is processed. This can occur before the Job's Documents have been completely transmitted to the Printer, or it might occur after the Job has been created but is awaiting processing. If the Job has already been completely created successfully, the Job can be terminated simply using an IPP Cancel-Job operation.
If the Job hasn't been fully created yet there is the risk that artifacts of that incomplete Job might remain. A well-implemented Client SHOULD clean up such artifacts if the Job is not completely created or it’s Documents not all submitted; leaving broken Job objects abandoned on the Printer is bad form.
There is some a dependency between the options below and how the Job was submitted. Adopting a high quality option from those listed below will likely depend on implementing a high quality option from §4.6.
Page 77 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
223224
1033
1034
1035
10361037103810391040
1041104210431044
104510461047
225
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Alternatives
BAD: Stop sending octets and abandon the connectiono Abandoned connection after some successful data transmission may allow
Job artifacts to linger
Figure 39: Canceling a Print Job During Job or Document Creation - BAD
Page 78 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
226227
1048
1049105010511052
1053
1054
1055
228
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Page 79 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
229230
1056
231
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
GOOD: Stop sending on a page boundary; properly terminate Document during IPP Print-Job operation; IPP Cancel-Job to cancel the Job object
Page 80 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
232233
105710581059
1060
234
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 40: Canceling a Print Job During Job or Document Creation - GOOD
Page 81 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
235236
1061
1062
1063
237
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BEST: Stop sending on a page boundary; properly terminate Document during IPP Send-Document operation; IPP Cancel-Job to cancel the Job object
Page 82 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
238239
106410651066
1067
240
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 41: Canceling a Print Job During Job or Document Creation - BEST
4.9 Getting Printer Supplies Status
Some administrative tasks, like checking or monitoring consumables levels, are presented to Users in print dialogs or job status dialogs. It could also be monitored by printer management software or device status monitoring software on User systems. A well implemented Client SHOULD provide supplies status. Ideally, the Client would check supplies status using publicly specified extensions to IPP.
Alternatives
BAD: Don't provide supplies statuso Not good for users or printer vendors
Page 83 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
241242
1068
1069
1070
10711072107310741075
1076
107710781079
243
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
POOR: Use some proprietary protocol or (possibly closed) platform-specific extension to IPP
o This falls short of the ideal that all devices implement a publicly specified and open extension to IPP
o Private extensions to IPP are less desirable than a publicly specified and open protocol other than IPP
GOOD: SNMP and standard printer MIBso Public standard but not IPP, so not ideal
Page 84 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
244245
1080108110821083108410851086
108710881089
1090
246
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 42: Getting Printer Supplies Status - GOOD
Page 85 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
247248
1091
1092
1093
249
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
BETTER: IPP Get-Printer-Attributes to retrieve "printer-supply" attributeo Printer needs to implement "printer-supply" attributeo Supplies events in polling model can monitor "printer-state-reasons" for
'marker-toner-low' and similar states
Figure 43: Getting Printer Supplies Status - BETTER
BEST: Monitor supplies status using the IPP Event Notifications and Subscriptions method [RFC3995]
o Printer needs to implement "printer-supply" attribute to support this scenarioo Printer MAY send affected attributes, e.g. "printer-supply", "printer-input-
tray", "printer-output-tray", etc.
Page 86 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
250251
10941095109610971098
1099
1100
1101
110211031104110511061107
252
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Figure 44: Getting Printer Supplies Status - BEST
Page 87 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
253254
1108
1109
1110
255
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
4.10 Error Handling
When a Client receives notice of an error, there are various ways to present that to the Client's user. Possible response actions include: presenting messages to the user; flagging or filtering those messages to indicate their severity and recoverability; and logging the event in an appropriate way.
A Client SHOULD log errors using the PWG Common Log Format [PWG5110.3].
5. Using and Evaluating IPP AttributesSome attributes that IPP has labeled as optional should always be used as a best practice. Below are some of these attributes and how they should be used in various contexts.
5.1 Job Template Attributes And Value Binding
While it is technically possible for a Client to only send those Job Template attributes whose values do not match the default values, this strategy should be avoided. If the default were to change between Job submission time and Job processing time, the resulting print Job might not meet user expectations. These default values should only be used for setting the initial state of Job Template attribute choice options for the User. This not only ensures the user’s expectations are met; it also makes implementing the client simpler because the Client doesn’t need to maintain any knowledge of whether the value chosen by the user matches the default provided by the Printer when the Job Template attributes were fetched to populate the user selection choices.
A Printer conveys its Job Template attributes’ default values using the “xxx-default” attributes. These attributes indicate the value the Printer will use if the Client does not provide that Job Template attribute at Job Creation time. The "xxx-actual" attributes reported by the IPP Printer in its operation response will report the values that are bound to the Job.
Using the “sides” Job Template attribute as an example, if the Printer reports that “sides-default” is 'one-sided' and “sides-supported” is {‘one-sided', 'two-sided-long-edge', 'two-sided-short-edge’}, a well-implemented Client SHOULD populate its "sides" Job option choice with the value from "sides-default": 'one-sided'. If the user makes some other choice, then the "sides" attribute would be updated to hold that new value. Once the user was satisfied with the choices and had requested the Job be printed, the Client would include the “sides” attribute and the value it holds in the Job Creation operation. Changes on the Printer to "sides-default" between the time the Job was submitted and the time it is processed will have no effect on the Job.
To help eliminate these pitfalls even for Clients that are poorly implemented and don't submit attributes that match the "xxx-default", a well-implemented Printer MAY bind Job
Page 88 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
256257
1111
1112111311141115
1116
1117
111811191120
1121
112211231124112511261127112811291130
11311132113311341135
113611371138113911401141114211431144
11451146
258
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Template attribute default values to each Job Template attribute at Job Creation time rather than waiting to do so at Job processing time, to help ensure user expectations.
5.1.1 IPP Client Recommendations
A Client SHOULD plan to submit all Job template attributes at Job creation time. A Client SHOULD set the initial state of each Job Template attribute to the corresponding Job Template attribute default value, if one exists.
5.1.2 IPP Printer Recommendations
A Printer SHOULD make that value binding visible to Clients as soon as possible by setting the xxx-actual Job Status attribute using that value as well.
5.2 Document Format Selection
A Client uses the “document-format” attribute in several ways. The Client evaluates the Printer’s document-format-supported attribute to decide on the most appropriate document format type. Once the Client has selected a format, it should perform a second Get-Printer-Attributes operation including "document-format" in the request, to request the Printer send the set of Job Template attributes and attribute values that correspond to that document format. This is discussed in detail in §4.4.
Several factors, including time delays between Job receipt and Job processing as well as implementation challenges, can prevent an IPP Printer from receiving robust and timely feedback from its document format interpreter and rendering engine about the document content submitted with a job. It is important for the Client to be as descriptive as possible about the construction of the Job, including not only that Job’s IPP attributes but also accurately reporting the document format for each Document associated with that Job.
5.2.1 IPP Client Recommendations
As with all other Job Template attributes, a Client SHOULD include the "document-format" attribute with all Job creation operations, with the value set to the actual MIME Media type of the document format to be submitted to the Printer. A Client SHOULD NOT submit a Job with the “document-format” attribute specifying “application/octet-stream” as the document format.
5.2.2 IPP Printer Recommendations
A Printer SHOULD NOT implement 'application/octet-stream' as the only document format. A Printer SHOULD list all the document formats it supports (even vendor-specific ones) via the "document-format-supported" attribute. A Printer SHOULD NOT use 'application/octet-stream' as its "document-format-default".
Page 89 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
259260
11471148
1149
115011511152
1153
11541155
1156
115711581159116011611162
1163116411651166116711681169
1170
11711172117311741175
1176
1177117811791180
261
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
A Printer SHOULD send the "document-format-actual" attribute in relevant IPP responses to report the detected MIME media type. If a request contains a document payload, the Printer SHOULD send the "document-format-actual" attribute value in the IPP operation response. The value of "document-format-actual" SHOULD be the detected format of the payload, not simply the value of the "document-format" attribute sent by the Client in the request.
5.3 Prefer "media-col" Attribute To "media" Attribute
The "media-col" attribute provides finer and more reliable control over media selection. As an example, the "media-col.media-size" sub-attribute is defined using integer value types rather than floating point value types, which avoids floating point calculation problems when converting between PWG size names and dimensions.
5.3.1 IPP Client Recommendations
Given a Printer Object that supports both "media" and "media-col" attributes, a Client SHOULD prefer to use the "media-col" attribute with operations that accept it. This is true for when "media" and "media-col" are top-level attributes as well as when "media" or "media-col" might be included within other collection attributes, such as "job-sheets", "job-error-sheet", "job-accounting-sheets", and others.
5.3.2 IPP Printer Recommendations
The Printer SHOULD allow for a limited degree of inaccuracy even with "media-col.media-size". If the dimensions are off by a small amount (1-3 units) this SHOULD NOT be regarded by the Printer as a mismatch.
For more discussion of the "media-xxx" attributes, see §5.8.11.
5.4 Extended Finishings Options With "finishings-col-XXX"
The IPP "finishings", "finishings-supported" and "finishings-default" attributes [RFC2911][RFC2911] define a basic mechanism for describing finishings capabilities. The "finishings-col-XXX" attributes [PWG5100.1] [PWG5100.3] extend the "finishings-XXX" attribute set by providing a mechanism to convey detailed description of finishing settings. In certain contexts, it is advantageous to use "finishings-col" rather than "finishings" to describe the finishings options, if the Printer supports both. A Printer can precisely describe the implementation underlying each "finishings" keyword using corresponding "finishings-col-database" and "finishings-col-ready" entries. A Client can use these detailed descriptions to provide an accurate print preview, and also provide a scalable user experience that can be simple but allow more detailed user control if desired.
Page 90 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
262263
118111821183118411851186
1187
1188118911901191
1192
11931194119511961197
1198
119912001201
1202
1203
12041205120612071208120912101211121212131214
264
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
5.4.1 IPP Client Recommendations
A Client SHOULD support "finishings-col-XXX" [PWG5100.1] to allow it to acquire from the Printer detailed descriptions of each value listed in "finishings-supported". This is especially important if the Client needs to map between IPP and JDF or other rich Job ticket formats.
5.4.2 IPP Printer Recommendations
A Printer SHOULD support IPP Finishings 2.0 [PWG5100.1].
5.5 Controlling Intended Output Using "ipp-attribute-fidelity", "job-mandatory-attributes", and "pdl-override-supported"
There are two attributes that might be used by a Client to control whether a print Job will print EXACTLY as requested, or alternately print with "best effort" but might not comply with all requested Job attributes. These attributes are listed below, each with a synopsis of their meaning and purpose.
ipp-attribute-fidelity [RFC2911][RFC2911] - Attribute provided by IPP Client in Job submission operations. If absent the IPP Printer will assume the value is "false". If present and value is "true" then the IPP Printer is required to support all Job attributes and attribute values included in the Job submission operation or else the IPP Printer is required to reject the operation.
job-mandatory-attributes [PWG5100.7] - Identifies which Job Template attributes the Printer is required to support in this Job Creation request in order to accept the Job. This allows the IPP Client to specify at a finer level of granularity those attributes that need to be supported. If job-mandatory-attributes is included and it lists all the Job attributes, this is equivalent to including the ipp-attribute-fidelity attribute with value set to "true".
Additionally, a Client can use the following attribute to determine whether the IPP Printer can prefer IPP provided attributes to attributes embedded in the document content itself.
pdl-override-supported [RFC2911][RFC2911] - Specifies whether the printer is capable of overriding Job attributes embedded in the Job document(s) with IPP Job attributes, and with what level of reliability: "attempted" [RFC2911],[RFC2911]; "not-attempted" [RFC2911],[RFC2911]; or "guaranteed" [PWG5100.11]. [PWG5100.11].
5.5.1 IPP Client Recommendations
Given these descriptions, a Client SHOULD comply with the following guidelines:
Do not always specify "ipp-attribute-fidelity" = 'true' because this can have unintended side effects, such as output scaling, etc.
Page 91 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
265266
1215
1216121712181219
1220
1221
12221223
1224122512261227
12281229123012311232
123312341235123612371238
123912401241
1242124312441245
1246
1247
12481249
267
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
If available prefer "job-mandatory-attributes" over "ipp-attribute-fidelity"
Regard "pdl-override-supported" = 'attempted' as functionally equivalent to "pdl-override-supported" = 'not-attempted', because there is nosince neither guarantee overrides.
Don't expect 'guaranteed' to be available, especially for complex PDLs, since it is impractical to implement with all but the simplest document formats.
Don't expect 'guaranteed' to be 100% trustworthy with complex PDLs, since implementing that guarantee would be impractical to implement.
Provide document data that is the correct size, etc. to avoid overrides and not depend on the IPP Printer to perform these overrides unless it can guarantee it.
5.5.2 IPP Printer Recommendations
A Printer SHOULD comply with the following guidelines regarding how to support "ipp-attribute-fidelity", "job-mandatory-attributes", and "pdl-override-supported":
The Printer SHOULD support "job-mandatory-attributes"
The Printer SHOULD support 'guaranteed' for "pdl-override-supported" for JPEG and PWG Raster document formats.
5.6 Prefer "multiple-document-handling" For Copies Collation
Although there was a time where specifying multiple copies of a Job would by default produce an un-collated collection of copies, when a User asks for multiple copies the User's expectation is almost always that the Job will produce a collated collection of copies. Despite this User expectation, for historical reasons the print systems have assumed un-collated to be the norm.
The "sheet-collate" attribute [RFC3381] "specifies whether or not the media sheets of each copy of each printed document in a Job are to be in sequence, when multiple copies of the document are specified by the ’copies’ attribute". The IPP Client likely doesn't want to collate sheets, but rather collate copies of the Job. The "multiple-document-handling" Job Template attribute provides these semantics. Although ("Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] §4.2.4) asserts that the "multiple-document-handling" attribute is relevant only if a Job consists of two or more documents, this attribute provides the desired semantics outside that context as well.
[PWG 5100.13]"IPP: Job and Printer Extensions – Set 3 (JPS3)" [PWG5100.13] §10 provides a detailed discussion of the relationship between Impressions, Pages and Sheets, and attributes that influence how the various Job Template attributes affect these metrics.
Page 92 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
268269
1250
125112521253
12541255
12561257
12581259
1260
12611262
1263
12641265
1266
12671268126912701271
127212731274127512761277127812791280
1281128212831284
270
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
5.6.1 IPP Client Recommendations
A Client SHOULD request collation for multiple copies of a Job using the "multiple-document-handling" attribute with its value set to "separate-documents-collated-copies" if the Printer supports the "multiple-document-handling" attribute.
5.6.2 IPP Printer Recommendations
A Printer SHOULD implement "multiple-document-handling" to allow a Client to request collated copies of a Job.
5.7 Specify "orientation-requested" For Supported Document Types
A Client uses the "orientation-requested" attribute [RFC2911][RFC2911] §4.2.10 to convey the desired orientation of the pages for a Job or Document in a Job. Although some document type formats provide a mechanism to express page orientation, others do not.
5.7.1 IPP Client Recommendations
If "orientation-requested-supported" is in the filtered list of Job Template attributes for the chosen document format, a Client SHOULD provide the "orientation-requested" attribute with the Job or with each Document submitted to an IPP Job.
5.7.2 IPP Printer Recommendations
A Printer SHOULD implement "orientation-requested" for the PDLs it supports that lack a mechanism to specify page orientation.
5.8 Evaluating Printer Capability Attributes
Before creating a Job, a Client SHOULD query the IPP Printer to evaluate its capabilities. Techniques for doing this using different sequences of operations are described in §4.3. When responding to an IPP Get-Printer-Attributes request, the Printer filters the set of attributes and values [RFC2911][RFC2911] to those that are acceptable to a Job Creation, Validate-Job, and Validate- Document operation...
IPP Client implementations SHOULD evaluate the attributes listed in Table 1, which lists the Printer attributes that are discussed in the following subsections.
Table 1: Printer Capability Attributes A Client Should Evaluate
Attribute Name Reference
Description
document-format- RFC 2911 Lists the set of supported document
Page 93 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
271272
1285
128612871288
1289
12901291
1292
1293129412951296
1297
129812991300
1301
13021303
1304
13051306130713081309
13101311
1312
273
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
supported formats
printer-get-attributes-supported
PWG 5100.13
Lists the set of attributes a Client can send to the Printer in a Get-Printer-Attributes operation request that the Printer can employ to filter the set of Job Template attributes it sends back in its response
document-format-varying-attributes
RFC 3380 Lists the attributes whose defaults or range of supported values vary by document format
ipp-features-supported PWG 5100.13
Lists the set of optional functionality the printer supports
printer-config-change-date-time
PWG 5100.13
Helps a Client or operator to determine how recently any of the Printer description attributes has been changed; useful if the Client is caching printer defaults and capabilities
printer-config-change-time
PWG 5100.13
Helps a Client or operator to determine how recently any of the Printer description attributes has been changed; useful if the Client is caching printer defaults and capabilities
job-creation-attributes-supported
PWG 5100.11
Lists the keyword names of the Job Template and operation attributes that the Printer will accept in Job Creation operations or a Validate-Job operation
document-creation-attributes-supported
PWG 5100.5
Lists the keyword names of the Document Template and operation attributes that the Printer will accept in Document Creation operations (Send-Document, Send-URI) or a Validate-Document operation
IPP Client implementations SHOULD NOT evaluate the attributes listed in Table 2.
Table 2: Printer Capability Attributes A Client Should AVOID
Attribute Name Reference
Description
Page 94 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
274275
1313
1314
276
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
??? ??? ???
??? ??? ???
5.8.1 document-format-supported / document-format
One of the most elemental tasks that a Client performs is choosing a print Job document format. The Printer's "document-format-supported" attribute enumerates the document formats supported by the Printer. How the Client chooses the particular document format is beyond the scope of this specification.
Once the Client has chosen a format, it SHOULD send a second Get-Printer-Attributes operation request, including the "document-format" attribute. As is described in §4.4, the Client does this to receive the list of Printer and Job Template attributes filtered to correspond to that specific document format. In this way, the Client can get a set of Printer capabilities the accurately describe the possible options supported by the Printer for that document format, with unsupported attributes and values filtered out [RFC2911]. Further filtering can be done using attributes listed in the Printer's "printer-get-attributes-supported" attribute, described in §5.8.2.
5.8.2 printer-get-attributes-supported
The "printer-get-attributes-supported" attribute [PWG5100.13][PWG5100.13] enumerates those attributes that can be included in a Get-Printer-Attributes request to influence the attributes and attribute values sent by the Printer in its Get-Printer-Attributes operation response. This attribute is useful to a Client because it allows it to further filter the Printer's capabilities so that the options provided to a user can be more tightly constrained. Ideally a user will be presented as many options as are supported but no more.
If a Printer supports the "printer-get-attributes-supported" attribute, a Client SHOULD include only attributes whose names are listed in that attribute when performing follow-up Get-Printer-Attributes operations as described in §4.4; otherwise, the Printer might reject the operation or the operation response might contain unfiltered information, which the Client would likely not expect.
5.8.3 document-format-varying-attributes
The "document-format-varying-attributes" attribute [RFC3380][RFC3380] is a Printer attribute that lists the Printer attributes that might vary depending on the document format. While this attribute was designed for use by a management Client engaged in manipulating the state of the Printer via Set-Printer-Attributes operations, a Client can use it in the process of submitting a Job to identify those attributes that could have different values depending on the document format.
Page 95 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
277278
1315
1316
1317131813191320
13211322132313241325132613271328
1329
1330133113321333133413351336
13371338133913401341
1342
134313441345134613471348
279
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
This attribute is useful to a Client because it provides another mechanism to detect attributes or attribute value ranges that could vary depending on the document format.
5.8.4 ipp-features-supported
The "ipp-features-supported" Printer attribute [PWG5100.13] provides a mechanism for listing support for a particular IPP extension feature. A feature can be comprised of multiple attributes, can also include new operations, and can have associated semantics defined as well. Examples of these features from [PWG5100.13] include "document-object", "job-save", "page-overrides", "proof-print", and "subscription-object". Other IPP specifications can define their own keywords and associated meanings, which are context-specific. It can be difficult to switch a feature on based solely on the existence of a particular set of attributes or attribute values.
This attribute is useful because it provides a way for a Client to easily enable potentially complex feature support without having to rely on more complicated heuristic analysis and interpolation of the attributes that are used to support the feature.
5.8.5 printer-config-change-date-time and printer-config-change-time
The "printer-config-change-date-time" and "printer-config-change-time" Printer attributes [PWG5100.13] provide 2 different representations of the most recent time at which the printer-config-changed Printer Event occurred.
This attribute is useful because a Client that records and subsequently monitors this attribute will be able to decide whether it needs to re-evaluate the printer's attributes or whether a cached set of values can be used.
5.8.6 xxx-supported and xxx-default
[RFC2911]"Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] §4.2 provides a set of rules for specifying how a Job Template attribute is defined. Generally a Job Template attribute is defined in a cluster of 3, including the attribute itself ("xxx"), an attribute that conveys the range of possible values that "xxx" can contain ("xxx-supported"), and an attribute that conveys the current default value ("xxx-default") that the Printer will use if that attribute isn't provided by the Client at Job submission time.
The "xxx-supported" and "xxx-default" attributes are reported to the Client using a Get-Printer-Attributes operation. These values can change if the Client includes attributes with the Get-Printer-Attributes operation such as "document-format" as discussed in §5.8.1 or one of the attributes enumerated by the "printer-get-attributes-supported" attribute as discussed in §5.8.2.
A Client SHOULD always provide all intended and applicable Job Template attributes explicitly in its operation requests; a Client SHOULD NOT depend on default values, because the default can change before the Job is processed.
Page 96 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
280281
13491350
1351
13521353135413551356135713581359
136013611362
1363
136413651366
136713681369
1370
1371137213731374137513761377
13781379138013811382
138313841385
282
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
5.8.7 xxx-supported vs. xxx-ready
Most Job Template attributes are defined using a cluster of 3 attributes ("xxx", "xxx-supported" and "xxx-default", as discussed in §5.8.6. Some attributes also have a fourth "xxx-ready" attribute in their cluster. This attribute is used to indicate which of the values in the "xxx-supported" attribute are ready for use with no user interaction needed. The attributes that have an associated "xxx-ready" attribute are generally those that involve consumables such as paper or marking agents. A common example would be the "media-ready" attribute [RFC2911], which indicates the set of media that is physically in the paper trays. This would likely differ from "media-supported" because the set of supported media types is most likely larger than the set of media types currently installed in the paper trays.
This attribute is useful to a Client because it allows the Client to be able to determine whether certain consumables choices are already available for use, and allows the Client to make certain choices as to the workflow it provides to the user.
5.8.8 job-creation-attributes-supported
The "job-creation-attributes-supported" attribute [PWG5100.11][PWG5100.11] lists the set of Job attributes that can be set by a Client with a Job Creation operation (Create-Job, Print-Job, Print-URI) or a Validate-Job operation. The list of attributes is not limited to Job Template attributes; the list can also include optional Job submission attributes, such as "job-name".
The Client can use this attribute to know which attributes the Printer supports.
5.8.9 document-creation-attributes-supported
The "document-creation-attributes-supported" attribute [PWG5100.5][PWG5100.5] is similar to the "job-creation-attributes-supported" attribute except it applies to those attributes that can be supplied in Document Creation (Print- Job, Print-URI, Send-Document, and Send-URI) and manipulation (Set-Document-Attributes, Set-Job-Attributes) operations. All recommendations made for the use of "job-creation-attributes-supported" also apply to "document-creation-attributes-supported".
5.8.10 job-settable-attributes-supported
The "job-settable-attributes-supported" attribute [RFC3380] lists the Job object attributes that can have their values changed via a Set-Job-Attributes operation. This is useful to the Client because it provides a mechanism to control some aspects of job state, which can affect processing time and execution. For instance, a Client can use this attribute to update Job attributes and release a job in the pending-held state after all documents have been submitted.
Page 97 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
283284
1386
1387138813891390139113921393139413951396
139713981399
1400
14011402140314041405
1406
1407
140814091410141114121413
1414
141514161417141814191420
285
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
5.8.11 media-col-ready vs. media-col-database
The “media-col-database” attribute describes all the pre-defined "media-col" values implemented by the Printer, regardless of whether they are currently available. By definition, this attribute is not sent by the Printer unless explicitly requested since it is large, expensive to generate, and likely contains media that are not readily available, which can be misleading to the user. The “media-col-ready” attribute [PWG5100.3] describes the attributes of the media that is currently ready to use.
The Printer SHOULD implement the “media-col-ready” attribute.
The Client SHOULD use “media-col-ready” if the Printer implements it. The Client SHOULD NOT retrieve the “media-col-database” attribute unless the User does something overt that depends on presenting or using the entire "media-col-database".
5.9 Resolving Job Attribute Conflicts and Constraints
The "job-constraints-supported" and "job-resolvers-supported" attributes [PWG5100.13] provide respectively mechanisms for a Printer to describe to a Client the constraints between sets of attributes and/or attribute values, and associated formulae for resolving constraint conflicts. A Client that supports these attributes properly can resolve conflicts between constrained attributes or attribute values locally, without having to contact the Printer with requests to validate the attribute set correctness. The "preferred-attributes" attribute provides an additional mechanism for a Printer to report attribute conflicts detected during a "Validate-Job" operation. This is covered in more detail in §13.2§ 4.5.
The “job-constraints-supported” attribute definition in [PWG5100.13] §5.6.8 provides this example:
For example, a constraint for duplex printing on transparency media would be encoded as a collection containing “resolver-name”, “sides”, and “media-col” member attributes. The “sides” member attribute would have two values - “two-sided-long-edge” and “two-sided- short-edge” - while the “media-col” member attribute would have a single "media-type" member attribute with the value “transparency”.
The “job-resolvers-supported” attribute definition in [PWG5100.13] §5.6.11 provides this example:
For example, a resolver for duplex printing on transparency media would be encoded as a collection containing “resolver-name”, “sides”, and “media-col” member attributes. The “sides” member attribute would have the value “one-sided” while the “media-col” member attribute would contain a "media-type" member attribute with the value “stationery”.
To illustrate how this works via 2 examples, the Client is assumed to have received the following attributes from the Printer in a Get-Printer-Attributes operation response. The
Page 98 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
286287
1421
142214231424142514261427
1428
142914301431
1432
143314341435143614371438143914401441
14421443
14441445144614471448
14491450
14511452145314541455
14561457
288
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
attributes relevant to these examples are listed below, using the Open Standard Print API [PAPI] attribute list text representation syntax:
sides-default="one-sided"media-col-ready={ { media-size = { x-dimension=21590 y-dimension=27940 } media-top-margin=423 media-bottom-margin=423 media-left-margin=423 media-right-margin=423 media-source=tray-3 media-type="stationery" media-source-properties= { media-source-feed-direction="long-edge-first" media-source-feed-orientation=4 } } { media-size= { x-dimension=27940 y-dimension=43180 } media-top-margin=423 media-bottom-margin=423 media-left-margin=423 media-right-margin=423 media-source="tray-2" media-type="transparency" media-source-properties= { media-source-feed-direction="short-edge-first" media-source-feed-orientation=3 } }}
job-constraints-supported={
Page 99 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
289290
14581459
1460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502
291
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
resolver-name=“A” sides= { "two-sided-long-edge" "two-sided-short-edge" } media-col= { media-type="transparency" }}
job-resolvers-supported={ resolver-name=“A” sides="one-sided" media-col= { media-type="stationery" }}
To illustrate how constraints and resolvers work using the above attribute information, two examples will be described. In each of them, the Client loads the attributes from the Printer and presents a print dialog with print options to the User. The state of "sides" is initialized with the value from "sides-default", and "“media-col" is initialized with the value from "media-col-default".
As a first example, the User chooses "sides" = 'two-sided-long-edge'. The Client detects a control change, and evaluates the changed value against the constraints. The Client detects no conflicts, so the Client accepts the attribute value change. Then the User selects "transparency" for a media type. The Client detects a control change and evaluates the changed value against the constraints. The Client detects a conflict, so the Client takes some action to resolve the conflict. The Client implementation determines how the conflict is resolved. It could be that the new value is rejected ("media-col" change in this example), or it could be that the new value is kept but the conflicting attribute is changed as per the resolver. Or the choices could be presented to the User in some way.
For a second example, the User selects "transparency" for a media type. The Client detects a control change and evaluates the changed value against the constraints. The Client detects no conflicts, so the Client accepts the attribute value change. Then the User selects "sides"='two-sided-short-edge'. The Client detects a control change and evaluates the changed value against the constraints. The Client detects a conflict, so the Client takes some action to resolve the conflict. Again, how the Client manages the resolution is at the discretion of the Client implementors.
Page 100 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
292293
150315041505150615071508150915101511151215131514151515161517151815191520152115221523
15241525152615271528
1529153015311532153315341535153615371538
1539154015411542154315441545
294
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
5.10 IPP Object Status Attributes
A Client will evaluate different sets of attributes when following the procedures in §4.7 or 4.11 to monitor the status of a Printer or Job. These sets should be interpreted in the context of one another to ensure correct status evaluation.
5.10.1 Printer Status
A Printer conveys its status using the "printer-state", "printer-state-reasons" and "printer-state-message" attributes [RFC2911], as well as the "printer-alert" and "printer-alert-description" [PWG5100.9]. A Client can acquire these attributes using a Get-Printer-Attributes operation. A Printer SHOULD append to its "printer-state-reasons" attribute values the appropriate suffixes defined in [RFC2911] §4.4.12.
If the Printer and Client both support IPP Notifications, the Client can create a Printer subscription that includes the "printer-state", "printer-state-reasons" and "printer-state-message" attributes in the "notify-attributes" list. See §5.11 for more information on IPP Notifications.
5.10.2 Job Status
A Job conveys its status using the "job-state", "job-state-reasons" and "job-state-message" attributes. A Client can acquire these attributes using a Get-Job-Attributes operation.
If the Printer and Client both support IPP Notifications, the Client can create a Job subscription that includes the "job-state", "job-state-reasons" and "job-state-message" attributes in the "notify-attributes" list. See §5.11 for more information on IPP Notifications.
5.10.3 Document Status
If the Client wants detailed information about the status of Document objects within a Job, it can get the status of the various Documents within the Job using the Get-Document-Attributes operation, and would examine the "document-state", "document-state-reasons" and "document-state-message" attributes.
5.11 IPP Notifications Attributes
A well-implemented IPP Printer SHOULD support IPP Notifications [RFC3995]. The Printer SHOULD include additional Printer attributes in Printer event notifications (e.g. "printer-supply" for supply events, "printer-input-tray" for media events, etc.).
When subscribing for IPP notifications, a Client SHOULD include the "notify-attributes" Subscription Template attribute in its Job Creation operations rather than subscribing to events using the separate Create-Job-Subscriptions or Create-Printer-Subscriptions operations. Having the Job Creation operation create the subscription makes the
Page 101 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
295296
1546
154715481549
1550
15511552155315541555
1556155715581559
1560
156115621563
1564156515661567
1568
1569157015711572
1573
157415751576
1577157815791580
297
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
subscription creation and Job creation operations atomic and reduces the need for additional operations.
A Client uses the "notify-attributes" attribute to list the attributes it wants request that each notification include particular attributes. If each notification includes the attributes the Client needs, the Client will not need to perform a subsequent Get-Printer-Attributes operation for a Printer subscription, or Get-Job-Attributes operation for a Job subscription.
6. IPP Document Page OrderDocument formats intended for streaming (printed directly), such as PWG Raster, need to have the pages sent in the order that they should emerge from the printer. This order will be affected in part by which side the marking appears on when the page emerges from the printer. On a printer that implements the "printer-output-tray" attribute and prints its documents “face down” (the paper emerges with the marking on the bottom side of the page), the pages should be sent in the order 1-N. On a printer that prints its pages “face up” (the paper emerges with the marking on the top side of the page), the pages should be sent in the reverse order (N-1). Other aspects, including duplex and page reordering, will further affect this page ordering. If the Printer does not support the "printer-output-tray" attribute, the "output-bin" and "output-bin-default" attributes can be evaluated. The 'face-up' value indicates last-to-first order; all other values are first-to-last.
Other document formats that are not intended for streaming but are rather intended for more general use, such as PDF or word processing document formats, need to be sent as-is, with no page reordering. It will be the Printer’s responsibility to paginate and print the file in the order that is appropriate given the paper orientation and other built-in information in the document format (with overriding behavior as per §5.5). This may require the entire Document to be received before the first page can be printed. For instance, if a Client submits a Job with its document content in PDF document format, the Client SHOULD send the document format in 1-N page ordering, and depend on the printer processing the pages in whatever order is appropriate to comply with the preferences in the Job IPP attributes and the settings in the PDF document.
7. IPP Printer Best PracticesThis section enumerates practices that SHOULD be followed by implementers of IPP Printer objects, whether embedded in a Printer or in a separate Print Server.
7.1 IPP Objects and URI Resource Paths
IPP operations require a target consisting of a "printer-uri" attribute and zero or more operation identifiers, such as "job-id", "document-number", or others [RFC2911]§([RFC2911] §3.1.5.).
Page 102 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
298299
15811582
15831584158515861587
1588
158915901591159215931594159515961597159815991600
1601160216031604160516061607160816091610
1611
16121613
1614
161516161617
300
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Each instance of a Printer, FaxOut, or Scan Service provided by an Imaging Device is identified by a URI. The URI scheme MUST be "ipps" [RFC-IPPS] or "ipp" [RFC3510]. It MUST NOT be "http" or "https" [RFC2910]. [RFC2910].
The path component of an IPP Printer URI SHOULD be “/ipp/print” for the only (or default) instance of the service on an Imaging System and “/ipp/print/instance-name” for each additional, non-default instance on the Imaging System. IPP FaxOut [PWG5100.15] and IPP Scan [PWG5100.17] each define a well-known path for their respective Service Object types.
If the Printer supports IPP operations with the "/" resource path, then the Printer SHOULD support Get-Printer-Attributes and SHOULD NOT support Job Creation operations.
[RFC2911]"Internet Printing Protocol/1.1: Model and Semantics" [RFC2911] requires particular Client behavior concerning the use of URIs in an operation's "printer-uri" attribute. [RFC2911][RFC2911] section 2.4 requires the Client to only provide URIs that are listed by the Printer's "printer-uri-supported" attribute. [RFC2911][RFC2911] § 3.1.5 requires the Client to only use absolute URIs for the value sent for the "printer-uri" operation attribute. Despite the recommendations in [RFC3196],[RFC3196], a Printer SHOULD NOT accept a request where the "printer-uri" value is a relative URI and SHOULD NOT accept a request where the "printer-uri" doesn't match one of those URIs in the Printer's "printer-uri-supported" attribute.
A Printer SHOULD reject IPP operations where the value of the "printer-uri" operation attribute is a relative URI. A Client SHOULD NOT use a relative URI in the "printer-uri" operation attribute.
The "job-uri" path has never been fully specified. Printers SHOULD choose a path appropriate for the implementation. Clients SHOULD use the "printer-uri" and "job-id" attributes to target a Job object for a Job operation. Clients SHOULD NOT use the "job-uri" attribute to target a Job object.
7.2 Fax Destination URIs
When a Client submits a fax Job to an IPP FaxOut service [PWG5100.15], it includes a set of destination URIs. An IPP FaxOut Printer Object SHOULD handle the “fax:” URI scheme as being equivalent to the “tel:”” URI scheme [RFC3966].
7.3 Printer Resource URIs
URIs to various Printer resident resources SHOULD be Network Accessible even if all other network services have been disabled in the Output Device.
As an example, the "printer-icons" URI SHOULD be Network Accessible even if the Output Device has its embedded web server turned off. Since the "printer-icons"
Page 103 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
301302
161816191620
16211622162316241625
162616271628
162916301631163216331634163516361637
163816391640
1641164216431644
1645
164616471648
1649
16501651
16521653
303
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
attribute is defined to contain a set of "http:"" or "https:"" URIs, each URI SHOULD include the port number of the IPP Server, e.g. "http://myprinter.mydomain.com:631/icon.png".
7.4 Error Reporting
A Printer SHOULD log errors using the PWG Common Log Format [PWG5110.3].
8. HTTP Protocol UseIPP currently uses HTTP/1.1 for its transport. IPP/2.0 and other IPP specifications have specified some of the facilities of HTTP that IPP clients and servers SHOULD support in order to provide the semantics that IPP needs to provide a great user experience. Even so, there are best practices that SHOULD be followed.
What follows includes recommendations for both Client and Server implementations. Each subsection will provide Client recommendations in an 8.x.1 subsection; Server recommendations will be listed in an 8.x.2 subsection.
8.1 New HTTP/1.1 Specifications
In June 2014 the IETF published the following specifications, which obsolete RFC 2616:
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing [RFC7230]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content [RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests [RFC7232]
Hypertext Transfer Protocol (HTTP/1.1): Range Requests [RFC7233]
Hypertext Transfer Protocol (HTTP/1.1): Caching [RFC7234]
Hypertext Transfer Protocol (HTTP/1.1): Authentication [RFC7235]
8.1.1 HTTP Client
Implementors SHOULD review their HTTP stack implementation to ensure conformance with these current HTTP/1.1 specifications.
8.1.2 HTTP Server
Implementors SHOULD review their HTTP stack implementation to ensure conformance with these current HTTP/1.1 specifications.
Page 104 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
304305
165416551656
1657
1658
1659
1660166116621663
166416651666
1667
16681669
1670
1671
1672
1673
1674
1675
1676
16771678
1679
16801681
306
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
8.2 HTTP/1.1 Expect Header
The HTTP/1.1 "Expect" header field [RFC7230] allows the HTTP Client to send the HTTP request header to the Server and pause to receive an HTTP response code before sending the request body, if present. This allows a Server to indicate via an appropriate response code if there are any authorization or encryption requirements to be satisfied before sending the HTTP request body.
8.2.1 HTTP Client
In its first request to the HTTP Server, and in all first uses of a particular IPP operation while involved in a session consisting of a sequence of IPP operations, the HTTP Client SHOULD include the "Expect: 100-continue" header in the request headers [RFC7231][RFC7231] §5.1.1. The HTTP Client SHOULD then wait at least 1 second for a response from the HTTP Server. If no response is received, the Client should record this for subsequent requests so that no further response delays are incurred, and then continue sending the message body; otherwise the HTTP Client SHOULD process the response in one of the following ways (which is a more detailed set of behaviors than described in HTTP/1.1 [RFC7230]):
100 Continue : continue sending the message body
301 Moved Permanently or/ 302 Moved Temporarily :
a. If the request type is POST or PUT, fail and report an error, since redirection is generally unexpected for this request type
b. If the request type is HEAD or GET, redirect the request to the new URI or address the redirection in an implementation-defined way, e.g. request confirmation from the User, validate the redirected URI scheme and origin server, etc.
400 Bad Request : the Client should record the lack of an Expect header, and re-send the HTTP request without the Expect header. (An HTTP/1.1 Server is supposed to support the Expect header as per [RFC7230] §5.1.1 but a robust Client might include logic for recovering from interacting with poorly implemented servers.)
401 Unauthorized : close the connection, acquire new credentials from the User, and retry the HTTP request with the newly acquired credentials
403 Forbidden : abandon the connection and report an error as per §4.12.
417 Expectation Failed : resend the HTTP request without the Expect header
426 Upgrade Required : if the upgrade response header contains a TLS identifier, upgrade the connection to TLS [RFC2817] and then re-send the HTTP request
Page 105 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
307308
1682
16831684168516861687
1688
168916901691169216931694169516961697
1698
1699
17001701
1702170317041705
1706170717081709
17101711
1712
1713
17141715
309
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Any other HTTP status code : treat this as a fatal error and report it as per §4.12.
8.2.2 HTTP Server
The HTTP Server SHOULD accept and process the "Expect" header as defined in § 5.1.1 of "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" [RFC7231].
8.3 "Host" Header Field
An HTTP Server validates the Host request header in order to protect against DNS rebinding attacks. Section 5.1.1 of "IPP Everywhere" [PWG5100.14] places additional requirements on the Host header.
8.3.1 HTTP Client
An HTTP Client SHOULD include the Host header field, and its value SHOULD match the name in the URI it is using.
8.3.2 HTTP Server
An HTTP Server SHOULD use the Host value in generated URIs, such as the embedded web server web pages or IPP operation responses.
8.4 If-Modified-Since, Last-Modified, and 304 Not Modified
The If-Modified-Since request header allows an HTTP Client to efficiently determine whether a particular resource that can be retrieved using a GET request (icon, ICC profile, localization file, etc.) has been updated since the last time the HTTP Client requested it.
8.4.1 HTTP Client
An HTTP Client should utilize the "If-Modified-Since" header in GET requests for resources that it may already have locally, and support the "Last-Modified" response header and "304 Not Modified" response code, to avoid re-fetching these resources if they haven't changed.
8.4.2 HTTP Server
HTTP Servers SHOULD support the "If-Modified-Since" request header [RFC7232], the Last-Modified response header [RFC7232], and the "304 Not Modified" response code [RFC7232].
Page 106 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
310311
1716
1717
17181719
1720
172117221723
1724
17251726
1727
17281729
1730
1731173217331734
1735
1736173717381739
1740
174117421743
312
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
8.5 Cache-Control
Most resource files provided by a Printer in a GET response will typically be cacheable. However, IPP responses in a POST response are not [PWG5100.14]. Most resources retrieved by an IPP Client from an IPP Printer via an HTTP GET are usually quite static and ought to be treated as a persistent resource. The HTTP "Cache-Control" header [RFC7234][RFC7234] formalizes this.
8.5.1 HTTP Client
An HTTP Client SHOULD conform to the HTTP/1.1 caching semantics [RFC7234]. An HTTP Client SHOULD support the "Cache-Control" response header.
8.5.2 HTTP Server
An HTTP Server SHOULD conform to the HTTP/1.1 caching semantics [RFC7234]. A Printer's HTTP Server MAY provide a "Cache-Control" header in each HTTP GET response, with an appropriate "max-age" value for that resource. A Printer's HTTP Server SHOULD provide a Cache-Control header in IPP POST responses with the value "no-cache".
9. Important Implementation Options
9.1 Job Receipts: The "xxx-actual" Attributes
The "xxx-actual" [PWG5100.8] attributes cannot be used to detect substitutions during. The state of these attributes is not guaranteed to be set until the Job reaches a terminating state ('aborted', 'canceled' or 'completed'). Processors of the Job receipt SHOULD NOT expect the Printer to bind values to the "xxx-actual" attributes before the job has reached a terminated state.
9.2 Printer Constraints: The "preferred-attributes" Attribute
The Printer indicates it supports the "preferred-attributes" attribute [PWG5100.13] with the "preferred-attributes-supported" Printer Description attribute. If supported, the Printer will send the "preferred-attributes" attribute in Validate-Job operation responses if it will perform substitutions the Printer to resolve constraints problems it detected. This gives the Client the opportunity to resolve these issues locally. However, although this is useful when performing Job "pre-flight", a Client should not be implemented to use this as a mechanism to be called with high frequency for resolving constraints conflicts in an interactive UI. As outlined in §4.5, a Client SHOULD start by using the procedures described in §5.9, which can be performed locally on the Client and doesn't require any network utilization.
Page 107 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
313314
1744
17451746174717481749
1750
17511752
1753
17541755175617571758
1759
1760
17611762176317641765
1766
1767176817691770177117721773177417751776
315
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
10. Conformance Recommendations
10.1 Client Conformance Recommendations
Clients SHOULD implement the following:
1. all of the "best" options in section 4;
2. all of the recommendations in section 5;
3. all of the recommendations in section 6;
4. all of the Client recommendations in section 8;
5. all of the Client recommendations in section 11;
6. all of the Client recommendations in section 12
10.2 Printer Conformance Recommendations
Printers SHOULD implement the following:
1. all of the "best" options provided in section 4;
2. all of the recommendations in section 5;
3. all of the recommendations in section 7;
4. all of the Printer recommendations in section 8;
5. all of the Printer recommendations in section 11;
6. all of the Printer recommendations in section 12
11. Internationalization ConsiderationsFor interoperability and basic support for multiple languages, conforming implementations MUST support:
1. The Universal Character Set (UCS) Transformation Format -- 8 bit (UTF-8) [STD63] encoding of Unicode [UNICODE] [ISO10646]; and
2. The Unicode Format for Network Interchange [RFC5198] that requires transmission of well-formed UTF-8 strings and recommends transmission of normalized UTF-8 strings in Normalization Form C (NFC) [UAX15].
Page 108 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
316317
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
17951796
17971798179918001801
318
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
Unicode NFC is defined as the result of performing Canonical Decomposition (into base characters and combining marks) followed by Canonical Composition (into canonical composed characters wherever Unicode has assigned them).
WARNING – Performing normalization on UTF-8 strings received from IPP Clients and subsequently storing the results (e.g., in IPP Job objects) could cause false negatives in IPP Client searches and failed access (e.g., to IPP Printers with percent-encoded UTF-8 URIs now 'hidden').
11.1 Client Considerations
A Client SHOULD query and use localization catalogs provided by the IPP Printer [PWG5100.13], if available.
11.2 Server Considerations
A Printer SHOULD support localization catalogs [PWG5100.13].
12. Security Considerations
12.1[9.2] Client Security Considerations
In addition to the sections below, Client implementors should also pay attention to §7.3, §8.2.1 and §8.3.
12.1.1[9.2.1] HTTP/1.1 Expect Header
As discussed in §8.2, a Client SHOULD send the HTTP/1.1 Expect header where it is important to determine if the Printer will request to upgrade the connection to use TLS if it isn't being used already. Examples of this situationscenario include:
a. First HTTP request for a connectionb. First IPP request for a connectionc. Any request where the Client will be transmitting potentially sensitive data
12.1.2[9.2.2] HTTP Upgrade
A Client or Server MAY be implemented to refuse to use certain operations if a connection is not employing TLS encryption. Encryption can be supplied via HTTP Upgrade [RFC2817][RFC2817] or HTTPS [RFC 2818]. Clients and Servers SHOULD support TLS encryption via HTTP Upgrade [RFC2817][RFC2817] and/or HTTP Over TLS (HTTPS [RFC2818].) [RFC2818].
Page 109 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
319320
180218031804
1805180618071808
1809
18101811
1812
1813
1814
1815
18161817
1818
181918201821
182218231824
1825
18261827182818291830
321
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
12.1.3[9.2.3] Using The Validate-Job Operation
A Client SHOULD use the Validate-Job IPP operation and the behavior recommendations enumerated in §8.2.1 to test whether the Printer requires authentication or encryption for Job submission.
12.1.4[9.2.4] Preferring The "ipps" URI Scheme
A Client SHOULD support the “ipps” URI scheme. [RFC-IPPS]. A Client SHOULD prefer the “ipps” URI variant when available. A Client probing a Printer for the first time (§4.1.2 and §4.2) SHOULD first try using TLS IPP over HTTPS, and if the connection fails then try non-TLS IPP over HTTP.
12.2[9.3] Server Security Considerations
In addition to the sections below, Client implementors should also pay attention to §7.3, §8.2.1 and §8.3.
12.2.1[9.3.1] HTTP/1.1 Expect Header
As discussed in §8.2, a Server MUST support the HTTP/1.1 Expect header and respond appropriately [RFC7230].[RFC7230].
12.2.2[9.3.2] HTTP Upgrade
A Server SHOULD support HTTP Upgrade [RFC2817][RFC2817] to indicate to a Client the need to upgrade the connection to TLS.
12.2.3[9.3.3] Support For The "ipps" URI Scheme
A Printer SHOULD support the "ipps" URI scheme [RFC-IPPS].
If a Printer is configured to only support only TLSIPPS (or IPP ("ipps" URI), it SHOULD still implementover HTTPS), and a Client sends an IPP over HTTP request, the Printer MAY do one of the following behaviors over non-TLS IPP ("ipp" URI):
a. Close the connection;
b. Return 301 Moved Permanently;
c. Return 400 Bad Request;
d. Return 426 Upgrade Required to redirect poorly implemented IPPS capable Client implementations and upgrade the connection to allow a graceful failureTLS
Page 110 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
322323
1831
183218331834
1835
1836183718381839
1840
18411842
1843
18441845
1846
18471848
1849
1850
185118521853
1854
1855
1856
185718581859
324
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
There is no IPP response, just a HTTP response. HTTP requests for legacy IPP Client implementations that don't support TLS IPP. (Recommendations TBD.)embedded web server or resources can be handled in the same way.
12.2.4[9.3.4] DNS Rebinding
Printers SHOULD validate the HTTP Host request header in order to protect against DNS rebinding attacks [PWG5100.14]. The Host header is discussed in §8.3.
[10.] Important Implementation Options
[10.1] Using "xxx-actual" attribute
The xxx-actual Job attributes could be used to detect substitutions that would be used by the Printer Object. Observing this, the Client MAY decide to cancel the Job rather than submit the document with this job. If the original Job was cancelled, the Client could create another Job with a new set of attributes submitted, or error out and not submit a Job at all.
HOWEVER, xxx-actual attributes are not stable until the Job reaches a terminating state (aborted, cancelled or completed) and processors of the Job receipt SHOULD keep this in mind. Given this, it isn't clear whether there is any value in examining the xxx-actual attributes since the values MAY NOT be set until after it is too late.
[10.2] Printer Constraints Resolution via "preferred-attributes"
The Printer includes "preferred-attributes" [PWG5100.3] in its Validate-Job operation response if the Printer detects constraints problems. The Printer will include in its Validate-Job response the "preferred-attributes" attribute, which lists the substitutions the Printer will use to resolve the constraints problems it detected. This gives the Client the opportunity to resolve these issues locally. However, this facility should not be considered a primary mechanism for resolving constraints conflicts because it involves Client / Printer protocol interaction. A Client should start by using the procedures described in §5.9, which can be performed locally on the Client and don't require any network utilization.
[11.] Internationalization Considerations
[11.1] Client Considerations
A Client SHOULD use localization catalogs provided by the IPP Printer, if available.
Page 111 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
325326
186018611862
1863
18641865
1866
1867
18681869187018711872
1873187418751876
1877
187818791880188118821883188418851886
1887
1888
1889
327
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
[11.2] Server Considerations
A Printer SHOULD provide localization catalogs to IPP Clients.
[12.] Conformance Requirements
[12.1] Client Conformance Requirements
There are no mandatory conformance requirements for Clients.
[12.2] Printer Conformance Requirements
There are no mandatory conformance requirements for Printers.
[12.3] Client Conditional Conformance Requirements
[1.] Clients should implement the "best" options in section 4.
[2.] Clients should implement all the recommendations in section 5.
[3.] Clients should implement all the recommendations in section 9.1.
[4.] Clients should implement all the recommendations in section 11.1.
[12.4] Printer Conditional Conformance Requirements
[1.] Printers should implement the "best" options provided in section 4.
[2.] Printers should implement all the recommendations in section 7.
[3.] Printers should implement all the recommendations in section 8.
[4.] Printers should implement all the recommendations in section 9.2
[5.] Printers should implement all the recommendations in section 11.2.
[13.] References
12.3[13.1] Informative References
[IANAIPP] Internet Assigned Numbers Authority (IANA) Registries, "Internet Printing Protocol", http://www.iana.org/assignments/ipp-registrations/
Page 112 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
328329
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
19101911
330
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
[ISO10646] "Information technology -- Universal Coded Character Set (UCS)", ISO/IEC 10646:2011
[PAPI] A. Hlava, N. Jacobs, M. Sweet, "Open Standard Print API (PAPI)", July 2005, http://prdownloads.sourceforge.net/openprinting/PAPI-specification.pdf?download http://prdownloads.sourceforge.net/ openprinting/PAPI-specification.pdf?download
[PWG5100.1] M. Sweet, "IPP Finishings 2.0", PWG 5100.1-2014, December 2014, http://ftp.pwg.org/pub/pwg/candidates/cs-ippfinishings20-20141219-5100.1.pdf http://ftp.pwg.org/pub/pwg/candidates/cs-ippfinishings20- 20141219-5100.1.pdf
[PWG5100.3] K. Ocke, T. Hastings, "Internet Printing Protocol (IPP): Production Printing Attributes – Set1", PWG 5100.3-2001, February 2001, http://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10-20010212-5100.3.pdf http://ftp.pwg.org/pub/pwg/candidates/cs-ippprodprint10- 20010212-5100.3.pdf
[PWG5100.5] D. Carney, T. Hastings, P. Zehler. “Internet Printing Protocol (IPP): Document Object”, PWG 5100.5-2003, October 2003, http://ftp.pwg.org/pub/pwg/candidates/cs-ippdocobject10-20031031-5100.5.pdf
[PWG5100.7] T. Hastings, P. Zehler, "Standard for The Internet Printing Protocol (IPP): Job Extensions", PWG 5100.7-2003, October 2003, http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobext10-20031031-5100.7.pdf http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobext10- 20031031-5100.7.pdf
[PWG5100.8] D. Carney, H. Lewis, "Internet Printing Protocol: '-actual' Attributes", PWG 5100.8-2003, March 2003, http://ftp.pwg.org/pub/pwg/candidates/cs-ippactuals10-20030313-5100.8.pdf http://ftp.pwg.org/pub/pwg/candidates/cs-ippactuals10- 20030313-5100.8.pdf
[PWG5100.9] I. McDonald, C. Whittle, "Internet Printing Protocol (IPP) Printer State Extensions v1.0", PWG 5100.9-2009, July 2009, http://ftp.pwg.org/pub/pwg/candidates/cs-ippstate10-20090731-5100.9.pdf http://ftp.pwg.org/pub/pwg/candidates/cs-ippstate10- 20090731-5100.9.pdf
[PWG5100.11] T. Hastings, D. Fullman, “IPP: Job and Printer Operations – Set 2”, PWG 5100.11-2010, October 2010, http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext10-20101030-5100.11.pdf
Page 113 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
331332
19121913
1914191519161917
1918191919201921
19221923192419251926
1927192819291930
19311932193319341935
19361937193819391940
19411942194319441945
1946194719481949
333
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
[PWG5100.12] R. Bergman, H. Lewis, I. McDonald, M. Sweet, "IPP/2.0 Second Edition", PWG 5100.12-2011, February 2011, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ipp20-20110214-5100.12.pdf ftp://ftp.pwg.org/pub/pwg/candidates/cs-ipp20-20110214- 5100.12.pdf
[PWG5100.13] M. Sweet, I. McDonald, P. Zehler, " IPP: Job and Printer Extensions – Set 3 (JPS3)", 5100.13-2012, July 2012, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf ftp://ftp.pwg.org/pub/pwg/candidates/cs- ippjobprinterext3v10-20120727-5100.13.pdf
[PWG5100.14] M. Sweet, I. McDonald, A. Mitchell, J. Hutchings, "IPP Everywhere", 5100.14-2013, January 2013, ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf ftp://ftp.pwg.org/pub/pwg/ candidates/cs-ippeve10-20130128-5100.14.pdf
[PWG5100.15] M. Sweet, "IPP FaxOut Service", PWG 5100.15-2013, November 2013, http://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10- 20131115-5100.15.pdf http://ftp.pwg.org/pub/pwg/candidates/cs- ippfaxout10- 20131115-5100.15.pdf
[PWG5100.16] M. Sweet, “IPP Transaction-Based Printing Extensions”, PWG 5100.16-2013, November 2013, http://ftp.pwg.org/pub/pwg/candidates/cs-ipptrans10-20131108-5100.16.pdf
[PWG5100.17] P. Zehler, M. Sweet, "IPP Scan Service (SCAN)", 5100.17-2014, September 2014, http://ftp.pwg.org/pub/pwg/candidates/cs-ippscan10-20140918-5100.17.pdf http://ftp.pwg.org/pub/pwg/candidates/cs- ippscan10-20140918-5100.17.pdf
[PWG5110.3] M. Sweet, "PWG Common Log Format", PWG 5110.3-2013, April, 2013, http://ftp.pwg.org/pub/pwg/candidates/cs-ids-log10-20130401.5110.3.pdf http://ftp.pwg.org/pub/pwg/candidates/cs-ids- log10-20130401.5110.3.pdf
[RFC2119] S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, RFC 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt
[RFC2817] R. Khare, S Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, September 2000, http://www.ietf.org/rfc/rfc2817.txt http://www.ietf.org/rfc/rfc2817.txt
[RFC2818] E. Rescorla, “HTTP Over TLS”, RFC 2818, May 2000, http://www.ietf.org/rfc/rfc2818.txt
Page 114 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
334335
19501951195219531954
19551956195719581959
1960196119621963
1964196519661967
1968196919701971
1972197319741975
1976197719781979
19801981
198219831984
19851986
336
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
[RFC2910] R. Herriot, S. Butler, P. Moore, R. Tuner, J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000, http://www.ietf.org/rfc/rfc2910.txt http://www.ietf.org/rfc/rfc2910.txt
[RFC2911] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000, http://www.ietf.org/rfc/rfc2911.txt http://www.ietf.org/rfc/rfc2911.txt
[RFC3196] T. Hastings, C. Manros, P. Zehler, C. Kugler, H. Holst, "Internet Printing Protocol/1.1: Implementer's Guide", RFC 3196, November 2001, http://www.ietf.org/rfc/rfc3196.txt http://www.ietf.org/rfc/rfc3196.txt
[RFC3380] T. Hastings, R. Herriot, C. Kugler, H. Lewis, "Internet Printing Protocol (IPP): Job and Printer Set Operations", RFC 3380, September 2002, http://www.ietf.org/rfc/rfc3381.txt http://www.ietf.org/rfc/rfc3381.txt
[RFC3381] T. Hastings, H. Lewis, R. Bergman, "Internet Printing Protocol (IPP): Job Progress Attributes", RFC 3381, September 2002, http://www.ietf.org/rfc/rfc3381.txt http://www.ietf.org/rfc/rfc3381.txt
[RFC3510] R. Herriot, I. McDonald, "Internet Printing Protocol/1.1 IPP URL Scheme", RFC 3510, April 2003, http://www.ietf.org/rfc/rfc3510.txt http://www.ietf.org/rfc/rfc3510.txt
[RFC3805] R. Bergman, H. Lewis, I. McDonald, "Printer MIB v2", RFC 3805, June 2004, http://www.ietf.org/rfc/rfc3805.txt http://www.ietf.org/rfc/rfc3805.txt
[RFC3806] R. Bergman, H. Lewis, I. McDonald, "Printer Finishing MIB", RFC 3806, June 2004, http://www.ietf.org/rfc/rfc3806.txt http://www.ietf.org/rfc/rfc3806.txt
[RFC3966] H. Schulzrinne, "The tel URI for Telephone Numbers", RFC 3966, December 2004, http://www.ietf.org/rfc/rfc3966.txt http://www.ietf.org/rfc/rfc3966.txt
[RFC3995] R. Herriot, T. Hastings, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", RFC 3995, March 2005, http://www.ietf.org/rfc/rfc3995.txt http://www.ietf.org/rfc/rfc3995.txt
[RFC3996] R. Herriot, T. Hastings, H. Lewis, "Internet Printing Protocol (IPP): The ’ippget’ Delivery Method for Event Notifications", RFC 3996, March 2005, http://www.ietf.org/rfc/rfc3996.txt http://www.ietf.org/rfc/rfc3996.txt
Page 115 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
337338
198719881989
1990199119921993
1994199519961997
199819992000
200120022003
200420052006
200720082009
201020112012
201320142015
201620172018
2019202020212022
339
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
[RFC3997] R. Herriot, T. Hastings, "Internet Printing Protocol (IPP): Requirements for IPP Notifications", RFC 3997, March 2005, http://www.ietf.org/rfc/rfc3997.txt http://www.ietf.org/rfc/rfc3997.txt
[RFC6762] S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762, February 2013, http://www.ietf.org/rfc/rfc6762.txt http://www.ietf.org/rfc/rfc6762.txt
[RFC6763] S. Cheshire, M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013, http://www.ietf.org/rfc/rfc6763.txt http://www.ietf.org/rfc/rfc6763.txt
[RFC7230] R. Fielding, J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014, http://www.ietf.org/rfc/rfc7230.txt http://www.ietf.org/rfc/rfc7230.txt
[RFC7231] R. Fielding, J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, http://www.ietf.org/rfc/rfc7231.txt http://www.ietf.org/rfc/rfc7231.txt
[RFC7232] R. Fielding, J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014, http://www.ietf.org/rfc/rfc7232.txt http://www.ietf.org/rfc/rfc7232.txt
[RFC7233] R. Fielding, Y. Lafon, J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014, http://www.ietf.org/rfc/rfc7233.txt http://www.ietf.org/rfc/rfc7233.txt
[RFC7234] R. Fielding, M. Nottingham, J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014, http://www.ietf.org/rfc/rfc7234.txt http://www.ietf.org/rfc/rfc7234.txt
[RFC7235] R. Fielding, J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014, http://www.ietf.org/rfc/rfc7235.txt http://www.ietf.org/rfc/rfc7235.txt
[RFC-IPPS] I. McDonald, M. Sweet, "IPP over HTTPS Transport Binding and 'ipps' URI Scheme", draft-mcdonald-ipps-uri-scheme-16.txt, November 2014, https://tools.ietf.org/id/draft-mcdonald-ipps-uri-scheme-16.txt https://tools.ietf.org/id/draft-mcdonald-ipps-uri-scheme-16.txt
[WSDiscovery-1.1] OASIS, "OASIS Web Services Dynamic Discovery (WS-Discovery) Version 1.1", July 2009, http://docs.oasis-open.org/ws- dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html http://docs.oasis- open.org/ws- dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html
Page 116 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
340341
202320242025
202620272028
202920302031
203220332034
203520362037
203820392040
204120422043
204420452046
204720482049
2050205120522053
2054205520562057
2058
342
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
13.[14.] Annex A: HTTP/2.0There is an effort to create a new major revision to HTTP, which for now is being called HTTP/2.0. It brings a number of new facilities to HTTP, many of which could be very useful to IPP. The IEEE ISTO PWG IPP Working Group will produce a binding document for IPP over HTTP/2.0 when HTTP/2.0 is ratified and published. No formal binding for IPP over HTTP/2.0 is currently defined.
14.[15.] Authors' AddressesPrimary author:
Smith KennedyHewlett-Packard Co.11311 Chinden Blvd. MS 506Boise, ID [email protected]
The author would like to thank the following individuals for their contributions:
Ezra Brooks - Kentucky State Board of Recreation
[16.] PlantUML Sequence Diagram SourcesPlantUML (http://plantuml.sourceforge.net) was used to generate the UML diagrams presented in this document. The PlantUML source content used to create those diagrams is listed below.
<< Include sources here (if deemed appropriate) >>
15.[17.] Change History
15.1[17.1] February 5, 2013
Initial revision.
15.2[17.2] March 20, 2013
Resolved issues from feedback provided during the IPP conference call on February 25, 2013, as documented in teleconference meeting minutes and author's own notes.
1. Added Validate-Job operation as operation to be used during printer selection process to validate access by Client / user
Page 117 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
343344
2059
20602061206220632064
2065
2066
20672068206920702071
2072
20732074
2075
2076207720782079
2080
2081
2082
2083
20842085
20862087
345
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
2. Replaced previous Section 5 "Conformance Requirements" with new Section 5 "Attributes and Their Use in Operations"
3. Replaced previous Section 6 "Internationalization Considerations" with new Section 6 "HTTP Protocol Usage"
4. Added updated list of references
15.3[17.3] May 13, 2013
Resolved remaining issues from February 25, 2013 teleconference meeting notes and other feedback received since then.
1. Added PWG 5100.8, 5100.13 and WS-Discovery references; removed boilerplate [REFERENCE] reference entry; fixed references for 5100.14.
2. Updated with meeting notes fixes from April 8, including updated notation for comments (now in italic), revised notation for indicating iterative looping and parallel execution, and many other changes to section 4. Also changed document naming convention and moved URL where it is to be located on PWG FTP site.
15.4[17.4] July 19, 2013
Updated with feedback and discussions from the May 2013 F2F in Cupertino, and other piecemeal feedback.
1. Changed title to "IPP/2.0 Implementer's Guide
2. Changed Abstract to "Updates and extends RFC 3196 for IPP/2.0."
3. Renamed to follow the wd-ippig20-yyyymmdd.docx/pdf naming convention given the title change.
4. Made a PWG Working Draft, not a best practice
5. Added normative reference to RFC 3196.
15.5[17.5] September 22, 2013
Updated with feedback from reflector discussions and conference calls. This is a "new baseline", and much more work is needed to fill in TBD sections.
1. Substantially elaborated section 5.5.
2. Updated comments about using xxx-actual in detecting whether the printer uses the requested / recommended attribute values (more discussion needed)
Page 118 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
346347
20882089
20902091
2092
2093
20942095
20962097
2098209921002101
2102
21032104
2105
2106
21072108
2109
2110
2111
21122113
2114
21152116
348
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
3. Editorial changes (fixed "Implementors" to be "Implementer's", renamed some section titles
15.6[17.6] October 2, 2013
1. Changed the title to "IPP Implementor's Guide v2.0" (in part reverting change #3 from 2013-09-23) and the abstract to make it clear this applies to all IPP versions, not just IPP/2.0.
2. Expanded §5.8 to enumerate the attributes used in evaluating printer capabilities and how to properly use them or handle the cases where they are absent and assumed to be not supported. This is mostly a set of placeholders at this point.
3. Updated §5.6 to clarify guidance on "multiple-document-handling" vs. "sheet-collate".
4. Updated §4.2 to include a placeholder statement to make note that a Client should maintain a sense of user identity between 4.2 and 4.3 to ensure that the capabilities evaluated are really those that the user has access to use and more importantly that none are missing.
5. Comments in section 4.5 to catch all the places where using "xxx-actual" to recognize substitutions before the Job has been processed is suggested, because this seems to be a problematic suggestion.
15.7[17.7] January 3, 2014
Updated with review feedback from October 2013 face-to-face and December 16 conference call minutes notes. This is a "new baseline". More work is still needed to fill in TBD sections.
1. Addressed scenario where Create-Job created the Job but Send-Document fails (triggered by query from vendor: what to do when “document-format” is unsupported?)
2. Added new proposed operation for filtering features for a given user (JPS4?)
3. Moved discussion of xxx-actual use to its own section (currently section 11.1)
4. Expanded discussion of Send-URI / document-by-reference and recommended generally against it
5. Added new section 9 for covering IPP Notifications
6. Other changes not described in detail (consult -rev document for specifics).
Page 119 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
349350
21172118
2119
212021212122
212321242125
21262127
2128212921302131
213221332134
2135
213621372138
213921402141
2142
2143
21442145
2146
2147
351
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
15.8[17.8] January 24, 2014
Updated with review feedback from the 2014-01-13 conference call.
1. Refactored section 9 to other locations as per meeting review.
2. Moved section 10 content to section 6 and deleted section 10 as per meeting review.
3. Updated some portions of the “Security” section (what is in this revision labeled section 9) with references back to the HTTP section and also using notes and replies from the reflector.
15.9[17.9] April 10, 2014
Updated with review feedback from the February 2014 PWG Face-to-Face and many updates and document structure changes, to resolve all instances of "TBD" in the document. First Prototype draft.
1. Replaced all instances of TBD with their appropriate descriptions. This includes the examination of many attributes in section 5.
2. Rewrote several significant sections of section 4.
3. Added new section on document type considerations, discussing the proper use of “application/octet-stream”, and the difference between media types that are “streaming” and have historically been used as PDLs, as compared with other media types that are more structured.
4. Added conformance requirements but haven't filled it out with a detailed list yet.
5. Listed additional references to RFC 3380, 3995-3997.
6. Many other changes.
15.10[17.10] May 13, 2014
Updated start of section 5.8 to include a table of the attributes to be discussed in the subsections of 5.8, right before the May 2014 Face-to-Face. No other significant changes.
15.11[17.11] August 14, 2014
Updated with review feedback from August 2014 PWG Face-to-Face meeting review of Section 7 and start of Section 8. Earlier sections include incomplete updates that should be disregarded by the reader.
Page 120 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
352353
2148
2149
2150
21512152
215321542155
2156
215721582159
21602161
2162
2163216421652166
2167
2168
2169
2170
217121722173
2174
217521762177
354
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
15.12[17.12] November 13, 2014
Updated with review feedback from May 2014 PWG Face-to-Face and subsequent conference calls.
1. Replaced all instances of TBD with their appropriate descriptions. This includes the examination of many attributes in section 5.
2. Rewrote several significant sections of section 4. Contemplating a shift to UML sequence diagrams for section 4.
3. Added new section on document type considerations, discussing the proper use of “application/octet-stream”, and the difference between media types that are “streaming” and have historically been used as PDLs, as compared with other media types that are more structured.
4. Added conformance requirements but haven't filled it out with a detailed list yet.
5. Listed additional references to many RFCs and PWG specifications now referenced by this document
6. Reviewed all meeting minutes since May 2014 and made sure that all points were at least considered if not addressed. Open issues (whether new or dating from earlier) marked with comments for future discussion.
7. Additional IPPS interoperability considerations.
15.13[17.13] January 27, 2015
Updated with review feedback on wd-ig-20141113-rev.pdf in several conference calls.
1. Updated section 4 with UML sequence diagrams, generated using PlantUML and the sources added in the new Section 16, to replace the bulleted lists, which were becoming unwieldy.
2. Resolved issues as per feedback from 2014-12-08 conference call meeting minutes
3. Resolved issues as per feedback from 2015-01-05 conference call meeting minutes
15.14[17.14] February 11, 2015
Updated following February 2015 F2F review - anticipating this revision will be WG last call.
1. Reviewed the rest of the document starting with §10
Page 121 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
355356
2178
21792180
21812182
21832184
2185218621872188
2189
21902191
219221932194
2195
2196
2197
219821992200
2201
2202
2203
22042205
2206
357
Working Draft – IPP Implementor's Guide v2.0 (IG) May 23, 2023
a. Re-ordered some of the later sections to more closely resemble the current template
b. Added reference to IANA PWG Registry
2. Resolved all "open question" comments
a. Merged two "BEST" options from §4.4
b. Updated §5.9 to call out the impracticality of implementing "pdl-override-supported" = 'guaranteed' for all but the simplest document formats
c. Decided that if IPPS is enabled but IPP is not then the Printer should use HTTP redirection and NOT mandate that the Printer implement any "basic set" of IPP
3. Resolved all feedback recorded in meeting minutes from February 4 review at the 2015 February PWG F2F (see ippv2-concall-minutes-20150105.pdf)
4. Added missing references, checked all references to be bookmarks, re-checked grammar and spelling
Page 122 of 122 Copyright © 20145 The Printer Working Group. All rights reserved.
358359
22072208
2209
2210
2211
22122213
221422152216
22172218
22192220
2221
360