RFC 2911
Internet Printing Protocol/1.1: Model and Semantics
Internet Printing Protocol/1.1: Model and Semantics 🖨️✨
okay bestie, let's get into RFC 2911 💖 It's on the Standards Track 🔥, so this is an actual Internet standard, not just a vibe. It was written by T. Hastings (the editor), R. Herriot, R. deBry, S. Isaacson, and P. Powell, from Xerox Corporation, Utah Valley State College, Novell, Inc., and Astart Technologies. It's dated September 2000, and it obsoletes RFC 2566 🦋
Status of this Memo 📝
this is an Internet standards track protocol for the Internet community, and they're literally asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol is in the standardization process, check the current "Internet Official Protocol Standards" document (STD 1). Distribution of this memo is unlimited 🌸
Copyright Notice 💜
Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀
Abstract 🧚
so this document is one piece of a whole set that together explains every part of the new Internet Printing Protocol (IPP) 🖨️ IPP is an application-level protocol for distributed printing using normal Internet tools and technologies. It's giving clean design, honestly 💅 The document describes a simplified model made of abstract objects, their attributes, and their operations, and the model doesn't depend on any particular encoding or transport 🌈
The model has two main objects: a Printer and a Job. A Job can optionally handle multiple documents 📄 IPP 1.1 semantics let end users and operators query printer capabilities, submit print jobs, check on the status of jobs and printers, and cancel, hold, release, and restart jobs ✨ Operators also get to pause, resume, and purge (jobs from) Printer objects, which is very main character energy for the admin crew 👑 The document also covers security, internationalization, and directory issues 🔐
The full IPP set includes these documents:
- Design Goals for an Internet Printing Protocol [RFC2567]
- Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568]
- Internet Printing Protocol/1.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
- Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
- Mapping between LPD and IPP Protocols [RFC2569]
the "Design Goals for an Internet Printing Protocol" doc takes a big-picture look at distributed printing and walks through real-life scenarios to show which features a printing protocol for the Internet needs 🧠 It covers requirements for three kinds of users: end users, operators, and administrators. It calls out which end-user requirements are already met in IPP/1.0, and a few OPTIONAL operator operations were added in IPP/1.1 🍓
the "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" doc is the high-level overview 🦋 It maps out the other documents in the IPP suite and explains the background and reasoning behind the IETF working group's big decisions. Very helpful if you're lost, iykyk 🫶
the "Internet Printing Protocol/1.1: Encoding and Transport" doc is where the abstract operations and attributes from this model get formally mapped onto HTTP/1.1 [RFC2616] 🌐 It defines the encoding rules for a new Internet MIME media type called application/ipp, and it explains how to carry a message body with application/ipp as its Content-Type over HTTP. It also defines a new scheme, ipp, for identifying IPP printers and jobs ✨
the "Internet Printing Protocol/1.1: Implementer's Guide" doc is the friend who gives advice to people building IPP clients and IPP objects 💖 It helps implementers understand IPP/1.1 and the things they might want to think about when designing their client and/or IPP object implementations. For example, it shows a typical order for processing requests, including error checking, and it explains the reasons behind some of the spec decisions 🧚
the "Mapping between LPD and IPP Protocols" doc gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations 🖨️💜
Table of Contents 🌸
the rest of the document, including the table of contents and everything after it, continues in part 2, so stay tuned, bestie 🎀✨
Okay bestie, this part is basically the big map of the whole spec 🗺️✨ Every section number and name is locked in exactly as written, so you can find anything fast.
1. Introduction 9
1.1 Simplified Printing Model 10
2. IPP Objects 12
2.1 Printer Object 13
2.2 Job Object 15
2.3 Object Relationships 16
2.4 Object Identity 17
3. IPP Operations 20
3.1 Common Semantics 21
3.1.1 Required Parameters 21
3.1.2 Operation IDs and Request IDs 22
3.1.3 Attributes 22
3.1.4 Character Set and Natural Language Operation Attribute 24
3.1.4.1 Request Operation Attributes 25
3.1.4.2 Response Operation Attributes 29
3.1.5 Operation Targets 30
3.1.6 Operation Response Status Codes and Status Messages 32
3.1.6.1 "status-code" (type2 enum) 32
3.1.6.2 "status-message" (text(255)) 33
3.1.6.3 "detailed-status-message" (text(MAX)) 33
3.1.6.4 "document-access-error" (text(MAX)) 34
3.1.7 Unsupported Attributes 34
3.1.8 Versions 36
3.1.9 Job Creation Operations 38
3.2 Printer Operations 41
3.2.1 Print-Job Operation 41
3.2.1.1 Print-Job Request 41
3.2.1.2 Print-Job Response 46
3.2.2 Print-URI Operation 48
3.2.3 Validate-Job Operation 49
3.2.4 Create-Job Operation 49
3.2.5 Get-Printer-Attributes Operation 50
3.2.5.1 Get-Printer-Attributes Request 51
3.2.5.2 Get-Printer-Attributes Response 53
3.2.6 Get-Jobs Operation 54
3.2.6.1 Get-Jobs Request 54
3.2.6.2 Get-Jobs Response 56
3.2.7 Pause-Printer Operation 57
3.2.7.1 Pause-Printer Request 59
3.2.7.2 Pause-Printer Response 60
3.2.8 Resume-Printer Operation 60
3.2.9 Purge-Jobs Operation 61
3.3 Job Operations 62
3.3.1 Send-Document Operation 62
3.3.1.1 Send-Document Request 64
3.3.1.2 Send-Document Response 65
3.3.2 Send-URI Operation 66
3.3.3 Cancel-Job Operation 66
3.3.3.1 Cancel-Job Request 67
3.3.3.2 Cancel-Job Response 68
3.3.4 Get-Job-Attributes Operation 69
3.3.4.1 Get-Job-Attributes Request 69
3.3.4.2 Get-Job-Attributes Response 70
3.3.5 Hold-Job Operation 71
3.3.5.1 Hold-Job Request 72
3.3.5.2 Hold-Job Response 73
3.3.6 Release-Job Operation 74
3.3.7 Restart-Job Operation 75
3.3.7.1 Restart-Job Request 76
3.3.7.2 Restart-Job Response 78
4. Object Attributes 78
4.1 Attribute Syntaxes 78
4.1.1 'text' 79
4.1.1.1 'textWithoutLanguage' 80
4.1.1.2 'textWithLanguage' 80
4.1.2 'name' 81
4.1.2.1 'nameWithoutLanguage' 82
4.1.2.2 'nameWithLanguage' 82
4.1.2.3 Matching 'name' attribute values 83
4.1.3 'keyword' 84
4.1.4 'enum' 85
4.1.5 'uri' 85
4.1.6 'uriScheme' 86
4.1.7 'charset' 86
4.1.8 'naturalLanguage' 87
4.1.9 'mimeMediaType' 87
4.1.9.1 Application/octet-stream -- Auto-Sensing 88
the document format
4.1.10 'octetString' 89
4.1.11 'boolean' 89
4.1.12 'integer' 89
4.1.13 'rangeOfInteger' 90
4.1.14 'dateTime' 90
4.1.15 'resolution' 90
4.1.16 '1setOf X' 90
4.2 Job Template Attributes 91
4.2.1 job-priority (integer(1:100)) 94
4.2.2 job-hold-until (type3 keyword | name (MAX)) 95
4.2.3 job-sheets (type3 keyword | name(MAX)) 96
4.2.4 multiple-document-handling (type2 keyword) 96
4.2.5 copies (integer(1:MAX)) 98
4.2.6 finishings (1setOf type2 enum) 98
4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 101
4.2.8 sides (type2 keyword) 102
4.2.9 number-up (integer(1:MAX)) 102
4.2.10 orientation-requested (type2 enum) 103
4.2.11 media (type3 keyword | name(MAX)) 104
4.2.12 printer-resolution (resolution) 105
4.2.13 print-quality (type2 enum) 105
4.3 Job Description Attributes 106
4.3.1 job-uri (uri) 107
4.3.2 job-id (integer(1:MAX)) 108
4.3.3 job-printer-uri (uri) 108
4.3.4 job-more-info (uri) 108
4.3.5 job-name (name(MAX)) 108
4.3.6 job-originating-user-name (name(MAX)) 109
4.3.7 job-state (type1 enum) 109
4.3.7.1 Forwarding Servers 112
4.3.7.2 Partitioning of Job States 112
4.3.8 job-state-reasons (1setOf type2 keyword) 113
4.3.9 job-state-message (text(MAX)) 118
4.3.10 job-detailed-status-messages (1setOf text(MAX)) 118
4.3.11 job-document-access-errors (1setOf text(MAX)) 118
4.3.12 number-of-documents (integer(0:MAX)) 119
4.3.13 output-device-assigned (name(127)) 119
4.3.14 Event Time Job Description Attributes 119
4.3.14.1 time-at-creation (integer(MIN:MAX)) 120
4.3.14.2 time-at-processing (integer(MIN:MAX)) 120
4.3.14.3 time-at-completed (integer(MIN:MAX)) 120
4.3.14.4 job-printer-up-time (integer(1:MAX)) 120
4.3.14.5 date-time-at-creation (dateTime) 121
4.3.14.6 date-time-at-processing (dateTime) 121
4.3.14.7 date-time-at-completed (dateTime) 121
4.3.15 number-of-intervening-jobs (integer(0:MAX)) 121
4.3.16 job-message-from-operator (text(127)) 121
4.3.17 Job Size Attributes 121
4.3.17.1 job-k-octets (integer(0:MAX)) 122
4.3.17.2 job-impressions (integer(0:MAX)) 122
4.3.17.3 job-media-sheets (integer(0:MAX)) 123
4.3.18 Job Progress Attributes 123
4.3.18.1 job-k-octets-processed (integer(0:MAX)) 123
4.3.18.2 job-impressions-completed (integer(0:MAX)) 123
4.3.18.3 job-media-sheets-completed (integer(0:MAX)) 124
4.3.19 attributes-charset (charset) 124
4.3.20 attributes-natural-language (naturalLanguage) 124
4.4 Printer Description Attributes 124
4.4.1 printer-uri-supported (1setOf uri) 126
4.4.2 uri-authentication-supported (1setOf type2 keyword) 127
4.4.3 uri-security-supported (1setOf type2 keyword) 128
4.4.4 printer-name (name(127)) 129
4.4.5 printer-location (text(127)) 129
4.4.6 printer-info (text(127)) 130
4.4.7 printer-more-info (uri) 130
4.4.8 printer-driver-installer (uri) 130
4.4.9 printer-make-and-model (text(127)) 130
4.4.10 printer-more-info-manufacturer (uri) 130
4.4.11 printer-state (type1 enum) 131
4.4.12 printer-state-reasons (1setOf type2 keyword) 131
4.4.13 printer-state-message (text(MAX)) 134
4.4.14 ipp-versions-supported (1setOf type2 keyword) 134
4.4.15 operations-supported (1setOf type2 enum) 135
4.4.16 multiple-document-jobs-supported (boolean) 136
4.4.17 charset-configured (charset) 136
4.4.18 charset-supported (1setOf charset) 137
4.4.19 natural-language-configured (naturalLanguage) 137
4.4.20 generated-natural-language-supported
(1setOf naturalLanguage) 137
4.4.21 document-format-default (mimeMediaType) 138
4.4.22 document-format-supported (1setOf mimeMediaType) 138
4.4.23 printer-is-accepting-jobs (boolean) 138
4.4.24 queued-job-count (integer(0:MAX)) 138
4.4.25 printer-message-from-operator (text(127)) 139
4.4.26 color-supported (boolean) 139
4.4.27 reference-uri-schemes-supported (1setOf uriScheme) 139
4.4.28 pdl-override-supported (type2 keyword) 139
4.4.29 printer-up-time (integer(1:MAX)) 140
4.4.30 printer-current-time (dateTime) 140
4.4.31 multiple-operation-time-out (integer(1:MAX)) 141
4.4.32 compression-supported (1setOf type3 keyword) 141 4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX)) 142
4.4.34 job-impressions-supported (rangeOfInteger(0:MAX)) 142
4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX)) 142
4.4.36 pages-per-minute (integer(0:MAX)) 142
4.4.37 pages-per-minute-color (integer(0:MAX)) 142
5. Conformance 143
5.1 Client Conformance Requirements 143
5.2 IPP Object Conformance Requirements 145
5.2.1 Objects 145
5.2.2 Operations 145
5.2.3 IPP Object Attributes 146
5.2.4 Versions 146
5.2.5 Extensions 147
5.2.6 Attribute Syntaxes 147
5.2.7 Security 148
5.3 Charset and Natural Language Requirements 148
6. IANA Considerations 148
6.1 Typed 'keyword' and 'enum' Extensions 149
6.2 Attribute Extensibility 151
6.3 Attribute Syntax Extensibility 152
6.4 Operation Extensibility 152
6.5 Attribute Group Extensibility 153
6.6 Status Code Extensibility 153
6.7 Out-of-band Attribute Value Extensibility 154
6.8 Registration of MIME types/sub-types for document-formats 154
6.9 Registration of charsets for use in 'charset'
attribute values 154
7. Internationalization Considerations 154
8. Security Considerations 158
8.1 Security Scenarios 159
8.1.1 Client and Server in the Same Security Domain 159
8.1.2 Client and Server in Different Security Domains 159
8.1.3 Print by Reference 160
8.2 URIs in Operation, Job, and Printer attributes 160
8.3 URIs for each authentication mechanisms 160
8.4 Restricted Queries 161
8.5 Operations performed by operators and system
administrators 161
8.6 Queries on jobs submitted using non-IPP protocols 162
9. References 162
10. Authors' Addresses 166
11. Formats for IPP Registration Proposals 168
11.1 Type2 keyword attribute values registration 169
11.2 Type3 keyword attribute values registration 169
11.3 Type2 enum attribute values registration 169
11.4 Type3 enum attribute values registration 170
11.5 Attribute registration 170
11.6 Attribute Syntax registration 171
11.7 Operation registration 171
11.8 Attribute Group registration 171
11.9 Status code registration 172
11.10 Out-of-band Attribute Value registration 172
12. APPENDIX A: Terminology 173
12.1 Conformance Terminology 173
12.1.1 NEED NOT 173
12.2 Model Terminology 173
12.2.1 Keyword 173
12.2.2 Attributes 173
12.2.2.1 Attribute Name 173
12.2.2.2 Attribute Group Name 174
12.2.2.3 Attribute Value 174
12.2.2.4 Attribute Syntax 174
12.2.3 Supports 174
12.2.4 print-stream page 176
12.2.5 impression 177
13. APPENDIX B: Status Codes and Suggested Status Code Messages 177
13.1 Status Codes 178
13.1.1 Informational 178
13.1.2 Successful Status Codes 178
13.1.2.1 successful-ok (0x0000) 178
13.1.2.2 successful-ok-ignored-or-substituted-attributes
(0x0001) 179
13.1.2.3 successful-ok-conflicting-attributes (0x0002) 179
13.1.3 Redirection Status Codes 179
13.1.4 Client Error Status Codes 179
13.1.4.1 client-error-bad-request (0x0400) 180
13.1.4.2 client-error-forbidden (0x0401) 180
13.1.4.3 client-error-not-authenticated (0x0402) 180
13.1.4.4 client-error-not-authorized (0x0403) 180
13.1.4.5 client-error-not-possible (0x0404) 180
13.1.4.6 client-error-timeout (0x0405) 181
13.1.4.7 client-error-not-found (0x0406) 181
13.1.4.8 client-error-gone (0x0407) 181
13.1.4.9 client-error-request-entity-too-large (0x0408) 182
13.1.4.10 client-error-request-value-too-long (0x0409) 182
13.1.4.11 client-error-document-format-not-supported (0x040A) 182
13.1.4.12 client-error-attributes-or-values-not-supported
(0x040B) 183
13.1.4.13 client-error-uri-scheme-not-supported (0x040C) 183
13.1.4.14 client-error-charset-not-supported (0x040D) 183
13.1.4.15 client-error-conflicting-attributes (0x040E) 183
13.1.4.16 client-error-compression-not-supported (0x040F) 184
13.1.4.17 client-error-compression-error (0x0410) 184
13.1.4.18 client-error-document-format-error (0x0411) 184
13.1.4.19 client-error-document-access-error (0x0412) 184
13.1.5 Server Error Status Codes 185
13.1.5.1 server-error-internal-error (0x0500) 185
13.1.5.2 server-error-operation-not-supported (0x0501) 185
13.1.5.3 server-error-service-unavailable (0x0502) 185
13.1.5.4 server-error-version-not-supported (0x0503) 185
13.1.5.5 server-error-device-error (0x0504) 186
13.1.5.6 server-error-temporary-error (0x0505) 186
13.1.5.7 server-error-not-accepting-jobs (0x0506) 187
13.1.5.8 server-error-busy (0x0507) 187
13.1.5.9 server-error-job-canceled (0x0508) 187
13.1.5.10 server-error-multiple-document-jobs-not-supported
(0x0509) 187
13.2 Status Codes for IPP Operations 187
14. APPENDIX C: "media" keyword values 190
15. APPENDIX D: Processing IPP Attributes 208
15.1 Fidelity 209
15.2 Page Description Language (PDL) Override 210
15.3 Using Job Template Attributes During Document Processing 212
16. APPENDIX E: Generic Directory Schema 214
17. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1
"Model and Semantics" Documents 215
18. Full Copyright Statement 2241. Introduction 🦋
The Internet Printing Protocol (IPP) is an application level protocol that lets you do distributed printing using Internet tools and technologies, and it's giving modern ✨. IPP version 1.1 (IPP/1.1) is mostly about end user stuff, with a few admin operations sprinkled in. This document is just one piece of a suite that fully defines IPP. The whole set looks like this:
- Design Goals for an Internet Printing Protocol [RFC2567]
- Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568]
- Internet Printing Protocol/1.1: Model and Semantics (this document)
- Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
- Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
- Mapping between LPD and IPP Protocols [RFC2569]
Anyone reading these for the first time is strongly encouraged to read them in the order above. Trust me, bestie 🫶.
Here's how this document is laid out, so you can find your way around 🗺️:
- The rest of Section 1 is an introduction to the IPP simplified model for distributed printing.
- Section 2 introduces the object types covered in the model, with their basic behaviors, attributes, and interactions.
- Section 3 defines the operations included in IPP/1.1. IPP operations are synchronous, so for each operation there is both a request and a response.
- Section 4 defines the attributes (and their syntaxes) that are used in the model.
- Sections 5 - 6 summarize the implementation conformance requirements for objects that support the protocol, and the IANA considerations, respectively.
- Sections 7 - 11 cover the Internationalization and Security considerations, as well as References, Author contact information, and Formats for Registration Proposals.
- Sections 12 - 14 are appendices covering Terminology, Status Codes and Messages, and "media" keyword values.
Note: This document uses terms such as "attributes", "keywords", and "support". These terms have special meaning and are defined in the model terminology section 12.2. Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance. These terms are defined in section 12.1 on conformance terminology, most of which is taken from RFC 2119 [RFC2119]. 🧠
- Section 15 is an appendix that helps clarify the effects of interactions between related attributes and their values.
- Section 16 is an appendix that enumerates the subset of Printer attributes that form a generic directory schema. These attributes are useful when registering a Printer, so that a client can find the Printer not just by name, but by filtered searches as well. 🔍
- Section 17 is an appendix summarizing the additions and changes from the IPP/1.0 "Model and Semantics" document [RFC2566] that produced this IPP/1.1 document.
- Section 18 is the full copyright notice.
1.1. Simplified Printing Model ✨
okay so bestie, the whole point of IPP is to make a printing protocol that actually works over the Internet, and to do that it uses a simplified printing model 🖨️💖 It hides all the messy parts of real-world printing so you only see the key stuff. The Internet is this huge distributed world where people who want to print (clients, apps, printer drivers, etc.) work with print service providers, and the setups underneath can be super complicated "n-tier" client/server systems. This model stays simple and abstract anyway, which is honestly iconic ✨ IPP only exposes the key objects and interfaces that printing needs, and this document doesn't cover anything that's beyond the scope of the first version of IPP (IPP/1.1) 🦋
IPP/1.1 borrows a bunch of good ideas and lessons from other specs and dev efforts: [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP]. It's especially inspired by the printing model from the Document Printing Application (DPA) [ISO10175] standard 👑 DPA covers both end-user and administrative features, but IPP/1.1 mostly focuses on end users, with a few extra OPTIONAL operator operations thrown in 💅
The IPP/1.1 model wraps up the important parts of distributed printing into two object types:
- Printer (Section 2.1)
- Job (Section 2.2)
Each object type has its own set of operations (see section 3) and attributes (see section 4) 🎀
Okay, but real systems have more going on underneath this abstracted model, and IPP/1.1 doesn't define all of it explicitly. Here's a little diagram showing where IPP/1.1 fits in with the other pieces 🧚
+--------------+
| Application |
o +. . . . . . . |
\|/ | Spooler |
/ \ +. . . . . . . | +---------+
End-User | Print Driver |---| File |
+-----------+ +-----+ +------+-------+ +----+----+
| Browser | | GUI | | |
+-----+-----+ +--+--+ | |
| | | |
| +---+------------+---+ |
N D S | | IPP Client |------------+
O I E | +---------+----------+
T R C | |
I E U |
F C R -------------- Transport ------------------
I T I
C O T | --+
A R Y +--------+--------+ |
T Y | IPP Server | |
I +--------+--------+ |
O | |
N +-----------------+ | IPP Printer
| Print Service | |
+-----------------+ |
| --+
+-----------------+
| Output Device(s)|
+-----------------+So an IPP Printer object basically packs in the stuff a physical output device normally does, plus the spooling, scheduling, and multi-device management that a print server usually handles 🖨️✨ Printer objects can be optionally registered as entries in a directory, where end users find and pick them using some kind of filtered, context-based search (see section 16) 🔍 The directory only stores relatively static info about the Printer, like name, context, and capabilities, so people can search and find printers that match what they need. The more dynamic stuff, like state, loaded and ready media, number of jobs at the Printer, errors, warnings, and so on, lives right on the Printer object itself, not in the directory entry, which just represents it 💜
IPP clients run the IPP protocol on the client side and let end users (or programs acting for them) query Printer objects and submit and manage print jobs 🫶 An IPP server is just the server-side part of the Printer object. The rest of the Printer object is the bit that implements (or gateways into) the actual application semantics of the print service 😭 Printer objects can live inside an output device, or they can run on a host on the network that talks to an output device 🌸
When a job gets submitted and the Printer object validates the attributes in the request, the Printer object creates a brand new Job object 🦋 The end user then interacts with that Job object to check its status and watch its progress. Users can also cancel their own print jobs with the Job object's Cancel-Job operation. Plus, they can hold, release, and restart their jobs using the Job object's OPTIONAL Hold-Job, Release-Job, and Restart-Job operations, if the implementation supports them 🍓
A privileged operator or administrator of a Printer object can cancel, hold, release, and restart any user's job using the REQUIRED Cancel-Job operation and the OPTIONAL Hold-Job, Release-Job, and Restart-Job operations 👑 Admins can also pause, resume, or purge jobs from a Printer object with the OPTIONAL Pause-Printer, Resume-Printer, and Purge-Jobs operations, if implemented 💅
The notification service is out of scope for this IPP/1.1 document. Still, with one, end users can register for and receive Printer-specific and Job-specific events 🔔
Without notifications, end users can keep up by polling: checking the status of Printer objects and following the progress of Job objects with the Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes operations 🌈
2. IPP Objects 🧚
the IPP/1.1 model introduces two object types, Printer and Job 🖨️ Each type models the relevant parts of a real-world thing, like an actual printer or an actual print job. Every object type is defined as a set of possible attributes that instances of that type may support. For each object (instance), the actual set of supported attributes and values describes one specific implementation 💖 The attributes and values describe its state, capabilities, realizable features, job processing functions, and default behaviors and characteristics. For example, the Printer object type is a set of attributes that each Printer object could potentially support, and the Job object type is the same idea for Job objects ✨
Every attribute in the set that defines an object type gets labeled as one of these:
- "REQUIRED": each object MUST support the attribute.
- "RECOMMENDED": each object SHOULD support the attribute.
- "OPTIONAL": each object MAY support the attribute.
Some attribute value definitions say an object MUST or SHOULD support a particular value. Otherwise, supporting that value is OPTIONAL 🎀
But here's the big rule, bestie: if an implementation supports an attribute, it MUST support at least one of the possible values for that attribute 🔥
2.1. Printer Object 🖨️✨
Okay, the star of the whole IPP/1.1 model is the Printer object 👑. It's the server side of the IPP/1.1 protocol 🫶. Through the protocol, end users can look up the attributes of a Printer object and submit print jobs to it 💌. The real stuff behind the Printer abstraction can look super different and be set up in all kinds of ways, but the model keeps those details hidden from the end user 🙈. Section 3 walks through each Printer operation in detail 💅.
The capabilities and state of a Printer object are described by its attributes, and those split into two groups:
- "job-template" attributes: These describe the job processing capabilities the Printer object supports, plus its defaults. (See section 4.2)
- "printer-description" attributes: These cover the Printer object's identification, state, location, references to other sources of information about it, and more. (see section 4.4)
Since a Printer object is an abstraction of a generic document output device and print service provider, it can represent any real or virtual device with semantics that fit the Printer object 🦋. That includes things like a fax device, an imager, or even a CD writer 💿.
Some examples of configurations that support a Printer object:
- An output device with no spooling capabilities
- An output device with a built-in spooler
- A print server supporting IPP with one or more associated output devices 3a) The associated output devices may or may not be capable of spooling jobs 3b) The associated output devices may or may not support IPP
The figures below show how Printer objects can be realized on top of different distributed printing setups 🌸. The embedded case covers configurations 1 and 2, and the hosted and fan-out figures cover configurations 3a and 3b.
In this document, "client" means a software entity that sends IPP operation requests to an IPP Printer object and accepts the IPP operation responses 🎀. A client MAY be:
- contained within software controlled by an end user, e.g. activated by the "Print" menu item in an application, or
- the print server component that sends IPP requests to either an output device or another "downstream" print server.
"IPP Printer" is a network entity that accepts IPP operation requests and returns IPP operation responses 🧚. So an IPP object MAY be:
- an (embedded) device component that accepts IPP requests and controls the device, or
- a component of a print server that accepts IPP requests (where the print server controls one or more networked devices using IPP or other protocols).
Here's the legend for the figures 🗝️:
Legend:
##### indicates a Printer object which is
either embedded in an output device or is
hosted in a server. The Printer object
might or might not be capable of queuing/spooling.
any indicates any network protocol or direct
connect, including IPPNow the pictures 📸:
embedded printer:
output device
+---------------+
O +--------+ | ########### |
/|\ | client |------------IPP------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
+---------------+
hosted printer:
+---------------+
O +--------+ ########### | |
/|\ | client |--IPP--># Printer #-any->| output device |
/ \ +--------+ # Object # | |
########### +---------------+
+---------------+
fan out: | |
+-->| output device |
any/ | |
O +--------+ ########### / +---------------+
/|\ | client |-IPP-># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
+-->| output device |
| |
+---------------+2.2. Job Object 📄💫
A Job object is how we model a print job 🧁. A Job object contains documents. The info needed to create a Job object goes out in a create request, from the end user through an IPP Client to the Printer object. The Printer object checks the create request, and if it accepts the request, it creates the new Job object 🙌. Section 3 describes each of the Job operations in detail.
A Job object's characteristics and state are described by its attributes, which fall into two groups:
- "job-template" attributes: These can be supplied by the client or end user, and they include job processing instructions meant to override any Printer object defaults and/or instructions embedded within the document data. (See section 4.2)
- "job-description" attributes: These describe the Job object's identification, state, size, etc. The client supplies some of them, and the Printer object generates the rest. (See section 4.3)
An implementation MUST support at least one document per Job object 🫶. An implementation MAY support multiple documents per Job object 🌈. A document is either:
- a stream of document data in a format supported by the Printer object (typically a Page Description Language - PDL), or
- a reference to such a stream of document data
In IPP/1.1, a document isn't modeled as an IPP object, so it has no object identifier or associated attributes 🙈. All job processing instructions are modeled as Job object attributes instead. These are called Job Template attributes, and they apply equally to all documents within a Job object 💜.
2.3. Object Relationships 🔗🦋
IPP objects have relationships that are kept persistently, along with the persistent storage of the object attributes 💾.
A Printer object can represent one or more physical output devices, or a logical device that "processes" jobs but never actually uses a physical output device to put marks on paper 🧠. Examples of logical devices include a Web page publisher or a gateway into an online document archive or repository. A Printer object contains zero or more Job objects 📚.
A Job object is contained by exactly one Printer object 💅. However, the identical document data associated with a Job object could be sent to either the same or a different Printer object. In that case, a second Job object would be created that's almost identical to the first one, but it would have new (different) Job object identifiers (see section 2.4) ✨.
A Job object is either empty (before any documents have been added) or contains one or more documents 🎀. If the contained document is a stream of document data, that stream can be contained in only one document. There can, though, be identical copies of the stream in other documents in the same or different Job objects 🍓. If the contained document is just a reference to a stream of document data, other documents (in the same or different Job objects) may contain the same reference 🫧.
2.4 Object Identity 🆔✨
okay so every Printer and Job object gets a Uniform Resource Identifier (URI) [RFC2396] 🦋 so it can be referenced forever without any confusion. A URL is just a specialized kind of URI, so even though this document says "URI" all the way through, it covers URLs too 💖
An administrator sets up each Printer object to either support or not support authentication and/or message privacy using Transport Layer Security (TLS) [RFC2246] 🔐 (how that security gets configured is totally outside this IPP/1.1 document, so no spoilers here). Sometimes both kinds of connection, authenticated and unauthenticated, can live on one single communication channel that has some kind of negotiation going on 🤝. Other times there are multiple channels, one for each security setup 🎀. Section 8 has the full tea on every security consideration and configuration, so go check it out 👑
If a Printer object has more than one communication channel, some or all of them might use different security mechanisms, or require them 🌈. In that case, an administrator can show all those channels at once as multiple URIs for one Printer object, where each URI stands for one of the channels 🦋. To make this work, the IPP Printer object type has a multi-valued identification attribute called printer-uri-supported. It MUST contain at least one URI. It MAY contain more than one URI. So basically, every Printer object has at least one URI that points to at least one channel, and it might have extra URIs, each pointing to a different channel 💅
printer-uri-supported has two best-friend attributes: uri-security-supported and uri-authentication-supported. Both have the same cardinality as printer-uri-supported 💜. uri-security-supported tells you which security mechanisms (if any) are used for each URI listed in printer-uri-supported. uri-authentication-supported tells you which authentication mechanisms (if any) are used for each URI listed in printer-uri-supported 🔥. All three of these attributes get the full breakdown in sections 4.4.1, 4.4.2, and 4.4.3 🌸
When a job gets submitted to a Printer object through a create request, the client only supplies a single Printer object URI 🍓. And that client-supplied Printer object URI MUST be one of the values in the printer-uri-supported Printer attribute 👑
IPP/1.1 doesn't say how the client gets that URI in the first place 🤷♀️. But it is RECOMMENDED that a Printer object be registered as an entry in a directory service 📒. Then end-users and programs can go searching the directory for Printers 🔍. Section 16 defines a generic schema for Printer object entries in the directory service and explains how that entry acts as a bridge to the actual IPP Printer object 🧚. The directory entry for the IPP Printer object includes the possibly many URIs for that Printer object, stored as values in one of its attributes 🫶
When a client sends a create request to the Printer object, the Printer object checks the request and creates a brand new Job object ✨. The Printer object gives the new Job object a URI, which gets stored in the job-uri Job attribute 💖. Clients then use that URI as the target for later Job operations 🎯. The Printer object builds that Job URI based on its configured security policy and the URI the client used in the create request 🔐
Here's an example, because examples make everything click 🙈. Say a Printer object supports two channels: one secured with SSL3 (HTTP over SSL3, with an https URI), and one open channel that isn't secured with SSL3 (a simple http URI) 🌈. If a client submits a job using the secure URI, the Printer object gives the new Job object a secure URI too 🔒. If a client submits a job using the open-channel URI, the Printer gives the new Job object an open-channel URI 🦋
The Printer object also fills in the Job object's job-printer-uri attribute 💜. This is a reference back to the Printer object that created the Job object 👑. So if a client only has the Job object's job-uri, it can query job-printer-uri to figure out which Printer object made the Job 🕵️♀️. If the Printer object supports more than one URI, it uses the one URI the client supplied when creating the job to build the value of job-printer-uri and to populate that attribute 🎀
Giving Job objects their own URIs is all about flexibility and scalability 🚀. For example, in some setups the Printer object might create Jobs that get processed in the same local environment as the Printer itself 🏠. In that case, the Job URI might just be the Printer's URI plus some unique piece for the Job, like the unique 32-bit positive integer mentioned later in this paragraph 🧩. In other setups, the Printer object might be a central clearing-house that validates every Job creation request, while the Job object itself is created in some environment far away from the Printer 🌍. Then the Job object's URI might have no physical-location relationship at all to the Printer object's URI 🛸. Again, the fact that Jobs have URIs is what makes this flexible and scalable 💅. BUT, many existing printing systems have local models or interface constraints that force print jobs to be identified using only a 32-bit positive integer, rather than an independent URI 😭. This numeric Job ID is only unique within the context of the Printer object the create request was originally submitted to 🔢. So, to let both kinds of clients access IPP Job objects (either by Job URI or by numeric Job ID), when the Printer object successfully processes a create request and creates a new Job object, the Printer object MUST generate both a Job URI and a Job ID 🫶. The Job ID (stored in the job-id attribute) only has meaning in the context of the Printer object the create request was originally submitted to 💜. This requirement to support both Job URIs and Job IDs means every type of client can reach Printer and Job objects, no matter what local constraints the client implementation has 🌈
On top of identifiers, Printer and Job objects also have names (printer-name and job-name) 🏷️. An object name NEED NOT be unique across all instances of all objects 🤍. An administrator picks and sets a Printer object's name through some mechanism outside the scope of this IPP/1.1 document 🎀. A Job object's name is optionally chosen and supplied by the IPP client submitting the job 🌸. If the client doesn't supply a Job name, the Printer object generates one for the new Job object 🧚. In every case, the name only has local meaning 💖
To summarize, here's the whole identity situation 📝:
- Each Printer object is identified with one or more URIs. The Printer's
printer-uri-supportedattribute contains the URI(s). - The Printer object's
uri-security-supportedattribute identifies the communication channel security protocols that may or may not have been configured for the various Printer object URIs (e.g.,'tls'or'none'). - The Printer object's
uri-authentication-supportedattribute identifies the authentication mechanisms that may or may not have been configured for the various Printer object URIs (e.g.,'digest'or'none'). - Each Job object is identified with a Job URI. The Job's
job-uriattribute contains the URI. - Each Job object is also identified with a Job ID, which is a 32-bit, positive integer. The Job's
job-idattribute contains the Job ID. The Job ID is only unique within the context of the Printer object which created the Job object. - Each Job object has a
job-printer-uriattribute which contains the URI of the Printer object that was used to create the Job object. This attribute is used to determine the Printer object that created a Job object when given only the URI for the Job object. This linkage is necessary to determine the languages, charsets, and operations which are supported on that Job (the basis for such support comes from the creating Printer object). - Each Printer object has a name (which is not necessarily unique). The administrator chooses and sets this name through some mechanism outside the scope of this IPP/1.1 document. The Printer object's
printer-nameattribute contains the name. - Each Job object has a name (which is not necessarily unique). The client optionally supplies this name in the create request. If the client does not supply this name, the Printer object generates a name for the Job object. The Job object's
job-nameattribute contains the name.
3. IPP Operations 🛠️💅
IPP objects support operations 💪. An operation is made of a request and a response 📨. When a client talks to an IPP object, it issues an operation request to that object's URI 🎯. Operation requests and responses have parameters that identify the operation 🔎. Operations also have attributes that affect how they run (the intended target, localization information, and so on) 🌍. These operation-specific attributes are called operation attributes, which is different from object attributes like Printer object attributes or Job object attributes 🦋. Each request carries along any operation attributes, object attributes, and/or document data needed to perform the operation 🎁. Each request needs a response from the object 💌. Each response tells you whether the operation succeeded or failed, using a status code as a response parameter ✅❌. The response can contain any operation attributes, object attributes, and/or status messages generated while the operation request was running 📋
This section breaks down the semantics of the IPP operations, both requests and responses, in terms of their parameters, attributes, and other associated data 🧠✨
The IPP/1.1 Printer operations are 🖨️:
Print-Job (section 3.2.1)
Print-URI (section 3.2.2)
Validate-Job (section 3.2.3)
Create-Job (section 3.2.4)
Get-Printer-Attributes (section 3.2.5)
Get-Jobs (section 3.2.6)
Pause-Printer (section 3.3.5)
Resume-Printer (section 3.3.6)
Purge-Jobs (section 3.3.7)The Job operations are 📄:
Send-Document (section 3.3.1)
Send-URI (section 3.3.2)
Cancel-Job (section 3.3.3)
Get-Job-Attributes (section 3.3.4)
Hold-Job (section 3.3.5)
Release-Job (section 3.3.6)
Restart-Job (section 3.3.7)The Send-Document and Send-URI Job operations are used to add a new document to an existing multi-document Job object 📚. That Job object was created using the Create-Job operation 🫶
3.1 Common Semantics 🌸
All IPP operations need some common parameters and operation attributes 🎀. These shared elements, along with their semantic characteristics, get defined and described in more detail in the following sections 💜
3.1.1 Required Parameters 🎀
okay bestie, every operation request has to include these REQUIRED parameters 💅:
"version-number","operation-id","request-id", and- the attributes that are REQUIRED for that type of request.
and every operation response has these REQUIRED parameters too 🫶:
"version-number","status-code",- the
"request-id"that was supplied in the corresponding request, and - the attributes that are REQUIRED for that type of response.
the "Encoding and Transport" document [RFC2910] has the special encoding rules for these parameters 📚. everything else in an operation gets encoded with the more generic rules for attributes and groups of attributes ✨.
3.1.2 Operation IDs and Request IDs 🦋
every IPP operation request has an identifying "operation-id" value 🔥. the valid values are listed in the "operations-supported" Printer attribute section (see section 4.4.15). the client says which operation it wants by sending the right "operation-id" value, periodt 💖.
every single operation invocation also gets a "request-id" value 🌸. the client picks it, and it MUST be an integer (possibly unique, depending on what the client needs) somewhere in the range from 1 to 2**31 - 1 (inclusive) 💜. the "request-id" is how clients juggle multiple outstanding requests at once 👑. the receiving IPP object copies all 32 bits of the client-supplied "request-id" into the response, so the client can match each response to the right outstanding request, even if the "request-id" is out of range 🧚. if the request gets terminated before the full "request-id" arrives, the IPP object rejects it and sends back a response with a "request-id" of 0 💀.
Note: some transports underneath IPP are connection-oriented, which makes it impossible for a client to get responses in any order other than the order its requests went out. in those cases, the"request-id"attribute isn't essential for correct protocol operation 🙈. but in other mappings, operation responses can come back in any order, and then the"request-id"is absolutely essential 😭.
3.1.3 Attributes 🌈
operation requests and responses are both made up of groups of attributes and/or document data 🍓. the attribute groups are:
- Operation Attributes: these get passed in the operation and affect how the IPP object handles the operation request, and they might affect other attributes or groups of attributes too ✨. some of them describe the document data for the print job and get associated with new Job objects, but most operation attributes don't stick around past the life of the operation 🫶. each operation attribute's description has conformance statements that say which ones are REQUIRED and which are OPTIONAL for an IPP object to support, plus which attributes a client MUST supply in a request and which attributes an IPP object MUST supply in a response 💅.
- Job Template Attributes: these affect how a job gets processed 🔥. a client can optionally include Job Template Attributes in a create request, and the receiving object MUST be prepared to receive all supported attributes 💖. the Job object can be queried later to see which Job Template attributes were originally requested in the create request, and those come back in the response as Job Object Attributes 🌸. the Printer object can also be queried about its Job Template attributes to find out what job processing capabilities it supports and/or what its default job processing behaviors are, though those come back in the response as Printer Object Attributes 🧚. the
"ipp-attribute-fidelity"operation attribute affects how all client-supplied Job Template attributes are processed (see sections 3.2.1.2 and 15 for the full story on"ipp-attribute-fidelity"and how it relates to other attributes) 👑. - Job Object Attributes: these come back in response to a query operation aimed at a Job object 💜.
- Printer Object Attributes: these come back in response to a query operation aimed at a Printer object 🌈.
- Unsupported Attributes: in a create request, the client sends a set of Operation and Job Template attributes 🍓. if any of those attributes or their values aren't supported by the Printer object, the Printer object sends back the set of unsupported attributes in the response 💀. sections 3.1.7, 3.2.1.2, and 15 give the full scoop on how Job Template attributes from a create request get processed and how unsupported attributes get returned to the client 🙈. because of extensibility, any IPP object might get a request with new or unknown attributes or values it has no support for 😭. in that case, the IPP object processes what it can and returns the unsupported attributes in the response ✨. the Unsupported Attributes group is defined for all operation responses, so unsupported attributes the client supplied in the request can come back 🫶.
later in this section, every operation gets formally defined by spelling out the allowed and expected groups of attributes for each request and response 📚. the model sets a specific order for each group in each request or response, but the attributes inside each group can be in any order, unless something says otherwise 🦋.
the attributes within a group MUST be unique 🔥. if an attribute with the same name shows up more than once, the group is mal-formed 💅. clients MUST NOT submit malformed requests, and Printers MUST NOT return malformed responses 🙈. if a malformed request gets submitted to a Printer, the Printer MUST either (1) reject the request with the 'client-error-bad-request' status code (see section 13.1.4.1) or (2) process the request normally after selecting just one of the attribute instances, depending on implementation 💖. which attribute gets selected when there are duplicates depends on the implementation 🌸. the IPP Printer MUST NOT use the values from more than one of those duplicate attribute instances 🧚.
each attribute definition has the attribute's name, followed by the name of its attribute syntax(es) in parentheses 🎀. each integer attribute is also followed by its allowed range in parentheses, (m:n), for that attribute's values 🌈. each text or name attribute is followed by its maximum size in octets in parentheses, (size), for that attribute's values 🍓. for more on attribute syntax notation, check the descriptions of these attribute syntaxes in section 4.1 ✨.
Note: document data included in the operation isn't technically an attribute, but it gets treated as a special attribute group for ordering purposes 🫶. the only operations that support supplying document data inside an operation request are Print-Job and Send-Document 👑. no operation responses include document data 💀.
some operations are REQUIRED for IPP objects to support, and the others are OPTIONAL (see section 5.2.2) 💜. so before using an OPTIONAL operation, a client SHOULD first use the REQUIRED Get-Printer-Attributes operation to query the Printer's "operations-supported" attribute and figure out which OPTIONAL Printer and Job operations are actually supported 🔥. the client SHOULD NOT use an OPTIONAL operation that isn't supported 🙈. when an IPP object gets a request for an operation it doesn't support, it returns the 'server-error-operation-not-supported' status code (see section 13.1.5.2) 😭. an IPP object is non-conformant if it does not support a REQUIRED operation 💅.
3.1.4 Character Set and Natural Language Operation Attributes 🧚
some Job and Printer attributes have text string and name values meant for humans to read, not machines (see the 'text' and 'name' attribute syntax descriptions in section 4.1) 🌸. the next sections describe two special Operation Attributes called "attributes-charset" and "attributes-natural-language" 💖. these are always part of the Operation Attributes group 👑. for most attribute groups, the order of the attributes doesn't matter 🦋. but for these two attributes in the Operation Attributes group, the order is critical 😭. the "attributes-charset" attribute MUST be the first attribute in the group, and the "attributes-natural-language" attribute MUST be the second 🔥. in other words, these attributes MUST be supplied in every IPP request and response, they MUST come first in the group, and they MUST come in that specified order 🫶. for job creation operations, the IPP Printer implementation saves these two attributes with the new Job object as Job Description attributes 🌈. to keep things brief, these operation attribute descriptions aren't repeated with every operation request and response; they point back to this section instead 🍓.
3.1.4.1 Request Operation Attributes 🎀
okay bestie, so every single IPP/1.1 operation request needs some REQUIRED operation attributes 💅. The client MUST supply them, and the Printer object MUST support them. no cap, these are not optional. 🔥
"attributes-charset"(charset): This operation attribute tells everyone which charset (coded character set and encoding method) is used by any 'text' and 'name' attributes the client is sending in this request ✨ It also tells the client which charset the Printer object MUST use (if supported) for all 'text' and 'name' attributes and status messages the Printer object sends back in the response. See Sections 4.1.1 and 4.1.2 for the definitions of the 'text' and 'name' attribute syntaxes.
All clients and IPP objects MUST support the 'utf-8' charset [RFC2279] and MAY support additional charsets, as long as they are registered with IANA [IANA-CS]. If the Printer object doesn't support the charset the client supplied, the Printer object MUST reject the request 🙅♀️ set the "attributes-charset" to 'utf-8' in the response, and return the client-error-charset-not-supported status code and any 'text' or 'name' attributes using the 'utf-8' charset. The Printer need not return any attributes in the Unsupported Attributes Group (See sections 3.1.7 and 3.2.1.2). The Printer object MUST indicate the charset(s) it supports as the values of the "charset-supported" Printer attribute (see Section 4.4.18), so clients can query which charset(s) are supported. 🌸
Note to client implementers: since IPP objects are only required to support 'utf-8', a client may want to supply 'utf-8' in "attributes-charset" to maximize interoperability with multiple IPP object implementations 🫶 even if the client is only passing and able to present a simpler charset, like US-ASCII [ASCII] or ISO-8859-1 [ISO8859-1]. Then the client has to filter out (or charset convert) the characters in the response that it can't present to its user. On the other hand, if both the client and the IPP objects support a charset in common besides utf-8, the client may want to use that charset to avoid charset conversion or data loss. 💖
See Section 4.1.7 for the 'charset' attribute syntax description, including the syntax and semantic interpretation of this attribute's values and example values.
"attributes-natural-language"(naturalLanguage): This operation attribute identifies the natural language used by any 'text' and 'name' attributes the client is supplying in this request. It also identifies the natural language that the Printer object SHOULD use for all 'text' and 'name' attributes and status messages in the response to this request. See Section 4.1.8 for the naturalLanguage syntax description, including the syntax and semantic interpretation of this attribute's values and example values. 🌈
There are no natural languages that are REQUIRED for the Printer object to support. 🧚 However, the Printer object's "generated-natural-language-supported" attribute identifies the natural languages the Printer object and any contained Job objects support for all text strings the IPP object generates. A client MAY query this attribute to find out which natural language(s) are supported for generated messages.
For the attributes where the Printer object generates text, meaning "job-state-message", "printer-state-message", and status messages (see Section 3.1.6), the Printer object MUST be able to generate these text strings in any of its supported natural languages. If the client requests a natural language that isn't supported, the Printer object MUST return these generated messages in the Printer's configured natural language, as specified by the Printer's "natural-language-configured" attribute (see Section 4.4.19). 🍓
For other 'text' and 'name' attributes supplied by the client, the authentication system, the operator, the system administrator, or the manufacturer (that is, "job-originating-user-name", "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make-and-model" (text)), the Printer object is only required to support the configured natural language of the Printer, identified by its "natural-language-configured" attribute. Support for extra natural languages for these attributes is permitted though. ✨
For any 'text' or 'name' attribute in the request that is in a different natural language than the value supplied in "attributes-natural-language", the client MUST use the Natural Language Override mechanism (see Sections 4.1.1.2 and 4.1.2.2) for each such attribute value supplied. The client MAY use the Natural Language Override mechanism redundantly, meaning even when the value is in the same natural language as the value in "attributes-natural-language" of the request. 💅
The IPP object MUST accept any natural language and any Natural Language Override, whether or not the IPP object supports that natural language (and independent of the value of the "ipp-attribute-fidelity" Operation attribute). In other words, the IPP object accepts all client-supplied values no matter what's in the Printer object's "generated-natural-language-supported" attribute, because that attribute only applies to generated messages, not client-supplied ones. The IPP object MUST remember that natural language for all client-supplied attributes, and when returning those attributes in response to a query, the IPP object MUST indicate that natural language. 🧠
Each value whose attribute syntax type is 'text' or 'name' (see Sections 4.1.1 and 4.1.2) has an Associated Natural-Language. This document doesn't specify how that association is stored in a Printer or Job object. When such a value is encoded in a request or response, the natural language is either implicit or explicit:
- In the implicit case, the value contains only the text/name value, and the language is specified by the
"attributes-natural-language"operation attribute in the request or response (see Sections 4.1.1.1 textWithoutLanguage and 4.1.2.1 nameWithoutLanguage). - In the explicit case (also known as the Natural Language Override case), the value contains both the language and the text/name value (see Sections 4.1.1.2 textWithLanguage and 4.1.2.2 nameWithLanguage).
For example, the "job-name" attribute MAY be supplied by the client in a create request. The text value for this attribute will be in the natural language identified by the "attribute-natural-language" attribute, or, if different, the one identified by the Natural Language Override mechanism. If supplied, the IPP object uses the value of "job-name" to populate the Job object's "job-name" attribute. Whenever any client queries the Job object's "job-name", the IPP object returns the attribute as stored, and uses the Natural Language Override mechanism to specify the natural language if it's different from the one reported in "attributes-natural-language" of the response. The IPP object MAY use the Natural Language Override mechanism redundantly, meaning even when the value is in the same natural language as the value in "attributes-natural-language" of the response. 🎀
An IPP object MUST NOT reject a request based on a supplied natural language in an "attributes-natural-language" Operation attribute, or in any attribute that uses the Natural Language Override. 🙌
Clients SHOULD NOT supply 'text' or 'name' attributes that use an illegal combination of natural language and charset. 🙈 For example, suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and 'iso-8859-7'. Suppose also that it supports natural languages 'en' (English), 'fr' (French), and 'el' (Greek). Although the Printer object supports the charset 'iso-8859-1' and natural language 'el', it probably doesn't support the combination of Greek text strings using the 'iso-8859-1' charset. The Printer object handles this apparent incompatibility differently depending on the context:
- In a create request: If the client supplies a text or name attribute (for example, the
"job-name"operation attribute) that uses an apparently incompatible combination, it's a client choice that doesn't affect the Printer object or its correct operation. Therefore, the Printer object simply accepts the client-supplied value, stores it with the Job object, and responds back with the same combination whenever the client (or any client) queries for that attribute. 💜 - In a query-type operation, like Get-Printer-Attributes: If the client requests an apparently incompatible combination, the Printer object responds (as described in section 3.1.4.2) using the Printer's configured natural language rather than the natural language requested by the client. 🦋
In either case, the Printer object does not reject the request because of the apparent incompatibility. The potential incompatible combination of charset and natural language can occur either at the global operation level or at the Natural Language Override attribute-by-attribute level. Plus, since the response always includes explicit charset and natural language information, there is never any question or ambiguity in how the client interprets the response. that's literally so clean 🌈👑
3.1.4.2 Response Operation Attributes ✨
Okay bestie, every single IPP/1.1 response has to carry these two. The Printer object MUST supply them and the client MUST support them, so they're REQUIRED. No cap 💅
attributes-charset (charset): This one tells the client which charset was used for any 'text' and 'name' attributes the Printer object sends back 🎀. The value MUST be the same as the attributes-charset the client sent in the request. If that's not possible because the requested charset isn't supported, the request would've been rejected already. See attributes-charset in Section 3.1.4.1 above for the full details.
If the Printer object supports more than just the 'utf-8' charset, it MUST be able to code convert between each of the supported charsets on a highest fidelity possible basis, so it can return the 'text' and 'name' attributes in the charset the client asked for 🌈. Some information loss MAY happen during conversion, depending on which charsets are involved. For example, the Printer object may turn a UTF-8 'a' into a US-ASCII 'a' with zero loss ✨. It could turn an ISO Latin 1 CAPITAL LETTER A WITH ACUTE ACCENT into US-ASCII 'A' and lose the accent 😭. It could also turn a UTF-8 Japanese Kanji character into an ISO Latin 1 error character indication like '?', a decimal code equivalent, or nothing at all, depending on the implementation 🙈.
Whether an implementation that supports more than one charset stores the data in the client's charset or code converts to one of the other supported charsets is up to the implementation 🍓. The strategy should try to minimize information loss during code conversion. On each response, that kind of implementation converts from its internal charset to the one requested 💜.
attributes-natural-language (naturalLanguage): This one tells the client which natural language is used by any 'text' and 'name' attributes the IPP object returns 🌸. Unlike attributes-charset, the IPP object NEED NOT send back the same value the client supplied. The IPP object MAY return the natural language of the Job object, or the Printer's configured natural language from the Printer object's natural-language-configured attribute, instead of the one the client sent 🦋. Any 'text' or 'name' attribute or status message in the response that's in a different natural language than the value returned in attributes-natural-language MUST use the Natural Language Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on each attribute value returned 🔥. The IPP object MAY also use the Natural Language Override mechanism redundantly, even when the value is in the same natural language as attributes-natural-language in the response 🧚.
3.1.5 Operation Targets 🎯
Every IPP operation is aimed at an IPP object. For Printer operations, the operation is always directed at a Printer object using one of its URIs, meaning one of the values in the Printer object's printer-uri-supported attribute 🖨️. Even if the Printer object has more than one URI, the client only supplies one of them as the target. The client picks the target by putting the right URI in the printer-uri (uri) operation attribute ✨.
For Job operations, the operation is directed at either:
- The Job object itself, using the Job object's URI. In this case, the client identifies the target by putting the correct URI in the
job-uri (uri)operation attribute 💖. - The Printer object that created the Job object, using both the Printer object's URI and the Job object's Job ID 🌈. Since that Printer object generated the Job ID, it MUST be able to correctly match the client-supplied Job ID to the correct Job object 🫶. The client supplies the Printer object's URI in
printer-uri (uri)and the Job object's Job ID injob-id (integer(1:MAX))👑.
If the operation is aimed at the Job object directly using its URI, the client MUST NOT include the redundant job-id operation attribute 🙅♀️.
The operation target attributes are REQUIRED operation attributes that MUST be included in every operation request 💅. Like the charset and natural language attributes (see section 3.1.4), they're specially ordered. In every case they come right after attributes-charset and attributes-natural-language in the operation attribute group. The exact ordering rules are:
- If there's only one operation target attribute (either only
printer-urior onlyjob-uri), that attribute MUST be the third attribute in the operation attributes group 🎀. - If Job operations use two operation target attributes (
printer-uriandjob-id), thenprinter-uriMUST be the third attribute andjob-idMUST be the fourth attribute 🦋.
In every case, the target URIs inside the body of IPP operation requests and responses must be in absolute format, not relative format. A relative URL identifies a resource within the scope of the HTTP server, but it doesn't include the scheme, host or port 🌸.
These rules apply to port numbers in URIs that identify IPP objects 🔌:
- If the URI scheme allows the port number to be explicitly included in the URI string, and a port number is specified in the URI, then the client MUST use that port number to contact the IPP object 💜.
- If the URI scheme allows the port number to be explicitly included in the URI string, and no port number is specified in the URI, then the client MUST use the default port number implied by that URI scheme to contact the IPP object 🍓.
- If the URI scheme does not allow an explicit port number in the URI, then the client MUST use the default port number implied by that URI to contact the IPP object 🧚.
Note: The IPP "Encoding and Transport document [RFC2910] shows a mapping of IPP onto HTTP/1.1 [RFC2616] and defines a new default port number for using IPP over HTTP/1.1 ✨.
3.1.6 Operation Response Status Codes and Status Messages 🚦
Every operation response includes a REQUIRED "status-code" parameter, an OPTIONAL "status-message" operation attribute, and an OPTIONAL "detailed-status-message" operation attribute 💖. The Print-URI and Send-URI responses MAY include an OPTIONAL "document-access-error" operation attribute 🌈.
3.1.6.1 "status-code" (type2 enum) 🔢
The REQUIRED "status-code" parameter tells you how the request was processed 🫶.
The status code is meant for automata, not humans 🤖. A client implementation of IPP SHOULD convert status code values into any localized message that makes sense to the end user 💅.
The "status-code" value is a numeric value with semantic meaning ✨. Its syntax is similar to a "type2 enum" (see section 4.1 on "Attribute Syntaxes"), except values can only range from 0x0000 to 0x7FFF 👑. Section 13 describes the status codes, assigns their numeric values, and suggests a matching status message for each one, for clients whose user's natural language is English 🎀.
If the Printer performs an operation with no errors and runs into no problems, it MUST return the status code 'successful-ok' in the response 🦋. See section 13.
If the client supplies unsupported values for any of the following parameters or operation attributes, the Printer object MUST reject the operation 🙅♀️. It NEED NOT return the unsupported attribute value in the Unsupported Attributes group, but it MUST return the indicated status code 🧚:
Parameter/Attribute Status code
version-number server-error-version-not-supported
operation-id server-error-operation-not-supported
attributes-charset client-error-charset-not-supported
compression client-error-compression-not-supported
document-format client-error-document-format-not-supported
document-uri client-error-uri-scheme-not-supported,
client-error-document-access-errorIf the client supplies unsupported values for other attributes, or unsupported attributes, the Printer returns the status code defined in section 3.1.7 on Unsupported Attributes 🍓.
3.1.6.2 "status-message" (text(255)) 💬
The OPTIONAL "status-message" operation attribute gives a short text description of how the operation went 🌸. Its syntax is "text(255)", so the maximum length is 255 octets (see section 4.1.1) 📏. The status message is for the human end user 🙋♀️. If a response includes a "status-message" attribute, an IPP client NEED NOT examine or display the messages, but it SHOULD do so in some implementation-specific manner ✨. A later version of a Printer object can use "status-message" to add supplemental information for the human user, to go along with a status code an earlier version of a client might not understand 🦋.
If the Printer object supports the "status-message" operation attribute, it MUST be able to generate this message in any of the natural languages listed in the Printer object's generated-natural-language-supported attribute (see the attributes-natural-language operation attribute in section 3.1.4.1 🌈. Section 13 suggests the text for the status message the Printer returns in English 💜.
As described in section 3.1.4.1 for any returned 'text' attribute, if there's a choice for generating this message, the Printer object uses the natural language in the client request's attributes-natural-language value if it's supported 🫶. Otherwise, it uses the value in the Printer object's own natural-language-configured attribute 👑.
If the Printer object supports the "status-message" operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a status message for these error status codes (see section 13) 🎀: 'client-error-bad-request', 'client-error-charset-not-supported', 'server-error-internal-error', 'server-error-operation-not-supported', and 'server-error-version-not-supported' 🔥. In that case, it MUST set the value of the attributes-charset operation attribute to 'utf-8' in the error response 💖.
3.1.6.3 "detailed-status-message" (text(MAX))
okay so the OPTIONAL "detailed-status-message" operation attribute is basically the deep technical tea 🔍 about what happened. It's the implementation-specific nerdy stuff, and its syntax is text(MAX), so the max length is 1023 octets (see section 4.1.1) 📏 If the Printer object supports this attribute, the Printer NEED NOT localize the message, since it's meant for the system admin or other experienced technical people 🧑💻 Translating it could literally scramble the technical meaning 💀 So bestie, Clients MUST NOT attempt to parse the value of this attribute 🙅♀️ If you want the errors a program can actually process, go check the "document-access-error" operation attribute (section 3.1.6.4) 🦋
3.1.6.4 "document-access-error" (text(MAX))
This OPTIONAL operation attribute spills the tea on any document access errors the Printer ran into before it sent back a response to the Print-URI (section 3.2.2) or Send-URI (section 3.3.1) operation 📦 For errors in the protocol named by the URI scheme in the "document-uri" operation attribute, like 'http:' or 'ftp:', the error code goes in parentheses, followed by the URI. Here's the example:
(404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdfMost Internet protocols use decimal error codes (unlike IPP), so the ASCII error code representation is in decimal 🔢✨
3.1.7 Unsupported Attributes
The Unsupported Attributes group is the list of attributes the operation can't support 🙈 It's mainly for the job creation operations, but literally any operation can return it 💅
A Printer object MUST include an Unsupported Attributes group in a response if the status code is one of these: 'successful-ok-ignored-or-substituted-attributes', 'successful-ok-conflicting-attributes', 'client-error-attributes-or-values-not-supported' or 'client-error-conflicting-attributes'.
If the status code is one of those four, the group MUST contain all of those attributes and only those attributes that are:
- a. an Operation or Job Template attribute supplied in the request, and
- b. unsupported by the printer. See below for details on the three categories "unsupported" attributes.
If the status code is one of the ones in the table in section 3.1.6.1, the Unsupported Attributes group NEED NOT contain the unsupported parameter or attribute that the table points to 🌸
If the Printer object isn't returning any Unsupported Attributes, it SHOULD omit Group 2 instead of sending an empty group. But a client MUST be able to accept an empty group anyway 🫶
Okay, so unsupported attributes come in three flavours 🌈
- The Printer object doesn't support the supplied attribute (no matter what the attribute syntax or value).
- The Printer object does support the attribute, but doesn't support some or all of the particular attribute syntaxes or values the client sent (i.e., the Printer object doesn't have those attribute syntaxes or values in its corresponding "xxx-supported" attribute).
- The Printer object does support the attributes and values supplied, but the particular values clash with one another, because they break a constraint, like not being able to staple transparencies 🙃
For an unsupported attribute name, the Printer object returns the client-supplied attribute with a substituted value of 'unsupported'. That value's syntax type is "out-of-band", and its encoding follows the special rules for "out-of-band" values in the "Encoding and Transport" document [RFC2910]. The value means there's no support for the attribute itself (see the beginning of section 4.1) 🚫
For a supported attribute with one or more unsupported syntaxes or values, the Printer object just returns the client-supplied attribute with those unsupported syntaxes or values exactly as the client sent them. This says the attribute is supported, but that particular syntax or value isn't ✨ If the client sends a multi-valued attribute and the Printer supports the attribute but only a subset of the supplied syntaxes or values, the Printer object MUST return only those attribute syntaxes or values that are unsupported 🎀
When two (or more) supported attribute values conflict with one another (each one is supported on its own, but they clash when requested together in the same job), the Printer object MUST return all the values it ignores or substitutes to resolve the conflict, but not any of the values it's still using 👑 How exactly to resolve the conflict is implementation dependent. See sections 3.2.1.2 and 15. See The Implementer's Guide [IPP-IIG] for an example 📖
3.1.8 Versions
Every operation request and response carries a "version-number" parameter 💜 Each value is in the form "X.Y", where X is the major version number and Y is the minor version number. Including a version number in the client request lets the client say which version of IPP it's interested in using, i.e., the version whose conformance requirements the client may be depending on the Printer to meet 🧚
If the IPP object doesn't support the major version number the client supplied (the major version field of the "version-number" parameter doesn't match any of the values in the Printer's "ipp-versions-supported", see section 4.4.14), the object MUST respond with a status code of 'server-error-version-not-supported', along with the closest version number that is supported (see section 13.1.5.4). If the major version number is supported but the minor one isn't, the IPP object SHOULD accept and attempt to perform the request (or reject the request if the operation isn't supported). Otherwise it rejects the request and returns the 'server-error-version-not-supported' status code. In all cases, the IPP object MUST return the "version-number" it supports that is closest to the version number the client sent 🔁
There's no version negotiation per se 🙅♀️ However, if a client gets a 'server-error-version-not-supported' status code from an IPP object, it SHOULD try again with a different version number. A client MAY also figure out the supported versions either from a directory that conforms to Appendix E (see section 16) or by querying the Printer object's "ipp-versions-supported" attribute (see section 4.4.14) 🗂️
An IPP object implementation MUST support version '1.1', i.e., meet the conformance requirements for IPP/1.1 as specified in this document and [RFC2910]. It is recommended that IPP object implementations accept any request with the major version '1' (or reject the request if the operation isn't supported) 🌟
There's only one notion of "version number" that covers both IPP Model and IPP Protocol changes. So the version number MUST change when introducing a new version of the Model and Semantics document (this document) or a new version of the "Encoding and Transport" document [RFC2910] 💖
Changes to the major version number indicate structural or syntactic changes that make it impossible for older IPP clients and Printer objects to correctly parse and process the new or changed attributes, operations and responses. If the major version number changes, the minor version number is set to zero. For example, adding the REQUIRED "ipp-attribute-fidelity" attribute to version '1.1' (if it hadn't been part of version '1.0') would have required a major version change, since an IPP/1.0 Printer wouldn't process a request with the correct semantics containing an attribute it didn't know about 😭 Items that might affect changing the major version number include any changes to the Model and Semantics document (this document) or the "Encoding and Transport" document [RFC2910] itself, such as:
- reordering of ordered attributes or attribute sets
- changes to the syntax of existing attributes
- adding REQUIRED (for an IPP object to support) operation attribute groups
- adding values to existing REQUIRED operation attributes
- adding REQUIRED operations
Changes to the minor version number indicate the addition of new features, attributes and attribute values that may not be understood by all IPP objects, but which can be ignored if not understood 🦋 Items that might affect changing the minor version number include any changes to the model objects and attributes but not the encoding and transport rules [RFC2910] (except adding attribute syntaxes). Examples are:
- grouping all extensions not included in a previous version into a new version
- adding new attribute values
- adding new object attributes
- adding OPTIONAL (for an IPP object to support) operation attributes (i.e., those attributes that an IPP object can ignore without confusing clients)
- adding OPTIONAL (for an IPP object to support) operation attribute groups (i.e., those attributes that an IPP object can ignore without confusing clients)
- adding new attribute syntaxes
- adding OPTIONAL operations
- changing Job Description attributes or Printer Description attributes from OPTIONAL to REQUIRED or vice versa
- adding OPTIONAL attribute syntaxes to an existing attribute
The encoding of the "version-number" MUST NOT change over any version number (either major or minor). This rule guarantees that all future versions will be backwards compatible with all previous versions (at least for checking the "version-number") 🔒 Also, any protocol elements (attributes, error codes, tags, etc.) that aren't carried forward from one version to the next are deprecated, so they can never be reused with new semantics 🪦
Implementations that support a certain version NEED NOT support ALL previous versions 🧩 As each new version is defined (through the release of a new IPP specification document), that version will specify which previous versions MUST and which versions SHOULD be supported in compliant implementations ✨
3.1.9 Job Creation Operations 🎀
okay bestie, so to "submit a print job" and make a brand new Job object 💖, a client sends a create request. A create request is any one of these three operation requests:
- The Print-Job Request: A client with a print job that has only a single document uses the Print-Job operation ✨. It lets the client "push" the document data to the Printer object by putting the data right inside the request.
- The Print-URI Request: A client with a single-document job uses the Print-URI operation 🦋. Here the Printer object "pulls" the document data instead of the client "pushing" it. The request carries only a URI reference to the document data, not the data itself.
- The Create-Job Request: A client with a multi-document job uses the Create-Job operation 👑. It's followed by one or more Send-Document and/or Send-URI operations, and each one adds another document to the new Job object. Send-Document includes the document data, so the client pushes it to the printer. Send-URI includes only a URI reference, so the Printer pulls the data from that location. The last Send-Document or Send-URI request for a given Job object includes a "last-document" operation attribute set to
'true', which tells the printer that this is the final one.
Throughout this model document, "create request" is the umbrella term for any of these three operation requests 🌸.
A Create-Job operation followed by only one Send-Document operation is semantically equivalent to a Print-Job operation 🧚. Even so, for performance reasons the client SHOULD use the Print-Job operation for all single-document jobs. Also, Print-Job is a REQUIRED operation (all implementations MUST support it), whereas Create-Job is an OPTIONAL operation, so some implementations might not support it 💀.
Job submission time is the moment a client issues a create request. Every Job object starts in the 'pending', 'pending-held', or 'processing' state (see section 4.3.7). When the Printer object starts processing the print job, the Job object's state moves to 'processing', and that's called job processing time 🍓. Some validation checks have to happen at job submission time, and others have to happen at job processing time.
At job submission time, and whenever a Validate-Job operation is received, the Printer MUST do the following:
- Process the client supplied attributes and either accept or reject the request
- Validate the syntax of and support for the scheme of any client supplied URI
At job submission time the Printer object MUST validate whether the supplied attributes, attribute syntaxes, and values are supported, by matching them against the Printer object's corresponding "xxx-supported" attributes. See section 3.1.7 for details. [IPP-IIG] presents suggested steps for an IPP object to either accept or reject any request, plus extra steps for processing create requests 🫶.
At job submission time the Printer object need not perform the validation checks that are reserved for job processing time, such as:
- Validating the document data
- Validating the actual contents of any client supplied URI (resolve the reference and follow the link to the document data)
Honestly, those job processing time checks are basically useless at submission time 😭. They require actually parsing and interpreting the document data, they aren't guaranteed to be 100% accurate, and they MUST be done, yet again, at job processing time. For a URI, checking that it's available at submission time doesn't guarantee it'll still be available at processing time either. At processing time the Printer object might also discover any of these conditions, which weren't detectable at submission time:
- runtime errors in the document data,
- nested document data that is in an unsupported format,
- the URI reference is no longer valid (i.e., the server hosting the document might be down), or
- any other job processing error
At job submission time, a Printer object, especially a non-spooling Printer, MAY accept jobs that it does not have enough space for ✨. In that situation, a Printer object MAY stop reading data from a client for an indefinite period of time. A client MUST be prepared for a write operation to block for an indefinite period of time (see section 5.1 on client conformance) 🙈.
When a Printer object has too little space to start a new job, it MAY reject a new create request. In that case, a Printer object MUST return a response (in reply to the rejected request) with a status-code of server-error-busy (see section 14.1.5.8), and it MAY close the connection before receiving all bytes of the operation. A Printer SHOULD signal that it's temporarily unable to accept jobs by setting the spool-space-full value in its "printer-state-reasons" attribute, then removing that value once it can accept another job (see section 4.4.12) 🌈.
When a client gets a server-error-busy status-code in an operation response, a client MUST be prepared for the Printer object to close the connection before the client has sent all of the data (especially for the Print-Job operation). A client MUST also be prepared to keep submitting a create request until the IPP Printer object accepts it. Keep retrying, bestie 💪.
At job processing time, the Printer has already replied to the create request with a successful status code. So if it detects an error now, it can't tell the end user with an operation status code 😬. Depending on the error, the Printer can instead set the job object's "job-state", "job-state-reasons", or "job-state-message" attributes to the right value(s), so later queries can report the correct job status 💅.
Note: Asynchronous notification of events is outside the scope of this IPP/1.1 document.
3.2 Printer Operations 🌷
All Printer operations are directed at Printer objects. A client MUST always supply the "printer-uri" operation attribute to identify the correct target of the operation 🎯.
3.2.1 Print-Job Operation 🖨️
This REQUIRED operation lets a client submit a print job with only one document and supply the document data itself, rather than just a reference to it 💖. See Section 15 for the suggested steps for processing create operations and their Operation and Job Template attributes.
3.2.1.1 Print-Job Request
The following groups of attributes are supplied as part of the Print-Job Request:
- Group 1: Operation Attributes
- Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes, as described in section 3.1.4.1. The Printer object MUST copy these values to the corresponding Job Description attributes described in sections 4.3.19 and 4.3.20 🧁.
- Target: The "printer-uri" (uri) operation attribute, which is the target for this operation as described in section 3.1.5 🎀.
- Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client, as described in section 8.3 🫧.
- "job-name" (name(MAX)): The client optionally supplies this attribute. The Printer object MUST support it. It holds the client supplied Job name, and if the client supplies it, its value is used for the "job-name" attribute of the newly created Job object ✨. The client MAY automatically include anything that helps the end user tell their jobs apart, like the name of the application program along with details from the document, such as the document name, document subject, or source file name. If the client doesn't supply this attribute, the Printer generates a name for the "job-name" attribute of the new Job object (see Section 4.3.5).
- "ipp-attribute-fidelity" (boolean): The client optionally supplies this attribute. The Printer object MUST support it. The value
'true'means total fidelity to the client supplied Job Template attributes and values is required; otherwise the Printer object MUST reject the Print-Job request 🔥. The value'false'means a reasonable attempt to print the Job object is acceptable, and the Printer object MUST accept the Print-Job request. If it isn't supplied, the Printer object assumes'false'. All Printer objects MUST support both types of job processing. See section 15 for a full description of "ipp-attribute-fidelity" and how it relates to other attributes, especially the Printer object's "pdl-override-supported" attribute 🦋. - "document-name" (name(MAX)): The client optionally supplies this attribute. The Printer object MUST support it. It holds the client supplied document name 📄. The document name MAY be different from the Job name. Usually the client software fills it in automatically for the end user, using a file name or an application generated name. If it's supplied, its value can be used in whatever way each implementation defines. Examples include printing it along with the Job (job start sheet, page adornments, etc.), using it in accounting or resource tracking tools, or even storing it along with the document as a document level attribute. IPP/1.1 does not support the concept of document level attributes 🙅♀️.
- "compression" (type3 keyword): The client optionally supplies this attribute. The Printer object MUST support this attribute and the "compression-supported" attribute (see section 4.4.32) 🗜️. The client supplied "compression" operation attribute identifies the compression algorithm used on the document data. The following cases exist:
- a) If the client omits this attribute, the Printer object MUST assume the data is not compressed (i.e., the Printer follows the rules below as if the client supplied the "compression" attribute with a value of
'none'). - b) If the client supplies this attribute but the value is not supported by the Printer object (i.e., the value is not one of the values of the Printer object's "compression-supported" attribute), the Printer object MUST reject the request and return the
'client-error-compression-not-supported'status code. See section 3.1.7 for returning unsupported attributes and values 🚫.
- a) If the client omits this attribute, the Printer object MUST assume the data is not compressed (i.e., the Printer follows the rules below as if the client supplied the "compression" attribute with a value of
- c) okay so if the client supplies the attribute and the Printer object supports that attribute value, the Printer object uses the matching decompression algorithm on the document data 🗜️✨
- d) if the decompression algorithm fails before the Printer returns an operation response, the Printer object MUST reject the request and return the
client-error-compression-errorstatus code 💀 - e) if the decompression algorithm fails after the Printer returns an operation response, the Printer object MUST abort the job and add the
compression-errorvalue to the job'sjob-state-reasonsattribute 😭 - f) if the decompression algorithm succeeds, the document data MUST then have the format specified by the job's
document-formatattribute, if one was supplied (see thedocument-formatoperation attribute definition below) 💅
document-format (mimeMediaType):
The client can optionally supply this one 🎀 and the Printer object MUST support it. Its value tells the Printer what format the document data is in. Here's how the different cases play out:
- a) if the client doesn't supply this attribute, the Printer object assumes the document data is in the format defined by the Printer object's
document-format-defaultattribute. (i.e. the Printer follows the rules below as if the client supplied thedocument-formatattribute with a value equal to the printer's default value) 🧚 - b) if the client supplies this attribute but the value isn't supported by the Printer object, meaning it isn't one of the values of the Printer object's
document-format-supportedattribute, the Printer object MUST reject the request and return theclient-error-document-format-not-supportedstatus code 🙈 - c) if the client supplies this attribute and its value is
application/octet-stream(i.e. to be auto-sensed, see Section 4.1.9.1), and the format isn't one of the document-formats that the Printer can auto-sense, and this check happens before the Printer returns an operation response, then the Printer MUST reject the request and return theclient-error-document-format-not-supportedstatus code 🔥 - d) if the client supplies this attribute and the value is supported by the Printer object, the Printer is capable of interpreting the document data 🌸
- e) if interpreting the document data fails before the Printer returns an operation response, the Printer object MUST reject the request and return the
client-error-document-format-errorstatus code 😵 - f) if interpreting the document data fails after the Printer returns an operation response, the Printer object MUST abort the job and add the
document-format-errorvalue to the job'sjob-state-reasonsattribute 💔
document-natural-language (naturalLanguage):
The client can optionally supply this attribute, and the Printer object can optionally support it. It says what natural language the document is in, but only for document-formats that need that info to be imaged unambiguously. There are no particular values the Printer object is required to support 🌍
job-k-octets (integer(0:MAX)):
The client can optionally supply this attribute, and the Printer object can optionally support it along with the job-k-octets-supported attribute (see section 4.4.33). The client-supplied job-k-octets operation attribute tells the total size, in K octets, of the document(s) being submitted (see section 4.3.17.1 for the full semantics) 📦. If the client supplies it and the Printer object supports it, the value fills in the Job object's job-k-octets Job Description attribute 🫶
For this attribute and the next two (job-impressions and job-media-sheets), a few rules apply. If the client supplies the attribute but the Printer object doesn't support it, the Printer object ignores the client's value. If the client supplies the attribute, the Printer supports it, and the value is within the range of the Printer object's xxx-supported attribute, the Printer object MUST use the value to fill in the Job object's xxx attribute ✅. If the client supplies the attribute and the Printer supports it, but the value is outside the range of the Printer object's xxx-supported attribute, the Printer object MUST copy the attribute and its value to the Unsupported Attributes response group, reject the request, and return the client-error-attributes-or-values-not-supported status code 🚫. If the client doesn't supply the attribute, the Printer object MAY choose to fill in the corresponding Job object attribute, as long as it supports the attribute and can calculate or figure out the correct value 🧠
job-impressions (integer(0:MAX)):
The client can optionally supply this attribute, and the Printer object can optionally support it along with the job-impressions-supported attribute (see section 4.4.34). The client-supplied job-impressions operation attribute tells the total size, in number of impressions, of the document(s) being submitted (see section 4.3.17.2 for the full semantics) 🖨️
See the last paragraph under job-k-octets 🦋
job-media-sheets (integer(0:MAX)):
The client can optionally supply this attribute, and the Printer object can optionally support it along with the job-media-sheets-supported attribute (see section 4.4.35). The client-supplied job-media-sheets operation attribute tells the total number of media sheets to be produced for this job (see section 4.3.17.3 for the full semantics) 📄
See the last paragraph under job-k-octets 🦋
Group 2: Job Template Attributes 🎀
The client can optionally supply a set of Job Template attributes, as defined in section 4.2. If the client isn't supplying any Job Template attributes in the request, the client SHOULD omit Group 2 instead of sending an empty group 🙌 That said, a Printer object MUST be able to accept an empty group, so nobody's getting rejected over it 🥹
Group 3: Document Content 📜
The client MUST supply the document data to be processed. That's the one non-negotiable 💖
On top of the mandatory parameters every operation request needs, the simplest Print-Job Request is just the attributes-charset and attributes-natural-language operation attributes, the printer-uri target operation attribute, and the Document Content, and that's it, nothing else 🍓 In this super simple case, the Printer object:
- creates a new Job object (the Job object contains a single document) 🧁
- stores a generated Job name in the
job-nameattribute, in the natural language and charset that were requested (see Section 3.1.4.1) (if those are supported, otherwise it uses the Printer object's default natural language and charset) 🌈 - at job processing time, uses its corresponding default value attributes for the supported Job Template attributes that the client didn't supply, either as an IPP attribute or as embedded instructions in the document data ⭐
3.2.1.2 Print-Job Response 💌
okay bestie, so the Printer object MUST send back these groups of attributes as part of the Print-Job Response 🎀
Group 1: Operation Attributes 🧚
Status Message: on top of the REQUIRED status code that shows up in every response, the response can optionally include a "status-message" (text(255)) and/or a "detailed-status-message" (text(MAX)) operation attribute, as described in sections 13 and 3.1.6. 💅 Now the tea: if the client sends unsupported or conflicting Job Template attributes or values, the Printer object MUST reject or accept the Print-Job request depending on whether the client supplied a 'true' or 'false' value for the "ipp-attribute-fidelity" operation attribute. 🙈 For the full list of suggested steps for processing a create request, check the Implementer's Guide [IPP-IIG] 📚
Natural Language and Character Set: the "attributes-charset" and "attributes-natural-language" attributes, as described in section 3.1.4.2 🌈
Group 2: Unsupported Attributes 🦋
See section 3.1.7 for details on returning Unsupported Attributes ✨
The value of "ipp-attribute-fidelity" the client sends doesn't change which attributes the Printer object returns in this group 💀. It only decides whether the Print-Job operation gets accepted or rejected. If the job is accepted, the client can query it using the Get-Job-Attributes operation, asking for the unsupported attributes that came back in the create response. That's how it finds out which attributes were ignored (not stored on the Job object) and which were stored with other (substituted) values. 🔥
Group 3: Job Object Attributes 👑
"job-uri" (uri): the Printer object MUST return the Job object's URI by returning the contents of the REQUIRED "job-uri" Job object attribute. The client uses that URI when it directs operations at the Job object. The Printer object always uses its configured security policy when it creates the new URI. But if the Printer object supports more than one URI, it also looks at which URI the Print-Job Request came in on, so the new URI points at the correct access channel. Basically, if the Print-Job Request comes in over a secure channel, the Printer object MUST generate a Job URI that uses the secure channel as well 🔐
"job-id" (integer(1:MAX)): the Printer object MUST return the Job object's Job ID by returning the REQUIRED "job-id" attribute. The client pairs this "job-id" with the "printer-uri" from the Print-Job Request when it directs Job operations at the Printer object 🧚
"job-state" (type1 enum): the Printer object MUST return the REQUIRED "job-state" attribute. The value of this attribute (along with the next one, "job-state-reasons") comes from a "snapshot" of the new Job object, taken at some meaningful point in time (implementation defined) between when the Printer object receives the Print-Job Request and when it returns the response ⏰
"job-state-reasons" (1setOf type2 keyword): the Printer object MUST return the REQUIRED "job-state-reasons" attribute 🧾
"job-state-message" (text(MAX)): the Printer object optionally returns the Job object's OPTIONAL "job-state-message" attribute. If the Printer object supports this attribute, then it MUST be returned in the response. If it isn't returned, the client can assume the attribute isn't supported and won't show up in a later Job object query 🙅♀️
"number-of-intervening-jobs" (integer(0:MAX)): the Printer object optionally returns the Job object's OPTIONAL "number-of-intervening-jobs" attribute. If the Printer object supports this attribute, then it MUST be returned in the response. If it isn't returned, the client can assume the attribute isn't supported and won't show up in a later Job object query 🔢
Note: any printer state info that affects a job's state gets reflected in the"job-state"and"job-state-reasons"attributes, so returning just those is enough. You don't need any specific printer status attributes 💅
Note: in addition to the mandatory parameters required for every operation response, the simplest response is just the"attributes-charset"and"attributes-natural-language"operation attributes, plus the"job-uri","job-id", and"job-state"Job Object Attributes. In that simplest case, the status code issuccessful-ok, and there's no"status-message"or"detailed-status-message"operation attribute. Main character energy 👑✨
3.2.2 Print-URI Operation 🌸
This OPTIONAL operation is identical to the Print-Job operation (section 3.2.1), except that the client gives a URI reference to the document data using the "document-uri" (uri) operation attribute (in Group 1), instead of including the document data itself 🔗. Before returning the response, the Printer MUST validate that it supports the retrieval method (e.g., http, ftp, etc.) implied by the URI, and it MUST check for valid URI syntax. If the client-supplied URI scheme isn't supported, meaning the value isn't in the Printer object's "referenced-uri-scheme-supported" attribute, the Printer object MUST reject the request and return the client-error-uri-scheme-not-supported status code 🙅♀️
The IPP Printer MAY validate that the document is accessible, either as part of the operation or afterwards. If the Printer finds an accessibility problem before returning an operation response, it rejects the request and returns the client-error-document-access-error status code. The Printer MAY also return a specific document access error code using the "document-access-error" operation attribute (see section 3.1.6.4) 🧐
If the Printer finds this document accessibility problem after accepting the request and returning an operation response with one of the successful status codes, the Printer adds the document-access-error value to the job's "job-state-reasons" attribute. It MAY also fill in the job's "job-document-access-errors" Job Description attribute (see section 4.3.11). Check out The Implementer's Guide [IPP-IIG] for suggested extra checks 📚
If the Printer object supports this operation, it MUST support the "reference-uri-schemes-supported" Printer attribute (see section 4.4.27) 🌈
It's up to the IPP object to interpret the URI and then "pull" the document from the source the URI string references 🧲
3.2.3 Validate-Job Operation 🦋
This REQUIRED operation is similar to the Print-Job operation (section 3.2.1), except that the client supplies no document data and the Printer allocates no resources (i.e., it does NOT create a new Job object) 🙃. It's only used to check a printer object's capabilities against whatever attributes the client supplies in the Validate-Job request. With Validate-Job, a client can confirm that an identical Print-Job operation (the one with the document data) would be accepted. The Validate-Job operation also does the same security negotiation as the Print-Job operation (see section 8), so the client can check that its security requirements and the Printer object's can be met before it runs a Print-Job operation 🔐
The Validate-Job operation doesn't accept a "document-uri" attribute. That lets a client check that the same Print-URI operation will be accepted, since the client doesn't send the data with Print-URI. The client SHOULD just issue the Print-URI request 💖
The Printer object returns the same status codes, Operation Attributes (Group 1), and Unsupported Attributes (Group 2) as the Print-Job operation. However, no Job Object Attributes (Group 3) come back, since no Job object is created 🫶
3.2.4 Create-Job Operation 🧚
This OPTIONAL operation is similar to the Print-Job operation (section 3.2.1), except that in the Create-Job request, the client doesn't supply document data or any reference to document data. The client also doesn't supply any of the "document-name", "document-format", "compression", or "document-natural-language" operation attributes. This operation gets followed by one or more Send-Document or Send-URI operations. In each of those operation requests, the client optionally supplies the "document-name", "document-format", and "document-natural-language" attributes for each document in the multi-document Job object 📄
If a Printer object supports the Create-Job operation, it MUST also support the Send-Document operation, and it MAY support the Send-URI operation 🫶
If the Printer object supports this operation, it MUST support the "multiple-operation-time-out" Printer attribute (see section 4.4.31) ⏳
If the Printer object supports this operation, then it MUST support the "multiple-document-jobs-supported" Printer Description attribute (see section 4.4.16), and indicate whether or not it supports multiple-document jobs 📑
If the Printer object supports this operation and supports multiple documents in a job, then it MUST support the "multiple-document-handling" Job Template job attribute with at least one value (see section 4.2.4), along with the associated "multiple-document-handling-default" and "multiple-document-handling-supported" Job Template Printer attributes (see section 4.2) 🎀
After the Create-Job operation completes, the value of the "job-state" attribute is similar to the "job-state" after a Print-Job, even though no document data has arrived 🥹. A Printer MAY set the job-data-insufficient value of the job's "job-state-reason" attribute to show that processing can't begin until enough data arrives, and it can set the "job-state" to either pending or pending-held. A non-spooling printer that doesn't implement the pending job state may even set the "job-state" to processing, even though there isn't any data to process yet 🖨️. See sections 4.3.7 and 4.3.8 💅
3.2.5 Get-Printer-Attributes Operation ✨
okay bestie, this one is REQUIRED 💅 It lets a client ask a Printer object for the values of its attributes. The client names the Printer attributes and/or attribute group names it cares about, and the Printer sends back an attribute set with the right values filled in 🦋
For Printer objects, the attribute group names are:
'job-template': the subset of the Job Template attributes that apply to a Printer object (the last two columns of the table in Section 4.2) that the implementation supports for Printer objects. 🎀'printer-description': the subset of the attributes specified in Section 4.4 that the implementation supports for Printer objects. 🌸'all': the special group'all'that includes all attributes that the implementation supports for Printer objects. 👑
Since a client MAY request specific attributes or named groups, there can be some overlap 👀 For example, if a client requests 'printer-name' and 'all', it's actually asking for "printer-name" twice: once by naming it, and once because it's inside 'all'. In that case, the Printer object NEED NOT return each attribute only once in the response, even if it was requested more than once. The client SHOULD NOT request the same attribute in multiple ways. not it, bestie 🙈
It is NOT REQUIRED that a Printer object support every attribute in a group, since some attributes are OPTIONAL. ngl though, it IS REQUIRED that each Printer object support all of the group names 💜
3.2.5.1 Get-Printer-Attributes Request
The Get-Printer-Attributes Request has the following sets of attributes 🧚
Group 1: Operation Attributes
- Natural Language and Character Set: The
"attributes-charset"and"attributes-natural-language"attributes, as described in section 3.1.4.1. 🌈 - Target: The
"printer-uri"(uri) operation attribute, which is the target for this operation as described in section 3.1.5. 🎯 - Requesting User Name: The
"requesting-user-name"(name(MAX)) attribute SHOULD be supplied by the client, as described in section 8.3. 💁♀️ "requested-attributes"(1setOf keyword): The client OPTIONALLY supplies a set of attribute names and/or attribute group names whose values the requester is interested in. The Printer object MUST support this attribute. If the client leaves this attribute out, the Printer MUST respond as if it had been supplied with a value of'all'. the main character of this request is literally the Printer 💖"document-format"(mimeMediaType): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute, and it's super useful for figuring out which supported attribute values relate to the requested document format 📄 The Printer object MUST return the attributes and values it uses to validate a job on a create or Validate-Job operation where this document format is supplied. The Printer object SHOULD return only (1) those attributes that are supported for the specified format and (2) the attribute values that are supported for that format. So by naming the format, the client can get the Printer to filter out the attributes and values that don't work for that specific format. ✨ For example, a Printer object might have multiple interpreters for both'application/postscript'(PostScript) and'text/plain'(text) documents. For only one of those interpreters, though, the Printer might be able to support"number-up"with values of'1','2', and'4'. For the other interpreter, it might only support"number-up"with a value of'1'. So a client can use Get-Printer-Attributes to see the attributes and values that will be used to accept or reject a create job operation. 🫶
If the Printer object does not distinguish between different sets of supported values for each document format when validating jobs in the create and Validate-Job operations, it MUST NOT distinguish between document formats in the Get-Printer-Attributes operation. If the Printer object DOES distinguish between sets of supported values for each document format the client specifies, this specialization applies only to the following Printer object attributes:
- Printer attributes that are Job Template attributes (
"xxx-default","xxx-supported", and"xxx-ready"in the Table in Section 4.2), "pdl-override-supported","compression-supported","job-k-octets-supported","job-impressions-supported","job-media-sheets-supported","printer-driver-installer","color-supported", and"reference-uri-schemes-supported"
The values of all other Printer object attributes (including "document-format-supported") stay invariant with respect to the client-supplied document format. The exception is any new Printer description attribute registered according to section 6.2. 🔒
If the client leaves out this "document-format" operation attribute, the Printer object MUST respond as if it had been supplied with the value of the Printer object's "document-format-default" attribute. It is RECOMMENDED that the client always supply a value for "document-format", because the Printer object's "document-format-default" may be 'application/octet-stream'. In that case the returned attributes and values are for the union of the document formats the Printer can automatically sense 🌀 For more details, see the description of the 'mimeMediaType' attribute syntax in section 4.1.9.
If the client supplies a value for the "document-format" operation attribute that the Printer doesn't support (meaning it is not among the values of the Printer object's "document-format-supported" attribute), the Printer object MUST reject the operation and return the 'client-error-document-format-not-supported' status code. 🚫
3.2.5.2 Get-Printer-Attributes Response
The Printer object returns the following sets of attributes as part of the Get-Printer-Attributes Response 💌
Group 1: Operation Attributes
- Status Message: In addition to the REQUIRED status code that comes back in every response, the response OPTIONALLY includes a
"status-message"(text(255)) and/or a"detailed-status-message"(text(MAX)) operation attribute, as described in sections 13 and 3.1.6. 📝 - Natural Language and Character Set: The
"attributes-charset"and"attributes-natural-language"attributes, as described in section 3.1.4.2. 🌍
Group 2: Unsupported Attributes
See section 3.1.7 for details on returning Unsupported Attributes. 🙅♀️
The response NEED NOT contain the "requested-attributes" operation attribute with any supplied values (attribute keywords) that the client requested but the IPP object doesn't support. If the Printer object DOES return unsupported attributes referenced in the "requested-attributes" operation attribute, and that attribute included group names such as 'all', then the unsupported attributes MUST NOT include attributes that are described in the standard but not supported by the implementation. bestie, this is the "don't lie about what you support" rule 💀
Group 3: Printer Object Attributes
This is the set of requested attributes and their current values. The Printer object ignores (does not respond with) any requested attribute it doesn't support. The Printer object MAY respond with a subset of the supported attributes and values, depending on the security policy in force. 🔐 However, the Printer object MUST respond with the 'unknown' value for any supported attribute (including all REQUIRED attributes) whose value it doesn't know. Also, the Printer object MUST respond with the 'no-value' value for any supported attribute (including all REQUIRED attributes) that the system administrator hasn't configured a value for. See the description of the "out-of-band" values at the beginning of Section 4.1. 🫧
3.2.6 Get-Jobs Operation 🌸
This REQUIRED operation lets a client retrieve the list of Job objects that belong to the target Printer object. The client MAY also supply a list of Job attribute names and/or attribute group names. A group of Job object attributes will be returned for each Job object that comes back 🧾
This operation is similar to the Get-Job-Attributes operation, except that Get-Jobs returns attributes from possibly more than one object. So it's basically Get-Job-Attributes' bigger, more dramatic sibling 👯♀️✨
3.2.6.1 Get-Jobs Request ✨
okay so the client sends the Get-Jobs request to a Printer object 🖨️💖 here's the full lineup of attribute groups in the request:
Group 1: Operation Attributes 🎀
- Natural Language and Character Set: the
"attributes-charset"and"attributes-natural-language"attributes, as described in section 3.1.4.1 📚 - Target: the
"printer-uri"(uri) operation attribute, which is the target for this operation, as described in section 3.1.5 🎯 - Requesting User Name: the
"requesting-user-name"(name(MAX)) attribute SHOULD be supplied by the client, as described in section 8.3 🫶 - "limit" (
integer(1:MAX)): the client can optionally send this one, and the Printer object MUST support it 💅 it's an integer that caps how many jobs the client gets back from the Printer, even if"which-jobs"or"my-jobs"already narrowed things down 🔢 it's a "stateless limit", so if the client sends 'N', only the first 'N' jobs come back in the Get-Jobs Response 🙈 there's no way to ask for the next 'M' jobs after those first 'N' 😭 and if the client doesn't send it at all, the Printer object responds with all the applicable jobs ✨ - "requested-attributes" (
1setOf type2 keyword): the client can optionally send this, and the Printer object MUST support it 🧚 it's a set of Job attribute names and/or attribute group names the requester cares about, and that set comes back for each Job object returned 💜 the allowed attribute group names are the same ones defined in the Get-Job-Attributes operation in section 3.3.4 🍓 if the client leaves it out, the Printer MUST respond as if the client had supplied two values:'job-uri'and'job-id'🦋 - "which-jobs" (
type2 keyword): the client can optionally send this, and the Printer object MUST support it 👑 it says which Job objects MUST be returned by the Printer object. The values are:'completed': this includes any Job object whose state is'completed','canceled', or'aborted'.'not-completed': this includes any Job object whose state is'pending','processing','processing-stopped', or'pending-held'.
A Printer object MUST support both values. However, if the implementation doesn't keep jobs in the 'completed', 'canceled', and 'aborted' states, then it returns no jobs when the 'completed' value is supplied 🥺
If a client supplies some other value, the Printer object MUST copy the attribute and the unsupported value to the Unsupported Attributes response group, reject the request, and return the 'client-error-attributes-or-values-not-supported' status code. 🚫
If the client doesn't supply this attribute, the Printer object MUST respond as if the client had supplied the attribute with a value of 'not-completed' 🌸
- "my-jobs" (
boolean): the client can optionally send this, and the Printer object MUST support it 🙋♀️ it says whether jobs from all users, or just the jobs submitted by the requesting user of this request, MUST be considered as candidate jobs to be returned 💅 if the client doesn't supply it, the Printer object MUST respond as if the client had supplied'false', i.e., jobs from all users 🌈 how the requesting user gets authenticated and how the jobs get matched is covered in section 8 🔐
3.2.6.2 Get-Jobs Response 💌
so the Printer object returns all the Job objects up to the number set by the "limit" attribute that match the criteria the client sent in the request 🎯 it's totally possible to get zero jobs back, because the Printer might have no Job objects at all, or nothing that matches what the client asked for 🤷♀️ and if the client requests any Job attributes at all, there's a set of Job Object Attributes returned for each Job object 💖
it's not an error for the Printer to return 0 jobs 🫶 and if the response comes back empty because nothing matches, but the request would have returned 1 or more jobs with a status code of 'successful-ok' had there been matching jobs, then the status code for 0 jobs MUST be 'successful-ok' ✨
Group 1: Operation Attributes 🎀
- Status Message: in addition to the REQUIRED status code that every response returns, the response can optionally include a
"status-message"(text(255)) and/or a"detailed-status-message"(text(MAX)) operation attribute, as described in sections 13 and 3.1.6 💬 - Natural Language and Character Set: the
"attributes-charset"and"attributes-natural-language"attributes, as described in section 3.1.4.2 📚
Group 2: Unsupported Attributes 🙅♀️
See section 3.1.7 for all the details on returning Unsupported Attributes 📖 The response NEED NOT contain the "requested-attributes" operation attribute with any supplied values (attribute keywords) that were requested by the client but aren't supported by the IPP object 🥹 If the Printer object does return unsupported attributes referenced in "requested-attributes", and that attribute included group names like 'all', the unsupported attributes MUST NOT include attributes that are described in the standard but not supported by the implementation 🔍
Groups 3 to N: Job Object Attributes 📦
The Printer object responds with one set of Job Object Attributes for each returned Job object 💅 It ignores (doesn't respond with) any requested attribute or value that isn't supported, or that's restricted by the security policy in force. That includes whether the requesting user is the user who submitted the job (the job originating user) or not (see section 8) 🔒 However, the Printer object MUST respond with the 'unknown' value for any supported attribute (including all REQUIRED attributes) whose value it doesn't know, unless that would violate the security policy 🫣 See the description of the "out-of-band" values at the beginning of Section 4.1 📝
Jobs come back in this order:
- If the client requests all
'completed'Jobs (Jobs in the'completed','aborted', or'canceled'states), they come back newest to oldest, with respect to actual completion time 🕰️ - If the client requests all
'not-completed'Jobs (Jobs in the'pending','processing','pending-held', and'processing-stopped'states), they come back in relative chronological order of expected time to complete, based on whatever scheduling algorithm is configured for the Printer object 🗓️
3.2.7 Pause-Printer Operation 💤
okay this one is OPTIONAL and lets a client stop the Printer object from scheduling jobs on all of its devices 🛑 depending on the implementation, the Pause-Printer operation MAY also stop the Printer from processing the current job or jobs 🙈 any job that's currently printing either stops as soon as the implementation permits, or gets completed, depending on the implementation 🖨️ The Printer object MUST still accept create operations to make new jobs, but it MUST prevent any jobs from entering the 'processing' state 🚧
if Pause-Printer is supported, then Resume-Printer MUST be supported too, and vice-versa 👯♀️ bestie rules!
the IPP Printer stops the current job(s) on its device(s) that were in the 'processing' or 'processing-stopped' states as soon as the implementation permits ✋ if the implementation is going to take a noticeable amount of time to stop, the IPP Printer adds the 'moving-to-paused' value to the Printer object's "printer-state-reasons" attribute (see section 4.4.12) ⏳ once all the devices have stopped, the IPP Printer moves the Printer object to the 'stopped' state, removes the 'moving-to-paused' value if it's there, and adds the 'paused' value to "printer-state-reasons" 🥰
when the current job(s) that were in the 'processing' state complete, the IPP Printer moves them to the 'completed' state 🎉 when the current job(s) that were in the 'processing' state stop in the middle of processing, the IPP Printer moves them to the 'processing-stopped' state and adds the 'printer-stopped' value to the job's "job-state-reasons" attribute 🛑
for any jobs that are 'pending' or 'pending-held', the 'printer-stopped' value of their "job-state-reasons" attribute also applies ✨ however, the IPP Printer NEED NOT update those jobs' "job-state-reasons" attributes, and it only needs to return the 'printer-stopped' value when those jobs get queried (the so-called "lazy evaluation") 😴
whether Pause-Printer affects jobs that were submitted to the device from sources other than the IPP Printer object in the same way it affects jobs submitted to the IPP Printer object using IPP depends on the implementation 🤔 That's the difference between using IPP as a universal management protocol and using it just to manage IPP jobs 🧐
the IPP Printer MUST accept the request in any state and move the Printer to the indicated new "printer-state" before returning, as follows 👇
Current New "printer IPP Printer's response status
"printer- "printer- -state- code and action:
state" state" reasons"
'idle' 'stopped' 'paused' 'successful-ok'
'processing' 'processing' 'moving- OPTION 1: 'successful-ok';
to- Later, when all output has
paused' stopped, the "printer-state"
becomes 'stopped', and the
'paused' value replaces the
'moving-to-paused' value in the
"printer-state-reasons"
attribute
'processing' 'stopped' 'paused' OPTION 2: 'successful-ok';
all device output stopped
immediately
'stopped' 'stopped' 'paused' 'successful-ok'🔐 Access Rights: the authenticated user (see section 8.3) performing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST reject the operation and return'client-error-forbidden','client-error-not-authenticated', or'client-error-not-authorized', as appropriate. 🚨
3.2.7.1 Pause-Printer Request ✨
okay so the Pause-Printer Request is made up of these attribute groups 💅
Group 1: Operation Attributes
- Natural Language and Character Set: the
attributes-charsetandattributes-natural-languageattributes, which you'll find in section 3.1.4.1 🌸 - Target: the
printer-uri(uri) operation attribute, the target for this operation, see section 3.1.5 🎯 - Requesting User Name: the
requesting-user-name(name(MAX)) attribute SHOULD be supplied by the client, see section 8.3 💜
3.2.7.2 Pause-Printer Response 🦋
and the Pause-Printer Response has these groups 🫶
Group 1: Operation Attributes
- Status Message: on top of the REQUIRED status code that shows up in every response, the response can optionally include a
status-message(text(255)) and/or adetailed-status-message(text(MAX)) operation attribute, see sections 13 and 3.1.6 🔥 - Natural Language and Character Set: the
attributes-charsetandattributes-natural-languageattributes, see section 3.1.4.2 🌈
Group 2: Unsupported Attributes
- for how Unsupported Attributes get returned, check section 3.1.7 👀
3.2.8 Resume-Printer Operation 🌷
okay this one is the glow-up to Pause-Printer ✨ it lets a client get the Printer object scheduling jobs again on all its devices. The Printer object MUST remove 'paused' and 'moving-to-paused' from the Printer object's printer-state-reasons attribute, if they're there. If there are no other reasons to keep a device paused (like a media-jam), the IPP Printer is free to switch itself to the 'processing' or 'idle' state, depending on whether there are jobs to process or not, and the devices get back to processing jobs 🧚
If the Pause-Printer operation is supported, then the Resume-Printer operation MUST be supported, and vice-versa 💖
The IPP Printer removes the 'printer-stopped' value from any job's job-state-reasons attributes in that Printer 🍓
The IPP Printer MUST accept the request in any state and move the Printer object to the new state the way the table shows 📋
Current New "printer- IPP Printer's response status code and
"printer- state" action:
state"
'idle' 'idle' 'successful-ok'
'processing' 'processing' 'successful-ok'
'stopped' 'processing' 'successful-ok';
when there are jobs to be processed
'stopped' 'idle' 'successful-ok';
when there are no jobs to be processed.Access Rights: the authenticated user (see section 8.3) doing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST reject the operation and return:'client-error-forbidden','client-error-not-authenticated', or'client-error-not-authorized', whichever fits best 🔒
The Resume-Printer Request and Resume-Printer Response have the same attribute groups and attributes as Pause-Printer (see sections 3.2.7.1 and 3.2.7.2) 💜
3.2.9 Purge-Jobs Operation 🧹
this one is OPTIONAL 🙈 and it lets a client remove all jobs from an IPP Printer object, no matter their job states, including jobs in the Printer object's Job History (see Section 4.3.7.2). After a Purge-Jobs operation, a Printer object MUST return no jobs in later Get-Job-Attributes and Get-Jobs responses (until new jobs get submitted) 💀
Whether Purge-Jobs (and Get-Jobs) affects jobs that were sent to the device from sources other than the IPP Printer object the same way it affects jobs sent to the IPP Printer object using IPP depends on the implementation. It comes down to whether IPP is used as a universal management protocol or just to manage IPP jobs, respectively 🌈
Note: if an operator wants to cancel all jobs without clearing out the Job History, they use the Cancel-Job operation on each job instead of Purge-Jobs 🫶
The Printer object MUST accept this operation in any state and move the Printer object to the 'idle' state ✨
Access Rights: the authenticated user (see section 8.3) doing this operation must be an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: client-error-forbidden, client-error-not-authenticated, and client-error-not-authorized, as appropriate 🔒
The Purge-Jobs Request and Purge-Jobs Response have the same attribute groups and attributes as Pause-Printer (see sections 3.2.7.1 and 3.2.7.2) 🎀
3.3 Job Operations 🎀
okay so every Job operation targets Job objects 🎯 A client MUST always give some way of identifying the Job object so the IPP object knows the right target. That identification MAY be either a single Job URI or a combo of a Printer URI with a Job ID. The IPP object implementation MUST support both forms of identification for every job 💖
3.3.1 Send-Document Operation 📄
this one is OPTIONAL 💅 and it lets a client make a multi-document Job object that starts out "empty" (no documents yet). In the Create-Job response, the Printer object hands back the Job object's URI (the job-uri attribute) and its 32-bit identifier (the job-id attribute). For each new document the client wants to add, it uses a Send-Document operation. Each Send-Document Request carries the entire stream of document data for one document 📦
If the Printer supports this operation but not multiple documents per job, the Printer MUST reject later Send-Document operations that come with data and return 'server-error-multiple-document-jobs-not-supported'. However, the Printer MUST accept the first document with a 'true' or 'false' value for the last-document operation attribute (see below), so clients MAY always submit one-document jobs with a 'false' value for last-document in the first Send-Document and a 'true' for last-document in the second Send-Document (with no data) 🧚
Create-Job and the send operations that follow (Send-Document or Send-URI) could be spread out over a really long time 😭 so a client MUST send another send operation within the minimum time interval the IPP Printer defines after receiving the previous request for the job. If a Printer object supports Create-Job and Send-Document, the Printer object MUST support the multiple-operation-time-out attribute (see section 4.4.31). This attribute says the minimum number of seconds the Printer object will wait for the next send operation before it takes some recovery action 🕰️
An IPP object MUST recover from an errant client that doesn't supply a send operation, some time after the minimum interval given by the Printer object's multiple-operation-time-out attribute. That recovery MAY include any of the following, or other recovery actions:
- Assume the Job is invalid, start changing the job state to
'aborted', add the'aborted-by-system'value to the job'sjob-state-reasonsattribute (see section 4.3.8), and clean up all resources tied to the Job. In this case, if another send operation finally shows up, the Printer responds with "client-error-not-possible" or "client-error-not-found," depending on whether the Job object still exists when that send operation arrives 💀 - Assume the last send operation received was actually the last document (as if the
last-documentflag had been set to'true'), close the Job object, and go ahead and process it (moving the Job's state to'pending') 🚀 - Assume the last send operation received was actually the last document, close the Job, but move it to
'pending-held'and add the'submission-interrupted'value to the job'sjob-state-reasonsattribute (see section 4.3.8). This lets the user or an operator decide whether to keep processing the Job by moving it back to'pending'with the Release-Job operation (see section 3.3.6), or to cancel it with the Cancel-Job operation (see section 3.3.3) 🫶
Each implementation is free to pick the "best" action based on local policy, whether any documents were added, whether the implementation spools jobs or not, and/or any other info it has available 🧠 If the choice is to abort the Job object, the Job object may already have been processed far enough that some media sheets have been printed 🖨️
Access Rights: the authenticated user (see section 8.3) doing this operation must either be the job owner (as determined in the Create-Job operation) or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return:'client-error-forbidden','client-error-not-authenticated', or'client-error-not-authorized', as appropriate 🔒
3.3.1.1 Send-Document Request ✨
okay so the Send-Document Request has a few attribute groups, and bestie, they're giving organization 💅 🎀
Group 1: Operation Attributes 🌸
Natural Language and Character Set: the attributes-charset and attributes-natural-language attributes, same as in section 3.1.4.1. 💖
Target: you can pick one of two vibes 🦋 Either (1) the printer-uri (uri) plus job-id (integer(1:MAX)), or (2) the job-uri (uri) operation attribute(s). Both define the target for this operation, as described in section 3.1.5. Pick your fighter 🥊
Requesting User Name: the requesting-user-name (name(MAX)) attribute SHOULD be supplied by the client, as described in section 8.3. 🫶
document-name (name(MAX)): the client OPTIONALLY supplies this one 🍓 The Printer object MUST support it. It holds the client-supplied document name. The document name MAY be different from the Job name. It's helpful, but it NEED NOT be unique across multiple documents in the same Job. Usually the client software fills this in automatically for the end user, using a file name or an application-generated name. For more on this attribute, check out the description of the document-name operation attribute in the Print-Job Request (section 3.2.1.1). 📄✨
compression (type3 keyword): see the description of compression for the Print-Job operation in Section 3.2.1.1. 🗜️
document-format (mimeMediaType): see the description of document-format for the Print-Job operation in Section 3.2.1.1. 📑
document-natural-language (naturalLanguage): the client OPTIONALLY supplies this, and the Printer object OPTIONALLY supports it 🌈 It specifies the natural language of the document, but only for document-formats that need a natural language specified in order to image the document unambiguously. There are no particular values the Printer object is required to support. 🗣️
last-document (boolean): the client MUST supply this attribute, and the Printer object MUST support it 👑 It's a boolean flag set to 'true' if this is the last document for the Job, and 'false' otherwise. This is the big finale flag 🎆
Group 2: Document Content 📦
The client MUST supply the document data if the last-document flag is set to 'false'. However, a client might not know that the previous document it sent with a Send-Document (or Send-URI) operation was the last one (aka the last-document attribute was set to 'false'). So it's legal to send a Send-Document request with no document data where the last-document flag is set to 'true' 🙈 That kind of request MUST NOT increment the value of the Job object's number-of-documents attribute, since no real document was added to the job. And it's not an error for a client to submit a job with no actual document data. Like, a single Create-Job and Send-Document request with a last-document operation attribute set to 'true' and no document data is totally fine 💅
3.3.1.2 Send-Document Response ✨
The following sets of attributes are part of the Send-Document Response:
Group 1: Operation Attributes 🌸
Status Message: in addition to the REQUIRED status code returned in every response, the response OPTIONALLY includes a status-message (text(255)) and/or a detailed-status-message (text(MAX)) operation attribute. See sections 13 and 3.1.6 for the details 📝
Natural Language and Character Set: the attributes-charset and attributes-natural-language attributes, as described in section 3.1.4.2. 💜
Group 2: Unsupported Attributes 🫧
See section 3.1.7 for details on returning Unsupported Attributes.
Group 3: Job Object Attributes 🧚
This is the same set of attributes as described in the Print-Job response (see section 3.2.1.2). It's giving déjà vu, but in a good way 💖
3.3.2 Send-URI Operation 🦋
This OPTIONAL operation is identical to the Send-Document operation (see section 3.3.1), except that a client MUST supply a URI reference (the document-uri operation attribute) instead of the document data itself. 🔗 If a Printer object supports this operation, clients can use either Send-URI or Send-Document to add new documents to an existing multi-document Job object. 📚 However, if a client needs to indicate that the previous Send-URI or Send-Document was the last document, the client MUST use the Send-Document operation with no document data and the last-document flag set to 'true'. It can't use a Send-URI operation with no document-uri operation attribute for this. 🚫
If a Printer object supports this operation, it MUST also support the Print-URI operation (see section 3.2.2). 🫶
The Printer object MUST validate the syntax and URI scheme of the supplied URI before returning a response, just as in the Print-URI operation. 🔍 The IPP Printer MAY validate the accessibility of the document as part of the operation or subsequently (see section 3.2.2). ✨
3.3.3 Cancel-Job Operation 🛑
This REQUIRED operation lets a client cancel a Print Job from the time the job is created up until it is completed, canceled, or aborted. 🙅♀️ Since a Job might already be printing by the time a Cancel-Job is received, some media sheet pages might still get printed before the job is actually terminated. Oops 🙈
The IPP object MUST accept or reject the request based on the job's current state, and transition the job to the indicated new state as follows:
Current "job- New "job- IPP object's response status
state" state" code and action:
'pending' 'canceled' 'successful-ok'
'pending-held' 'canceled' 'successful-ok'
'processing' 'canceled' 'successful-ok'
'processing' 'processing' 'successful-ok' See Rule 1
'processing' 'processing' 'client-error-not-possible'
See Rule 2
'processing- 'canceled' 'successful-ok'
stopped'
'processing- 'processing- 'successful-ok' See Rule 1
stopped' stopped'
'processing- 'processing- 'client-error-not-possible'
stopped' stopped' See Rule 2
'completed' 'completed' 'client-error-not-possible'
'canceled' 'canceled' 'client-error-not-possible'
'aborted' 'aborted' 'client-error-not-possible'Rule 1: if the implementation needs some measurable time to cancel the job in the 'processing' or 'processing-stopped' job states, the IPP object MUST add the 'processing-to-stop-point' value to the job's job-state-reasons attribute. Then it transitions the job to the 'canceled' state when the processing ceases (see section 4.3.8). ⏳
Rule 2: if the Job object already has the 'processing-to-stop-point' value in its job-state-reasons attribute, then the Printer object MUST reject a Cancel-Job operation. 🚫💀
Access Rights: the authenticated user (see section 8.3) performing this operation must either be the job owner, or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return'client-error-forbidden','client-error-not-authenticated', or'client-error-not-authorized', as appropriate. 🔐
3.3.3.1 Cancel-Job Request 🎀
The following groups of attributes are part of the Cancel-Job Request:
Group 1: Operation Attributes 🌸
Natural Language and Character Set: the attributes-charset and attributes-natural-language attributes, as described in section 3.1.4.1. 💖
Target: either (1) the printer-uri (uri) plus job-id (integer(1:MAX)), or (2) the job-uri (uri) operation attribute(s). Both define the target for this operation, as described in section 3.1.5. 🦋
Requesting User Name: the requesting-user-name (name(MAX)) attribute SHOULD be supplied by the client, as described in section 8.3. 🫶
message (text(127)): the client OPTIONALLY supplies this, and the Printer object OPTIONALLY supports it 📨 It's a message to the operator. This message attribute is NOT the same as the job-message-from-operator attribute. That one reports a message from the operator to the end user, who queries it. This message operation attribute is used to send a message from the client to the operator along with the operation request. How or where to display it to the operator (if at all) is an implementation decision 🤷♀️
3.3.3.2 Cancel-Job Response ✨
The following sets of attributes are part of the Cancel-Job Response:
Group 1: Operation Attributes 🌸
Status Message: in addition to the REQUIRED status code returned in every response, the response OPTIONALLY includes a status-message (text(255)) and/or a detailed-status-message (text(MAX)) operation attribute. See sections 13 and 3.1.6 for the details 📝
Natural Language and Character Set: the attributes-charset and attributes-natural-language attributes, as described in section 3.1.4.2. 💜
Group 2: Unsupported Attributes 🫧
See section 3.1.7 for details on returning Unsupported Attributes.
Once a successful response has been sent, the implementation guarantees that the Job will eventually end up in the 'canceled' state. 🫶 Between the time the Cancel-Job operation is accepted and the time the job enters the 'canceled' job-state (see section 4.3.7), the job-state-reasons attribute SHOULD contain the 'processing-to-stop-point' value. That value tells later queries that although the Job might still be 'processing', it will eventually end up 'canceled', NOT 'completed'. It's the receipt that proves the job is going out for good 🧾💅
3.3.4. Get-Job-Attributes Operation ✨
okay bestie, this one is REQUIRED 💅 so every implementation has to have it. It lets a client ask for the values of a Job object's attributes, and it's basically a twin of Get-Printer-Attributes (see section 3.2.5) 👯♀️. The differences are that it's aimed at a Job object instead of a Printer object, there's no "document-format" operation attribute when you're querying a Job, and what comes back is a set of Job object attributes instead of Printer object attributes.
For Jobs, the possible attribute group names are:
'job-template': the subset of the Job Template attributes that apply to a Job object (the first column of the table in Section 4.2) that the implementation supports for Job objects. 🎀'job-description': the subset of the Job Description attributes specified in Section 4.3 that the implementation supports for Job objects. 📋'all': the special group'all'that includes all attributes that the implementation supports for Job objects. 👑
Since a client MAY request specific attributes or named groups, there is a potential that there is some overlap. For example, if a client requests, 'job-name' and 'job-description', the client is actually requesting the "job-name" attribute once by naming it explicitly, and once by inclusion in the 'job-description' group. In such cases, the Printer object NEED NOT return the attribute only once in the response even if it is requested multiple times. The client SHOULD NOT request the same attribute in multiple ways. 🙈
It is NOT REQUIRED that a Job object support all attributes belonging to a group (since some attributes are OPTIONAL). However, it is REQUIRED that each Job object support all these group names. 🫶
3.3.4.1. Get-Job-Attributes Request 💌
The following groups of attributes are part of the Get-Job-Attributes Request when the request is directed at a Job object:
Group 1: Operation Attributes
- Natural Language and Character Set: The
"attributes-charset"and"attributes-natural-language"attributes as described in section 3.1.4.1. - Target: Either (1) the
"printer-uri"(uri) plus"job-id"(integer(1:MAX)) or (2) the"job-uri"(uri) operation attribute(s) which define the target for this operation as described in section 3.1.5. 🎯 - Requesting User Name: The
"requesting-user-name"(name(MAX)) attribute SHOULD be supplied by the client as described in section 8.3. 🧑💻 "requested-attributes"(1setOf keyword): The client OPTIONALLY supplies this attribute. The IPP object MUST support this attribute. It is a set of attribute names and/or attribute group names in whose values the requester is interested. If the client omits this attribute, the IPP object MUST respond as if this attribute had been supplied with a value of'all'. 🔍
3.3.4.2. Get-Job-Attributes Response 🎁
The Printer object returns the following sets of attributes as part of the Get-Job-Attributes Response:
Group 1: Operation Attributes
- Status Message: In addition to the REQUIRED status code returned in every response, the response OPTIONALLY includes a
"status-message"(text(255)) and/or a"detailed-status-message"(text(MAX)) operation attribute as described in sections 13 and 3.1.6. 💬 - Natural Language and Character Set: The
"attributes-charset"and"attributes-natural-language"attributes as described in section 3.1.4.2. The"attributes-natural-language"MAY be the natural language of the Job object, rather than the one requested. 🌍
Group 2: Unsupported Attributes
- See section 3.1.7 for details on returning Unsupported Attributes. 🧾
The response NEED NOT contain the "requested-attributes" operation attribute with any supplied values (attribute keywords) that were requested by the client but are not supported by the IPP object. If the Printer object does return unsupported attributes referenced in the "requested-attributes" operation attribute and that attribute included group names, such as 'all', the unsupported attributes MUST NOT include attributes described in the standard but not supported by the implementation. 🚫
Group 3: Job Object Attributes
- This is the set of requested attributes and their current values. The IPP object ignores (does not respond with) any requested attribute or value which is not supported or which is restricted by the security policy in force, including whether the requesting user is the user that submitted the job (job originating user) or not (see section 8). However, the IPP object MUST respond with the
'unknown'value for any supported attribute (including all REQUIRED attributes) for which the IPP object does not know the value, unless it would violate the security policy. See the description of the"out-of-band"values in the beginning of Section 4.1. 🔐
3.3.5. Hold-Job Operation ⏸️
This OPTIONAL operation lets a client hold a pending job in the queue so that it is not eligible for scheduling, like a little "not yet bestie" 🙅♀️. If the Hold-Job operation is supported, then the Release-Job operation MUST be supported, and vice-versa. The OPTIONAL "job-hold-until" operation attribute lets a client specify whether to hold the job indefinitely or until a specified time period, if supported. ⏳
The IPP object MUST accept or reject the request based on the job's current state and transition the job to the indicated new state as follows:
Current "job- New "job-state" IPP object's response status
state" code and action:
'pending' 'pending-held' 'successful-ok' See Rule 1
'pending' 'pending' 'successful-ok' See Rule 2
'pending-held' 'pending-held' 'successful-ok' See Rule 1
'pending-held' 'pending' 'successful-ok' See Rule 2
'processing' 'processing' 'client-error-not-possible'
'processing- 'processing- 'client-error-not-possible'
stopped' stopped'
'completed' 'completed' 'client-error-not-possible'
'canceled' 'canceled' 'client-error-not-possible'
'aborted' 'aborted' 'client-error-not-possible'Rule 1: If the implementation supports multiple reasons for a job to be in the 'pending-held' state, the IPP object MUST add the 'job-hold-until-specified' value to the job's "job-state-reasons" attribute. 🧾
Rule 2: If the IPP object supports the "job-hold-until" operation attribute, but the specified time period has already started (or is the 'no-hold' value) and there are no other reasons to hold the job, the IPP object MUST make the job be a candidate for processing immediately (see Section 4.2.2) by putting the job in the 'pending' state. 🚀
Note: In order to keep the Hold-Job operation simple, such a request is rejected when the job is in the 'processing' or 'processing-stopped' states. If an operation is needed to hold jobs while in these states, it will be added as an additional operation, rather than overloading the Hold-Job operation. Then it is clear to clients by querying the Printer object's "operations-supported" (see Section 4.4.15) and the Job object's "job-state" (see Section 4.3.7) attributes which operations are possible. 👀
Access Rights: The authenticated user (see section 8.3) performing this operation must either be the job owner or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return: 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate. 🔒 this part is giving bouncer energy, and I'm here for it.
3.3.5.1. Hold-Job Request 📝
The groups and operation attributes are the same as for a Cancel-Job request (see section 3.3.3.1), with the addition of the following Group 1 Operation attribute:
"job-hold-until"(type3 keyword | name(MAX)): The client OPTIONALLY supplies this Operation attribute. The IPP object MUST support this operation attribute in a Hold-Job request, if it supports the"job-hold-until"Job template attribute in create operations. See section 4.2.2. The IPP object SHOULD support the"job-hold-until"Job Template attribute for use in job create operations with at least the'indefinite'value, if it supports the Hold-Job operation. Otherwise, a client cannot create a job and hold it immediately (without picking some supported time period in the future). 😩
If supplied and supported as specified in the Printer's "job-hold-until-supported" attribute, the IPP object copies the supplied operation attribute to the Job object, replacing the job's previous "job-hold-until" attribute, if present, and makes the job a candidate for scheduling during the supplied named time period. 📅
If supplied, but either the "job-hold-until" Operation attribute itself or the value supplied is not supported, the IPP object accepts the request, returns the unsupported attribute or value in the Unsupported Attributes Group according to section 3.1.7, returns the 'successful-ok-ignored-or-substituted-attributes', and holds the job indefinitely until a client performs a subsequent Release-Job operation. 🤷♀️
If the client (1) supplies a value that specifies a time period that has already started or the 'no-hold' value (meaning don't hold the job) and (2) the IPP object supports the "job-hold-until" operation attribute and there are no other reasons to hold the job, the IPP object MUST accept the operation and make the job be a candidate for processing immediately (see Section 4.2.2). 🏃♀️
If the client does not supply a "job-hold-until" Operation attribute in the request, the IPP object MUST populate the job object with a "job-hold-until" attribute with the 'indefinite' value (if IPP object supports the "job-hold-until" attribute) and hold the job indefinitely, until a client performs a Release-Job operation. 🧊
3.3.5.2. Hold-Job Response 📨
The groups and attributes are the same as for a Cancel-Job response (see section 3.3.3.2). 💖
3.3.6 Release-Job Operation 🦋
okay so this one is OPTIONAL bestie 🫶 It lets a client release a job that was held earlier, so it's eligible for scheduling again 🍓 If Hold-Job is supported, then Release-Job MUST be supported too, and vice-versa. Twins, basically 👯♀️
This operation removes the "job-hold-until" job attribute (if it's there) from the job object that was given in the create or the most recent Hold-Job or Restart-Job operation, and it removes that attribute's effect on the job ✨ The IPP object MUST remove the 'job-hold-until-specified' value from the job's "job-state-reasons" attribute, if it's present. See section 4.3.8.
The IPP object MUST accept or reject the request based on the job's current state, and move the job to the requested new state like this 💅
Current "job- New "job-state" IPP object's response status
state" code and action:
'pending' 'pending' 'successful-ok'
No effect on the job.
'pending-held' 'pending-held' 'successful-ok' See Rule 1
'pending-held' 'pending' 'successful-ok'
'processing' 'processing' 'successful-ok'
No effect on the job.
'processing- 'processing- 'successful-ok'
stopped' stopped' No effect on the job.
'completed' 'completed' 'client-error-not-possible'
'canceled' 'canceled' 'client-error-not-possible'
'aborted' 'aborted' 'client-error-not-possible'Rule 1: if there are other reasons to keep the job in 'pending-held', like 'resources-are-not-ready', the job stays in 'pending-held' 🧸 So 'pending-held' isn't only for jobs with 'job-hold-until' on them. It's for any reason at all to keep a job from being a candidate for scheduling and processing, such as 'resources-are-not-ready'. See the "job-hold-until" attribute (section 4.2.2).
Access Rights: the authenticated user (see section 8.3) performing this operation must either be the job owner or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized', whichever fits ⚠️
The Release-Job Request and Release-Job Response have the same attribute groups and attributes as the Cancel-Job operation (see section 3.3.3.1 and 3.3.3.2).
3.3.7 Restart-Job Operation 🔁
This is another OPTIONAL one 💖 It lets a client restart a job that's kept in the queue after processing has finished (see section 4.3.7.2).
The job moves to the 'pending' or 'pending-held' job state and starts over from the very beginning on the same IPP Printer object, with the same attribute values 🌸 If any documents in the job were passed by reference (Print-URI or Send-URI), the Printer MUST re-fetch the data, because Restart-Job means repeating all of the job's processing from scratch. The Job Description attributes that track progress, like "job-impressions-completed", "job-media-sheets-completed", and "job-k-octets-processed", MUST be reset to 0, so they give an accurate record from the restart point. The job object MUST keep using the same "job-uri" and "job-id" attribute values 🎀
Note: if an operation that does NOT reset the job progress attributes is ever needed in the future, a new operation will be defined. It'll make a copy of the job, give the copy a new "job-uri" and "job-id", and reset the progress attributes in the copy only 🧚
The IPP object MUST accept or reject the request based on the job's current state, and move the job to the indicated new state as follows 💅
Current "job- New "job-state" IPP object's response status
state" code and action:
'pending' 'pending' 'client-error-not-possible'
'pending-held' 'pending-held' 'client-error-not-possible'
'processing' 'processing' 'client-error-not-possible'
'processing- 'processing- 'client-error-not-possible'
stopped' stopped'
'completed' 'pending' or 'successful-ok' - job is started
'pending-held' over.
'completed' 'completed' 'client-error-not-possible' -
see Rule 1
'canceled' 'pending' or 'successful-ok' - job is started
'pending-held' over.
'canceled' 'canceled' 'client-error-not-possible' -
see Rule 1
'aborted' 'pending' or 'successful-ok' - job is started
'pending-held' over.
'aborted' 'aborted' 'client-error-not-possible' -
see Rule 1Rule 1: if the Job Retention Period has expired for the job in this state, then the IPP object rejects the operation. See section 4.3.7.2.
Note: to stop a user from accidentally restarting a job in the middle of things 🙈, Restart-Job requests are rejected when the job is in the 'processing' or 'processing-stopped' states. If an operation to hold or restart jobs in those states is ever needed, it'll be added as its own operation instead of overloading Restart-Job. That way it's crystal clear that the user meant for the current job not to be completed.
Access Rights: the authenticated user (see section 8.3) performing this operation must either be the job owner or an operator or administrator of the Printer object (see Sections 1 and 8.5). Otherwise, the IPP object MUST reject the operation and return 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized', whichever fits 🫠
3.3.7.1 Restart-Job Request 📨
The groups and attributes are the same as for a Cancel-Job request (see section 3.3.3.1), plus one extra Group 1 Operation attribute ✨
"job-hold-until" (type3 keyword | name(MAX)):The client optionally supplies this attribute. The IPP object MUST support this Operation attribute in a Restart-Job request if it supports the "job-hold-until" Job Template attribute in create operations (see section 4.2.2). Otherwise, the IPP object need not support the "job-hold-until" Operation attribute in a Restart-Job request.
If it's supplied and supported as specified in the Printer's "job-hold-until-supported" attribute, the IPP object copies the supplied Operation attribute to the Job object, replacing the job's previous "job-hold-until" attribute if it had one. It also makes the job a candidate for scheduling during the named time period you supplied (see section 4.2.2) 🕰️
If it's supplied but the value isn't supported, the IPP object accepts the request, returns the unsupported attribute or value in the Unsupported Attributes Group according to section 3.1.7, returns the 'successful-ok-ignored-or-substituted-attributes' status code, and holds the job indefinitely until a client performs a later Release-Job operation 😵💫
If it's supplied but the "job-hold-until" Operation attribute itself isn't supported, the IPP object accepts the request, returns the unsupported attribute with the out-of-band 'unsupported' value in the Unsupported Attributes Group according to section 3.1.7, returns the 'successful-ok-ignored-or-substituted-attributes' status code, and restarts the job. In other words, it ignores the "job-hold-until" attribute.
If the client (1) supplies a value that specifies a time period that has already started, or the 'no-hold' value (meaning don't hold the job), and (2) the IPP object supports the "job-hold-until" operation attribute and there are no other reasons to hold the job, the IPP object makes the job a candidate for processing immediately (see Section 4.2.2) 🚀
If the client doesn't supply a "job-hold-until" operation attribute in the request, the IPP object removes the "job-hold-until" attribute from the job if it's present. If there are no other reasons to hold the job, the Restart-Job operation makes the job a candidate for processing immediately (see Section 4.2.2) 💨
3.3.7.2 Restart-Job Response 📬
The groups and attributes are the same as for a Cancel-Job response (see section 3.3.3.2).
Note: in the future, an OPTIONAL Modify-Job or Set-Job-Attributes operation may be specified. It would let the client modify other attributes before releasing the restarted job 🎀
4. Object Attributes 🌈
This section describes the attributes, with their attribute syntaxes and values, that are part of the IPP model 🧁 The sections below show the objects and their associated attributes that are in scope for this protocol. A lot of these attributes come from other relevant documents:
Each attribute is uniquely identified in this document by a "keyword" (see section 12.2.1), which is the attribute's name. The keyword shows up in the section header that describes that attribute 🔑
Note: keywords aren't the only thing used to identify attributes. One of the attribute syntaxes below is "keyword" too, so some attributes have keyword values. That's why these attributes are defined as having an attribute syntax that is a set of keywords 💜
4.1 Attribute Syntaxes ✨
okay so this section is the rulebook for what kinds of values an attribute is allowed to have 📜🎀 All clients and IPP objects MUST be able to accept these basic attribute syntax types, in responses and in requests respectively 💖 Each attribute description in sections 3 and 4 puts the name of its attribute syntax(es) in parentheses in the heading 🦋 A conforming implementation of an attribute MUST include the semantics of the attribute syntax(es) identified there, no shortcuts bestie 🫶 If you want to see how the protocol can grow new attribute syntaxes, check out Section 6.3 💅
each sub-section below is named after the keyword of its attribute syntax, which is the bit inside the single quotes 🌸 in operation requests and responses, every attribute value MUST be represented as one of the attribute syntaxes in the heading for that attribute 💅 now here's the twist: the value of an attribute in a response (but not in a request) MAY be one of the "out-of-band" values, whose special encoding rules are defined in the "Encoding and Transport" document [RFC2910] 🧚 the standard "out-of-band" values are:
'unknown': The attribute is supported by the IPP object, but the value is unknown to the IPP object for some reason. 🤷♀️'unsupported': The attribute is unsupported by the IPP object. This value MUST be returned only as the value of an attribute in the Unsupported Attributes Group. 🙈'no-value': The attribute is supported by the Printer object, but the administrator has not yet configured a value. 🍓
All attributes in a request MUST have one or more values as defined in Sections 4.2 to 4.4. Thus clients MUST NOT supply attributes with "out-of-band" values for operations defined in this document. All attributes in a response MUST have one or more values as defined in Sections 4.2 to 4.4 or a single "out-of-band" value. no out-of-band values in requests, period 🙅♀️
most attributes only have one attribute syntax, but a few (e.g., "job-sheet", "media", "job-hold-until") have several, depending on the value 👑 those choices are separated by the "|" character in the sub-section heading. since each value MUST be tagged as to its attribute syntax in the protocol, a single-valued attribute instance may have any one of its attribute syntaxes, and a multi-valued attribute instance may have a mixture of its defined attribute syntaxes. it's giving mix-and-match 🌈
4.1.1 'text'
a text attribute is an attribute whose value is a sequence of zero or more characters encoded in a maximum of 1023 ('MAX') octets 📝 MAX is the maximum length for each value of any text attribute. however, if an attribute will always contain values whose maximum length is much less than MAX, the definition of that attribute will include a qualifier that sets the maximum length for values of that attribute. for example, the "printer-location" attribute is specified as printer-location (text(127)). in this case, text values for "printer-location" MUST NOT exceed 127 octets. if a longer text string is supplied via some external interface (other than the protocol), implementations are free to truncate it to this shorter length limitation ✂️
in this document, all text attributes are defined using the 'text' syntax. but 'text' is only shorthand, the formal meaning is 'textWithoutLanguage | textWithLanguage'. so for any attribute defined in this document using the 'text' attribute syntax, all IPP objects and clients MUST support both the 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes. in actual usage and protocol execution though, objects and clients accept and return only one of the two syntaxes per attribute. the 'text' syntax never shows up "on-the-wire" 👀
both of these are needed for real-world interoperability between sites and systems that use different natural languages to communicate with humans 🌍 generally, one natural language applies to all text attributes in a given request or response. that language is indicated by the "attributes-natural-language" operation attribute defined in section 3.1.4, or the "attributes-natural-language" job attribute defined in section 4.3.20, so there's no need to label the language for every single text string. in these cases, the attribute syntax 'textWithoutLanguage' is used for text attributes. in other cases, the client needs to supply, or the Printer object needs to return, a text value in a natural language that's different from the rest of the text values in the request or response. then the client or Printer object uses the attribute syntax 'textWithLanguage' for text attributes. this is the Natural Language Override mechanism described in section 3.1.4 💫
the 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes are described in more detail in the following sections.
4.1.1.1 'textWithoutLanguage'
the 'textWithoutLanguage' syntax indicates a value that is sequence of zero or more characters encoded in a maximum of 1023 (MAX) octets. text strings are encoded using the rules of some charset. the Printer object MUST support the UTF-8 charset [RFC2279] and MAY support additional charsets to represent 'text' values, provided that those charsets are registered with IANA [IANA-CS]. see Section 4.1.7 for the definition of the 'charset' attribute syntax, including restricted semantics and examples of charsets 🌷
4.1.1.2 'textWithLanguage'
the 'textWithLanguage' attribute syntax is a compound syntax with two parts 💅 first, a 'textWithoutLanguage' part encoded in a maximum of 1023 (MAX) octets, plus an extra 'naturalLanguage' part (see section 4.1.8) that overrides the natural language in force. the 'naturalLanguage' part explicitly identifies the natural language that applies to the text part of that value, and that value alone. for any give text attribute, the 'textWithoutLanguage' part is limited to the maximum length defined for that 'text' attribute, and the 'naturalLanguage' part is always limited to 63 (additional) octets. using 'textWithLanguage' instead of the normal 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism, and it MUST be supported by all IPP objects and clients 🌈
if the attribute is multi-valued (1setOf text), then the 'textWithLanguage' attribute syntax MUST be used to explicitly specify each attribute value whose natural language needs to be overridden. other values in a multi-valued 'text' attribute in a request or a response revert to the natural language of the operation attribute 🔁
in a create request, the Printer object MUST accept and store with the Job object any natural language in the "attributes-natural-language" operation attribute, whether the Printer object supports that natural language or not. furthermore, the Printer object MUST accept and store any 'textWithLanguage' attribute value, whether the Printer object supports that natural language or not. these requirements are independent of the value of the "ipp-attribute-fidelity" operation attribute that the client MAY supply. no matter what language it is, the printer keeps it 🫶
Example: if the client supplies the "attributes-natural-language" operation attribute with the value 'en' (English), but the value of the "job-name" attribute is in French, the client MUST use the 'textWithLanguage' attribute syntax with the following two values:
'fr': Natural Language Override indicating French
'Rapport Mensuel': the job name in Frenchsee the "Encoding and Transport" document [RFC2910] section 3.9 for the encoding of the two parts, and Appendix A for a detailed example of the 'textWithLanguage' attribute syntax 📖
4.1.2 'name'
this syntax type is used for user-friendly strings, like a Printer name, that are more meaningful to humans than identifiers 🎀 names are never translated from one natural language to another. the 'name' attribute syntax is basically the same as 'text', including the REQUIRED support of UTF-8, except that the sequence of characters is limited so that its encoded form MUST NOT exceed 255 (MAX) octets 🦋
also like 'text', 'name' is really shorthand for either 'nameWithoutLanguage' or 'nameWithLanguage'. so all IPP objects and clients MUST support both the 'nameWithoutLanguage' and 'nameWithLanguage' attribute syntaxes. in actual usage and protocol execution, objects and clients accept and return only one of the two syntaxes per attribute. the 'name' syntax never appears "on-the-wire" 🙈
only the 'text' and 'name' attribute syntaxes permit the Natural Language Override mechanism 💖
some attributes are defined as 'type3 keyword | name'. these attributes support values that are either type3 keywords or names. this dual-syntax mechanism lets a site administrator extend these attributes to legally include values that are defined locally by that administrator 🧚 such names are not registered with IANA, so they stay local to the site 🏠
4.1.2.1 'nameWithoutLanguage'
the 'nameWithoutLanguage' syntax indicates a value that is sequence of zero or more characters encoded in a maximum of 255 (MAX) octets. ✨
4.1.2.2 'nameWithLanguage' 💖
okay so 'nameWithLanguage' is a compound syntax with two parts 🎀. First there's a 'nameWithoutLanguage' part, capped at 1023 (MAX) octets. Then there's a 'naturalLanguage' part (see section 4.1.8) that overrides whichever language is in force. That override part names the language for that one name value and that one name value alone ✨. For any given text attribute, the 'textWithoutLanguage' part is limited to the max length for that 'text' attribute, and the 'naturalLanguage' part is always capped at 63 (additional) octets. Using 'textWithLanguage' instead of the normal 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism 🌈, and it MUST be supported by all IPP objects and clients 🫶.
The 'nameWithLanguage' syntax behaves exactly like 'textWithLanguage' 💅. Using 'textWithLanguage' instead of the normal 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism, and it MUST be supported by all IPP objects and clients, no exceptions 🙈. If a name is in a different language from the rest of the object or operation, you use this 'nameWithLanguage' syntax instead of the generic 'nameWithoutLanguage' one 🦋.
If the attribute is multi-valued (1setOf text), then the 'nameWithLanguage' syntax MUST be used to explicitly specify each attribute value whose natural language needs overriding 👑.
Any other values in a multi-valued 'name' attribute, in a request or a response, go back to the natural language of the operation attribute 🌸.
In a create request, the Printer object MUST accept and store with the Job object any natural language in the "attributes-natural-language" operation attribute, whether the Printer object supports that language or not 💜. It also MUST accept and store any 'nameWithLanguage' attribute value, again whether or not it supports that language 🔥. None of this depends on the "ipp-attribute-fidelity" operation attribute that the client MAY supply 🧚.
Example: say the client supplies the "attributes-natural-language" operation attribute with the value 'en' (English), but the "printer-name" attribute is in German 🇩🇪. The client MUST use the 'nameWithLanguage' attribute syntax like this:
'de': Natural Language Override indicating German
'Farbdrucker': the Printer name in GermanFor the encoding of the two parts, check section 3.9 of the "Encoding and Transport" document [RFC2910], and Appendix A has a detailed example of the 'nameWithLanguage' attribute syntax 📚✨.
4.1.2.3 Matching 'name' attribute values 🔍
okay, for matching two 'name' attribute values for equality 💖, such as during job validation (where a client-supplied value for attribute "xxx" gets checked against the values of the Printer object's matching "xxx-supported" attribute), these match rules apply:
'keyword'values never match'name'values 🙅♀️.'name'values (nameWithoutLanguage and nameWithLanguage) match if (1) the name parts match and (2) the Associated Natural-Language parts (see section 3.1.4.1) match. The rules are:- a. the name parts match if the two names are identical character by character, except it is RECOMMENDED that case be ignored 🌈. For example:
'Ajax-letter-head-white'MUST match'Ajax-letter-head-white'and SHOULD match'ajax-letter-head-white'and'AJAX-LETTER-HEAD-WHITE'✨. - b. the Associated Natural-Language parts match if the shorter of the two meets the syntactic requirements of RFC 1766 [RFC1766] and matches byte for byte with the longer one 🦋. For example,
'en'matches'en','en-us'and'en-gb', but matches neither'fr'nor'e'💅.
- a. the name parts match if the two names are identical character by character, except it is RECOMMENDED that case be ignored 🌈. For example:
4.1.3 'keyword' 🎀
okay, the 'keyword' syntax is a sequence of characters, 1 to 255 long 🍓. It only uses the US-ASCII [ASCII] encoded values for lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot ("."), and underscore ("_") 💜. The first character MUST be a lowercase letter, and keywords MUST be in U.S. English 🇺🇸.
This type is for enumerating semantic identifiers of entities in the abstract protocol, meaning the entities this document identifies 🧚. Keywords are used as attribute names or as attribute values. Unlike 'text' and 'name' values, 'keyword' values MUST NOT use the Natural Language Override mechanism 🙈, since they MUST always be US-ASCII and U.S. English 🫶.
Keywords are for use in the protocol 🤖. A user interface will likely map protocol keywords to friendly, localized words and phrases in the user's natural language 🌸. The keywords in this document MAY be displayed to users whose natural language is U.S. English, and they MAY be mapped to other U.S. English words for U.S. English users, since the user interface is outside the scope of this document 💖.
For each attribute of this type, the full set of defined keyword values gets listed in that attribute's definition 📋.
When a keyword represents an attribute (its name), it MUST be unique across the full scope of all IPP objects and attributes 👑. When a keyword represents a value of an attribute, it MUST be unique just within that attribute's scope 🔥. So the same keyword MUST NOT be used for two different values within the same attribute to mean two different semantic ideas 🙅♀️. However, the same keyword MAY be used across two or more attributes, representing different semantic ideas for each attribute ✨. Section 6.1 explains how the protocol can be extended with new keyword values 🦋. Examples of attribute name keywords:
"job-name"
"attributes-charset"Note: this document uses "type1", "type2", and "type3" prefixes on the 'keyword' basic syntax to show different levels of review for extensions (see section 6.1) 📚🌈.
4.1.4 'enum' 🌸
The 'enum' syntax is an enumerated integer value in the range from 1 to 2**31 - 1 (MAX) 🔢. Each value has an associated 'keyword' name 🏷️. For each attribute of this type, the full set of possible values gets listed in that attribute's definition ✨. This type is used for attributes that get enum values assigned by other standards, such as SNMP MIBs 🦋. A number of attribute enum values in this document are also used for corresponding attributes in other standards [RFC1759] 💜. This type is not used for attributes to which the administrator may assign values 🙈. Section 6.1 explains how the protocol can be extended with new enum values 💅.
Enum values are for use in the protocol 🤖. A user interface maps protocol enum values to displayable, localized words and phrases in the user's natural language 🌸. The enum symbols in this document MAY be displayed to users whose natural language is U.S. English, and they MAY be mapped to other U.S. English words for U.S. English users, since the user interface is outside the scope of this document 🎀.
Note: SNMP MIBs use '2' for 'unknown', which corresponds to the IPP "out-of-band" value 'unknown'. See the description of the "out-of-band" values at the beginning of Section 4.1 👑. Therefore, attributes of type 'enum' start at '3' 🧚.
Note: this document uses "type1", "type2", and "type3" prefixes on the 'enum' basic syntax to show different levels of review for extensions (see section 6.1) 🌈.
4.1.5 'uri' 🦋
The 'uri' syntax is any valid Uniform Resource Identifier, or URI [RFC2396] 🌐. Most of the time, URIs are just Uniform Resource Locators, aka URLs 💖. The maximum length of URIs used as IPP attribute values is 1023 octets 📏. Most other IPP attribute syntaxes only allow lowercased values, but this one follows the case-sensitive and case-insensitive rules in [RFC2396] 🙌. See also [IPP-IIG] for a discussion of case in URIs 📚.
4.1.6 'uriScheme' 🎀
The 'uriScheme' syntax is a sequence of characters representing a URI scheme, according to RFC 2396 [RFC2396] 🧚. RFC 2396 says the values are case-insensitive, but IPP requires all lowercase values in IPP attributes so that IPP clients and Printer objects can compare them easily 💅. The standard values for this syntax are these keywords:
'ipp': for IPP schemed URIs (e.g.,"ipp:...")'http': for HTTP schemed URIs (e.g.,"http:...")'https': for use with HTTPS schemed URIs (e.g.,"https:...") (not on IETF standards track) 🔒'ftp': for FTP schemed URIs (e.g.,"ftp:...") 📂'mailto': for SMTP schemed URIs (e.g.,"mailto:...") 📧'file': for file schemed URIs (e.g.,"file:...") 🗂️
A Printer object MAY support any URI 'scheme' that has been registered with IANA [IANA-MT] 🌸. The maximum length of URI 'scheme' values used to represent IPP attribute values is 63 octets 📏.
4.1.7 'charset' 💜
The 'charset' syntax is a standard identifier for a charset 🔤. A charset is a coded character set plus its encoding scheme 🧠. Charsets label certain document contents and 'text' and 'name' attribute values 🏷️. The syntax and semantics of this type are specified in RFC 2046 [RFC2046] and listed in the IANA character-set Registry [IANA-CS], following the IANA procedures in [RFC2278] 📜. RFC 2046 says the values are case-insensitive US-ASCII [ASCII], but IPP requires all lowercase values in IPP attributes so IPP clients and Printer objects can compare them easily 💖. When a character set in the IANA registry has more than one name (alias), the name labeled "(preferred MIME name)" MUST be used, if it's present 👑.
The maximum length of 'charset' values used to represent IPP attribute values is 63 octets 📏.
Some examples:
'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set (UCS), represented with the UTF-8 [RFC2279] transfer encoding scheme, in which US-ASCII is a subset charset 🌈.'us-ascii': 7-bit American Standard Code for Information Interchange (ASCII), ANSI X3.4-1986 [ASCII] 🦋. That standard defines US-ASCII, but RFC 2045 [RFC2045] removes most of the control characters from conformant usage in MIME and IPP 🙈.'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet Nr 1 [ISO8859-1] 🌍. That standard defines a coded character set used by Latin languages in the Western Hemisphere and Western Europe, and US-ASCII is a subset charset 🧚.
Some attribute descriptions MAY place additional requirements on which charset values can be used 🎀. Those could be REQUIRED values that MUST be supported, or extra restrictions, such as requiring that the charset have US-ASCII as a subset charset 💅✨.
4.1.8 'naturalLanguage' ✨
Okay bestie, so naturalLanguage is the standard identifier for a human language, plus optionally a country 🌍. The values come from RFC 1766 [RFC1766]. RFC 1766 says they're case-insensitive US-ASCII [ASCII], but IPP goes all lowercase so IPP clients and Printer objects can compare them easily 💅. Examples include:
'en': for English
'en-us': for US English
'fr': for French
'de': for GermanThe maximum length of naturalLanguage values used to represent IPP attribute values is 63 octets. 🌸
4.1.9 'mimeMediaType' 🎀
The mimeMediaType attribute syntax is the Internet Media Type (also called a MIME type) defined by RFC 2046 [RFC2046] and registered under the RFC 2048 [RFC2048] procedures. It's how you identify a document format 📄. The value MAY include a charset or other parameter, depending on how the Media Type is specified in the IANA Registry [IANA-MT]. Most other IPP syntax types only allow lowercase, but this one allows mixed case, and those values are case-insensitive 🦋.
Examples are:
'text/html': An HTML document
'text/plain': A plain text document in US-ASCII (RFC 2046
indicates that in the absence of the charset parameter MUST
mean US-ASCII rather than simply unspecified) [RFC2046].
'text/plain; charset=US-ASCII': A plain text document in US-ASCII
[52, 56].
'text/plain; charset=ISO-8859-1': A plain text document in ISO
8859-1 (Latin 1) [ISO8859-1].
'text/plain; charset=utf-8': A plain text document in ISO 10646
represented as UTF-8 [RFC2279]
'application/postscript': A PostScript document [RFC2046]
'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset
escape sequence embedded in the document data)
'application/pdf': Portable Document Format - see IANA MIME Media
Type registry
'application/octet-stream': Auto-sense - see section 4.1.9.1The maximum length of a mimeMediaType value to represent IPP attribute values is 255 octets. 💖
4.1.9.1 Application/octet-stream -- Auto-Sensing the document format 🔥
Okay this one is a whole vibe. application/octet-stream is the special type here. If the Printer object supports it, the Printer object MUST be capable of auto-sensing the format of the document data using an implementation-dependent method that examines some number of octets of the document data. That can happen during the create operation, during document processing, or both 🕵️♀️. While auto-sensing, a Printer might figure out that the document-data is in a format it doesn't recognize. If it finds this out before returning an operation response, it rejects the request and returns the client-error-document-format-not-supported status code 🙅♀️. If it finds out after accepting the request and returning an operation response with one of the successful status codes, the Printer adds the unsupported-document-format value to the job's job-state-reasons attribute 😭.
If the Printer object's document-format-default attribute is set to application/octet-stream, then the Printer object not only supports auto-sensing, it also depends on the result of auto-sensing when the client doesn't supply the document-format attribute 🧚. If the client supplies a document format value, the Printer MUST rely on the supplied attribute and MUST NOT just trust its auto-sensing algorithm 🙈. To summarize:
- If the client does not supply a document format value, the Printer MUST rely on its default value setting (which may be
application/octet-stream, indicating an auto-sensing mechanism). - If the client supplies a value other than
application/octet-stream, the client is supplying valid information about the format of the document data, and the Printer object MUST trust the client-supplied value more than the outcome of applying an automatic format detection mechanism. For example, the client may be requesting the printing of a PostScript file as atext/plaindocument. The Printer object MUST print a text representation of the PostScript commands rather than interpret the stream of PostScript commands and print the result. - If the client supplies a value of
application/octet-stream, the client is indicating that the Printer object MUST use its auto-sensing mechanism on the client-supplied document data, whether auto-sensing is the Printer object's default or not.
Note: Auto-sensing is probabilistic, so if the client requests both auto-sensing (document-formatset toapplication/octet-stream) and true fidelity (ipp-attribute-fidelityset totrue), the Printer object might not be able to guarantee exactly what the end user intended. The auto-sensing algorithm might mistake one document format for another. It can, however, guarantee that its auto-sensing mechanism gets used. 🤓
When a Printer performs auto-sensing on a document in a submitted job, it is RECOMMENDED that the Printer tell the user that auto-sensing happened and which document-format was auto-sensed, by printing that information on the job's job-start-sheet 📃✨.
4.1.10 'octetString' 🍓
The octetString attribute syntax is a sequence of octets encoded in a maximum of 1023 octets, which section headers show using the notation octetString(MAX). It's used for opaque data 🫶.
4.1.11 'boolean' 💜
The boolean attribute syntax has only two values: true and false. Simple and iconic 👑.
4.1.12 'integer' 🌈
The integer attribute syntax is an integer in the range from -2**31 (MIN) to 2**31 - 1 (MAX). Each attribute can set its own range in its section header if it's narrower than the full range. For example, job-priority uses integer(1:100). Enforcing that extra constraint is up to the IPP objects, not the protocol 🧠.
4.1.13 'rangeOfInteger' ⭐
The rangeOfInteger attribute syntax is an ordered pair of integers that defines an inclusive range. The first integer is the lower bound, and the second is the upper bound. If an attribute in this document has a rangeOfInteger syntax and its header gives a range constraint (X:Y, with X as the minimum and Y as the maximum), then the constraint applies to both integers 🎯.
4.1.14 'dateTime' 🕰️
The dateTime attribute syntax is a standard, fixed-length, 11-octet representation of the "DateAndTime" syntax defined in RFC 2579 [RFC2579]. RFC 2579 also has an 8-octet representation of a "DateAndTime" value, but IPP objects MUST use the 11-octet representation. A user interface maps protocol dateTime values to friendly, localized words or phrases for the user's natural language and date format, including time zone 🌏.
4.1.15 'resolution' 🖨️
The resolution attribute syntax specifies a two-dimensional resolution in the indicated units. It has 3 values: a cross-feed direction resolution (positive integer), a feed direction resolution (positive integer), and a units value. The meanings come from the suggested values in the Printer MIB [RFC1759]. The cross-feed direction component matches the prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed direction component matches prtMarkerAddressabilityFeedDir, and the units component matches prtMarkerAddressabilityUnit (where 3 means dots per inch and 4 means dots per centimeter). All three values MUST be present, even if the first two are the same. Example: '300', '600', '3' is a 300 dpi cross-feed resolution and a 600 dpi feed direction resolution, since 3 means dots per inch (dpi) 💅✨.
4.1.16 '1setOf X' 🦋
The '1setOf X' attribute syntax is one or more values of attribute syntax type X. It's used for multi-valued attributes. It's called 1setOf instead of plain setOf as a reminder that the set of values MUST NOT be empty (in other words, a set of size 0 is not allowed) 🙅♀️. Sets are normally unordered, but each attribute description of this type can say that the values MUST be in a certain order for that attribute 🍰.
4.2 Job Template Attributes 🎀
Okay bestie, so Job Template attributes are the settings that tell the printer how a job should get processed 🖨️✨ Support for them by a Printer object is OPTIONAL (check out section 12.2.3 for the tea on support for OPTIONAL attributes 💅), and clients can optionally include Job Template attributes in their create requests 🫶
Every Job Template attribute follows these rules. For each one called xxx:
- Okay, this one's the big rule 🔥 If the Printer object supports
xxx, then it MUST support both axxx-defaultattribute (unless there is aNoin the table below) and axxx-supportedattribute. If the Printer object doesn't supportxxx, then it MUST support neither axxx-defaultattribute nor axxx-supportedattribute, and it MUST treat an attributexxxsupplied by a client as unsupported. An attributexxxmay be supported for some document formats and not for others. For example, it's expected that a Printer object would only supportorientation-requestedfor formats like 'text/plain' or 'text/html', but not for something like 'application/postscript' 💖 xxxis optionally supplied by the client in a create request. Ifxxxis supplied, the client is indicating a desired job processing behavior for this Job 🎯 Whenxxxis not supplied, the client is basically saying "use your default job processing behavior at job processing time, unless the document content has an embedded instruction about xxx-related behavior" 🌸- The
xxx-supportedattribute is a Printer object attribute that tells you which job processing behaviors that Printer object supports. A client can query the Printer object to find out what xxx-related behaviors are supported by checking the returned values of thexxx-supportedattribute 🔍 - The
xxx-defaultdefault value attribute describes what will happen at job processing time when the client hasn't given any other job processing info, either explicitly as an IPP attribute in the create request or implicitly as an embedded instruction inside the document data 🧚
Now the plot twist 🙈 An administrator MAY change the default value attribute after a Job object has been submitted but before it's processed, so the default value the Printer object uses at job processing time may be different from the default value that was in effect at job submission time. Wild, right? 💀
Note: Thexxxin eachxxx-supportedattribute name is singular, even though anxxx-supportedattribute usually has more than one value, such asjob-sheet-supported, unless thexxxJob Template attribute is plural, such asfinishingsorsides. In such cases thexxx-supportedattribute names are:finishings-supportedandsides-supported. 🧁
If an application wants to show an end user a list of supported values to pick from, the application SHOULD query the Printer object for its supported value attributes. It SHOULD also query the default value attributes too 👑 If the application then limits selectable values to only the ones that are supported, it can guarantee that the values the client supplies in the create request all fall within the set of supported values at the Printer. That's giving organized 💅 When querying the Printer, the client MAY enumerate each attribute by name in the Get-Printer-Attributes Request, or the client MAY just name the job-template group to get the complete set of supported attributes (both supported and default attributes) ✨
The finishings attribute is the perfect example of a Job Template attribute 🦋 It can take on a set of values like 'staple', 'punch', and/or 'cover'. A client can query the Printer object for the finishings-supported attribute and the finishings-default attribute. The supported attribute holds a set of supported values. The default value attribute holds the finishing value(s) that will be used for a new Job if the client doesn't supply a finishings attribute in the create request and the document data doesn't contain any matching finishing instructions. If the client does supply the finishings attribute in the create request, the IPP object validates the value or values to make sure they're a subset of the supported values listed in the Printer object's finishings-supported attribute. See section 3.1.7 🌈
Here's the summary table of names and relationships for all Job Template attributes 📋 The first column ("Job Attribute") shows the name and syntax for each Job Template attribute in the Job object. These are the ones a client can optionally include in a create request. The last two columns ("Printer: Default Value Attribute" and "Printer: Supported Values Attribute") show the name and syntax for each Job Template attribute in the Printer object (the default value attribute and the supported values attribute). A "No" in the table means the Printer MUST NOT support the attribute, which basically means it's just not applicable 🙅♀️ For brevity, the 'text' and 'name' entries don't show the maximum length for each attribute 🍓
+===================+======================+======================+
| Job Attribute |Printer: Default Value| Printer: Supported |
| | Attribute | Values Attribute |
+===================+======================+======================+
| job-priority | job-priority-default |job-priority-supported|
| (integer 1:100) | (integer 1:100) |(integer 1:100) |
+-------------------+----------------------+----------------------+
| job-hold-until | job-hold-until- |job-hold-until- |
| (type3 keyword | | default | supported |
| name) | (type3 keyword | |(1setOf ( |
| | name) |type3 keyword | name))|
+-------------------+----------------------+----------------------+
| job-sheets | job-sheets-default |job-sheets-supported |
| (type3 keyword | | (type3 keyword | |(1setOf ( |
| name) | name) |type3 keyword | name))|
+-------------------+----------------------+----------------------+
|multiple-document- |multiple-document- |multiple-document- |
| handling | handling-default |handling-supported |
| (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)|
+-------------------+----------------------+----------------------+
| copies | copies-default | copies-supported |
| (integer (1:MAX)) | (integer (1:MAX)) | (rangeOfInteger |
| | | (1:MAX)) |
+-------------------+----------------------+----------------------+
| finishings | finishings-default | finishings-supported |
|(1setOf type2 enum)|(1setOf type2 enum) |(1setOf type2 enum) |
+-------------------+----------------------+----------------------+
| page-ranges | No | page-ranges- |
| (1setOf | | supported (boolean) |
| rangeOfInteger | | |
| (1:MAX)) | | |
+-------------------+----------------------+----------------------+
| sides | sides-default | sides-supported |
| (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)|
+-------------------+----------------------+----------------------+
| number-up | number-up-default | number-up-supported |
| (integer (1:MAX)) | (integer (1:MAX)) |(1setOf (integer |
| | | (1:MAX) | |
| | | rangeOfInteger |
| | | (1:MAX))) |
+-------------------+----------------------+----------------------+
| orientation- |orientation-requested-|orientation-requested-|
| requested | default | supported |
| (type2 enum) | (type2 enum) | (1setOf type2 enum) |
+-------------------+----------------------+----------------------+
| media | media-default | media-supported |
| (type3 keyword | | (type3 keyword | |(1setOf ( |
| name) | name) |type3 keyword | name))|
| | | |
| | | media-ready |
| | |(1setOf ( |
| | |type3 keyword | name))|
+-------------------+----------------------+----------------------+
| printer-resolution| printer-resolution- | printer-resolution- |
| (resolution) | default | supported |
| | (resolution) |(1setOf resolution) |
+-------------------+----------------------+----------------------+
| print-quality | print-quality-default| print-quality- |
| (type2 enum) | (type2 enum) | supported |
| | |(1setOf type2 enum) |
+-------------------+----------------------+----------------------+4.2.1 job-priority (integer(1:100)) ✨
okay so this attribute sets a priority for scheduling the Job 💅 higher number = higher priority. 1 is the lowest possible and 100 is the highest possible 🔥. Among the jobs that are ready to print, a Printer MUST print all jobs with a priority value of n before printing any with a priority value of n-1, for all n 👑.
If the Printer object supports this attribute, it MUST always support the full range from 1 to 100. No administrative restrictions are permitted. This way an end-user can always use the entire range with any Printer object 🫶. If privileged jobs are implemented outside IPP/1.1, they MUST have priorities higher than 100, rather than cutting down the range that end-users get 💀 not okay, we love a fair range.
If the client doesn't send this attribute and the Printer object supports it, the Printer object MUST use the value of its job-priority-default at job submission time. (This is different from most Job Template attributes, which get used when needed at job processing time 🧚.)
The syntax for job-priority-supported is also integer(1:100). This single integer tells you how many priority levels the Printer supports 🌈. The Printer object MUST take the value the client supplies and map it to the closest integer in a sequence of n integers spread evenly over the range from 1 to 100, using this formula:
roundToNearestInt((100x+50)/n)Here n is the value of job-priority-supported, and x goes from 0 through n-1.
Some examples, because they're so satisfying:
- if n=1, the sequence is 50
- if n=2, the sequence is 25 and 75
- if n = 3, the sequence is 17, 50 and 83
- if n = 10, the sequence is 5, 15, 25, 35, 45, 55, 65, 75, 85, and 95
- if n = 100, the sequence is 1, 2, 3, ... 100
And one more to make it click: if job-priority-supported is 10 and the client sends values from 1 to 10, the Printer object maps them to 5, then values 11 to 20 map to 15, and so on 🎀.
4.2.2 job-hold-until (type3 keyword | name (MAX)) 🍓
This attribute specifies the named time period during which the Job MUST become a candidate for printing ⏰.
Standard keyword values for named time periods are:
'no-hold': immediately, if there are not other reasons to hold the job'indefinite': - the job is held indefinitely, until a client performs a Release-Job (section 3.3.6)'day-time': during the day'evening': evening'night': night'weekend': weekend'second-shift': second-shift (after close of business)'third-shift': third-shift (after midnight)
An administrator MUST associate allowable print times with a named time period (by means outside the scope of this IPP/1.1 document). An administrator is encouraged to pick names that hint at the type of time period. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation 🌸.
If this attribute's value specifies a time period in the future, the Printer SHOULD add the 'job-hold-until-specified' value to the job's "job-state-reasons" attribute, MUST move the job to the 'pending-held' state, and MUST NOT schedule the job for printing until the specified time period arrives 🙈.
When the specified time period arrives, the Printer MUST remove the 'job-hold-until-specified' value from the job's "job-state-reason" attribute, if it's there. If no other job state reasons keep the job in the 'pending-held' state, the Printer MUST consider the job a candidate for processing by moving it to the 'pending' state ✨.
If the value of this attribute is the named value 'no-hold', or the specified time period has already started, the job MUST be a candidate for processing immediately 🔥.
If the client doesn't send this attribute and the Printer object supports it, the Printer object MUST use the value of its "job-hold-until-default" at job submission time (unlike most Job Template attributes, which get used when needed at job processing time) 🧚.
4.2.3 job-sheets (type3 keyword | name(MAX)) 📄
This attribute decides which job start/end sheet(s), if any, MUST be printed with a job 🎀.
Standard keyword values are:
'none': no job sheet is printed'standard': one or more site-specific standard job sheets are printed, e.g. a single start sheet, or both start and end sheets
An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation 💅.
The effect of this attribute on jobs with multiple documents MAY be affected by the "multiple-document-handling" job attribute (section 4.2.4), depending on the job sheet semantics 👑.
4.2.4 multiple-document-handling (type2 keyword) 🫧
This attribute only matters if a job has two or more documents 🦋. It MUST be supported with at least one value if the Printer supports multiple documents per job (see sections 3.2.4 and 3.3.1). It controls finishing operations and how one or more print-stream pages get placed into impressions and onto media sheets. When the copies attribute is greater than 1, it also controls the order in which the copies produced from the documents come out 🖨️. For the purposes of this explanations, if "a" stands for an instance of document data, then the result of processing the data in document "a" is a sequence of media sheets, written as a(*).
Standard keyword values are:
'single-document': If a Job object has multiple documents, say the document data is called a and b, then the result of processing all the document data (a and then b) MUST be treated as a single sequence of media sheets for finishing operations. That means finishing is done on the concatenation of the sequencesa(*),b(*). The Printer object MUST NOT force the data in each document instance onto a new print-stream page, nor make it start a new impression on a new media sheet. If more than one copy is made, the ordering of the sets of media sheets MUST bea(*), b(*), a(*), b(*), start on a new media sheet.'separate-documents-uncollated-copies': If a Job object has multiple documents, say the document data is called a and b, then the result of processing the data in each document instance MUST be treated as a single sequence of media sheets for finishing operations. That means the setsa(*)andb(*)each get finished separately. The Printer object MUST force each copy of the result of processing the data in a single document to start on a new media sheet. If more than one copy is made, the ordering of the sets of media sheets MUST bea(*), a(*), ..., b(*), b(*) ....'separate-documents-collated-copies': If a Job object has multiple documents, say the document data is called a and b, then the result of processing the data in each document instance MUST be treated as a single sequence of media sheets for finishing operations. That means the setsa(*)andb(*)each get finished separately. The Printer object MUST force each copy of the result of processing the data in a single document to start on a new media sheet. If more than one copy is made, the ordering of the sets of media sheets MUST bea(*), b(*), a(*), b(*), ....'single-document-new-sheet': Same as'single-document', except the Printer object MUST ensure that the first impression of each document instance in the job is placed on a new media sheet. This value lets multiple documents be stapled together with a single staple, where each document starts on a new sheet 🧷.
The 'single-document' value matches 'separate-documents-collated-copies' when it comes to the ordering of print-stream pages, but not media sheet generation. That's because 'single-document' will put the first page of the next document on the back side of a sheet if an odd number of pages has been produced so far for the job, while 'separate-documents-collated-copies' always forces the next document or document copy onto a new sheet 💀. Also, if the "finishings" attribute specifies 'staple', then with 'single-document', documents a and b get stapled together as a single document with no regard to new sheets. With 'single-document-new-sheet', documents a and b get stapled together as a single document, but document b starts on a new sheet. With 'separate-documents-uncollated-copies' and 'separate-documents-collated-copies', documents a and b get stapled separately 📎.
Note: None of these values provide a way to produce uncollated sheets within a document, i.e., where multiple copies of sheet n are produced before sheet n+1 of the same document.
How this attribute relates to the other attributes that control document processing is described in section 15.3 🌷.
4.2.5 copies (integer(1:MAX)) 🍭
This attribute specifies the number of copies to be printed 🖨️.
On lots of devices, the number of collated copies that can be supported is limited by the number of physical output bins on the device. That number can be different from the number of uncollated copies the device can support 🫶.
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4). How this attribute relates to the other attributes that control document processing is described in section 15.3 💜.
4.2.6 finishings (1setOf type2 enum) ✨
Okay bestie, finishings are the extra glam the Printer adds to every copy of every document in a Job 💅 Think stapling, punching holes, binding, the works. This attribute tells the Printer which finishing ops to do. If the Job has multiple documents, the "multiple-document-handling" attribute decides what counts as a "copy" for finishing 🦋
Here are the standard enum values, verbatim because tables don't get remixed 🎀
Value Symbolic Name and Description
'3' 'none': Perform no finishing
'4' 'staple': Bind the document(s) with one or more staples. The
exact number and placement of the staples is site-
defined.
'5' 'punch': This value indicates that holes are required in the
finished document. The exact number and placement of the
holes is site-defined The punch specification MAY be
satisfied (in a site- and implementation-specific manner)
either by drilling/punching, or by substituting pre-
drilled media.
'6' 'cover': This value is specified when it is desired to select
a non-printed (or pre-printed) cover for the document.
This does not supplant the specification of a printed
cover (on cover stock medium) by the document itself.
'7' 'bind': This value indicates that a binding is to be applied
to the document; the type and placement of the binding is
site-defined.
'8' 'saddle-stitch': Bind the document(s) with one or more
staples (wire stitches) along the middle fold. The exact
number and placement of the staples and the middle fold
is implementation and/or site-defined.
'9' 'edge-stitch': Bind the document(s) with one or more staples
(wire stitches) along one edge. The exact number and
placement of the staples is implementation and/or site-
defined.
'10'-'19' reserved for future generic finishing enum values.The next batch is more specific. These indicate a corner or an edge as if the document were a portrait document (see below) 🧚
Value Symbolic Name and Description
'20' 'staple-top-left': Bind the document(s) with one or more
staples in the top left corner.
'21' 'staple-bottom-left': Bind the document(s) with one or more
staples in the bottom left corner.
'22' 'staple-top-right': Bind the document(s) with one or more
staples in the top right corner.
'23' 'staple-bottom-right': Bind the document(s) with one or more
staples in the bottom right corner.
'24' 'edge-stitch-left': Bind the document(s) with one or more
staples (wire stitches) along the left edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'25' 'edge-stitch-top': Bind the document(s) with one or more
staples (wire stitches) along the top edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'26' 'edge-stitch-right': Bind the document(s) with one or more
staples (wire stitches) along the right edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'27' 'edge-stitch-bottom': Bind the document(s) with one or more
staples (wire stitches) along the bottom edge. The exact
number and placement of the staples is implementation
and/or site-defined.
'28' 'staple-dual-left': Bind the document(s) with two staples
(wire stitches) along the left edge assuming a portrait
document (see above).
'29' 'staple-dual-top': Bind the document(s) with two staples
(wire stitches) along the top edge assuming a portrait
document (see above).
'30' 'staple-dual-right': Bind the document(s) with two staples
(wire stitches) along the right edge assuming a portrait
document (see above).
'31' 'staple-dual-bottom': Bind the document(s) with two staples
(wire stitches) along the bottom edge assuming a portrait
document (see above).Now the rotation drama 🔄 The 'staple-xxx' values are always measured as if the document is portrait. If your doc is actually landscape or reverse-landscape, the client has to send the transformed value. For example, to put a staple in the upper left corner of a landscape document when it's held for reading, the client sends 'staple-bottom-left'. That's because landscape is a +90 degree rotation of the image relative to the media from portrait, which is anti-clockwise. Now, if you want the upper left corner of a reverse-landscape document held for reading, the client sends 'staple-top-right'. Reverse-landscape is a -90 degree rotation, which is clockwise 🌸
How the angle of each staple (vertical, horizontal, or angled) works depends on the implementation, and that can depend on the value of the attribute too 🤷♀️
Note: This attribute's effect on multi-document jobs is controlled by the "multiple-document-handling" job attribute (section 4.2.4). How it plays with the other attributes that control document processing is in section 15.3 💜
Last but not least, if the client sends 'none' with any other combo, it's the same as if only the other combo was sent. 'none' has no effect, periodt 💅
4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 🎀
This attribute picks which print-stream pages the Printer object prints for each copy of each document. Any pages that don't exist in the document(s) just get skipped, nothing gets printed for them 🌈
Here's the big rule: Ranges MUST be in ascending order, like 1-3, 5-7, 15-19, and they MUST NOT overlap. That way a non-spooling Printer object can get through the job in a single pass 🏃♀️ If the ranges are out of order or overlapping, the IPP object MUST reject the request and return the 'client-error-bad-request' status code. No exceptions, bestie 😭
Also, this attribute is about print-stream pages, not application-numbered pages. So the page numbers in the headers or footers of certain word processing apps don't count 🙈
For multi-document jobs, the "multiple-document-handling" attribute decides what counts as a "copy" for the page range. When "multiple-document-handling" is 'single-document', the Printer object MUST apply each supplied page range once to the concatenation of the print-stream pages. For example, if there are 8 documents with 10 pages each, the page-range '41:60' prints the pages in the 5th and 6th documents as a single document, and none of the other documents' pages get printed 🦋
When "multiple-document-handling" is 'separate-documents-uncollated-copies' or 'separate-documents-collated-copies', the Printer object MUST apply each supplied page range repeatedly to each document copy. Same job, but now the page-range '1:3, 10:10' prints the first 3 pages and the 10th page of each of the 8 documents in the Job, as 8 separate documents 👑
Usually a device driver figures out the exact pages to print, so you won't need this attribute. But when you're printing an archived document that's already formatted, the end user might want just a subset of pages. In that case, if page-ranges = n.m is specified, the first page printed is page n, and every page after it goes through and includes page m ✨
"page-ranges-supported" is a boolean that says whether the printer can handle page ranges. That capability can vary from one PDL to another 🌸 There is no "page-ranges-default" attribute, so if the client doesn't send "page-ranges", all pages of the document get printed. Simple as that 💖
Note: The multi-document effect is controlled by "multiple-document-handling" (section 4.2.4), and how this attribute works with the other document processing attributes is described in section 15.3 🫶
4.2.8 sides (type2 keyword) 🦋
This attribute says how print-stream pages get imposed onto the sides of a selected medium instance (an impression). Basically, it's the front-and-back layout 📄
The standard keyword values are:
'one-sided': imposes each consecutive print-stream page on the same side of consecutive media sheets.'two-sided-long-edge': imposes each consecutive pair of print-stream pages on the front and back of consecutive media sheets, so each pair reads correctly as if it's bound on the long edge. This is sometimes called'duplex'or'head-to-head'.'two-sided-short-edge': imposes each consecutive pair of print-stream pages on the front and back of consecutive media sheets, so each pair reads correctly as if it's bound on the short edge. This is sometimes called'tumble'or'head-to-toe'.'two-sided-long-edge','two-sided-short-edge','tumble', and'duplex'all work the same for portrait or landscape. However'head-to-toe'is'tumble'in portrait but'duplex'in landscape.'head-to-head'also switches between'duplex'and'tumble'when you flip between portrait and landscape modes 🔄
Note: This attribute's multi-document effect is controlled by "multiple-document-handling" (section 4.2.4), and how it interacts with the other document processing attributes is in section 15.3 💜
4.2.9 number-up (integer(1:MAX)) 🌈
This attribute says how many print-stream pages get imposed on a single side of a selected medium instance. Here's the breakdown 💅
Value Description
'1' the Printer MUST place one print-stream page on a single side
of an instance of the selected medium (MAY add some sort
of translation, scaling, or rotation).
'2' the Printer MUST place two print-stream pages on a single side
of an instance of the selected medium (MAY add some sort
of translation, scaling, or rotation).
'4' the Printer MUST place four print-stream pages on a single
side of an instance of the selected medium (MAY add some
sort of translation, scaling, or rotation).This attribute mostly handles the translation, scaling, and rotation of print-stream pages 🧚
Note: This attribute's effect on multi-document jobs is controlled by "multiple-document-handling" (section 4.2.4), and how it works with the other document processing attributes is described in section 15.3 🎀
4.2.10 orientation-requested (type2 enum) 🧭✨
okay so this attribute is how you tell the Printer which orientation you want for the printed print-stream pages 🖨️. It does NOT describe the orientation of the pages the client sent in, so keep those two straight, bestie 💅
For some document formats (like application/postscript), the desired orientation is already baked into the document data 🌸. A device driver generates that info before the print job gets submitted. Other formats (like text/plain) have no notion of desired orientation inside them at all. For those, the Printer object can attach the desired orientation to the document data after it's been submitted 🦋. It's expected that a Printer object would only support "orientations-requested" for some formats (e.g., text/plain or text/html) but not others (e.g., application/postscript). This is no different than any other Job Template attribute, since section 4.2, item 1, points out that a Printer object may support or not support any Job Template attribute based on the document format supplied by the client. Still, a special mention is made here, because it is very likely that a Printer object will support "orientation-requested" for only a subset of the supported document formats 💖
Standard enum values are:
Value Symbolic Name and Description
'3' 'portrait': The content will be imaged across the short edge
of the medium.
'4' 'landscape': The content will be imaged across the long edge
of the medium. Landscape is defined to be a rotation of
the print-stream page to be imaged by +90 degrees with
respect to the medium (i.e. anti-clockwise) from the
portrait orientation. Note: The +90 direction was
chosen because simple finishing on the long edge is the
same edge whether portrait or landscape
'5' 'reverse-landscape': The content will be imaged across the
long edge of the medium. Reverse-landscape is defined to
be a rotation of the print-stream page to be imaged by -
90 degrees with respect to the medium (i.e. clockwise)
from the portrait orientation. Note: The 'reverse-
landscape' value was added because some applications
rotate landscape -90 degrees from portrait, rather than
+90 degrees.
'6' 'reverse-portrait': The content will be imaged across the
short edge of the medium. Reverse-portrait is defined to
be a rotation of the print-stream page to be imaged by
180 degrees with respect to the medium from the portrait
orientation. Note: The 'reverse-portrait' value was
added for use with the "finishings" attribute in cases
where the opposite edge is desired for finishing a
portrait document on simple finishing devices that have
only one finishing position. Thus a 'text'/plain'
portrait document can be stapled "on the right" by a
simple finishing device as is common use with some middle
eastern languages such as Hebrew.Heads up: the effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4), and how this attribute relates to the other attributes that control document processing is described in section 15.3 📚
4.2.11 media (type3 keyword | name(MAX)) 📄🌈
this attribute identifies the medium that the Printer uses for ALL the impressions of the Job 🎀
The values for "media" can be medium-names, medium-sizes, input-trays and electronic forms, so ONE attribute covers all the media stuff ✨. If a Printer object supports a medium name as a value, that medium name implicitly selects an input-tray that contains the specified medium. If it supports a medium size, that size implicitly selects a medium name, which in turn implicitly selects an input-tray holding media of that size. If it supports an input-tray as the value, that input-tray implicitly selects whatever medium is in it at the time the job prints (this includes manual-feed input-trays 🙌). If it supports an electronic form as the value, the form implicitly selects a medium-name, which then selects an input-tray holding the medium the form specifies. The electronic form also implicitly selects an image that the Printer MUST merge with the document data as its prints each page 🫶
Standard keyword values come from ISO DPA [ISO10175], the Printer MIB [RFC1759], and ASME-Y14.1M [ASME-Y14.1M], and they're listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation 🧚
There's also an extra Printer attribute called "media-ready", and it's different from "media-supported" because its legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required 🍓. If an IPP object supports "media-supported", it NEED NOT support "media-ready" 🙈
The relationship of this attribute and the other attributes that control document processing is described in section 15.3 💜
4.2.12 printer-resolution (resolution) 🔍
this attribute identifies the resolution that the Printer uses for the Job 💫
4.2.13 print-quality (type2 enum) 🎨
this attribute specifies the print quality that the Printer uses for the Job 👑
The standard enum values are:
Value Symbolic Name and Description
'3' 'draft': lowest quality available on the printer
'4' 'normal': normal or intermediate quality on the printer
'5' 'high': highest quality available on the printer4.3 Job Description Attributes 📋🌸
the attributes in this section form the attribute group called "job-description" 🎀. The table below summarizes them. The third column shows whether an attribute is a REQUIRED attribute that MUST be supported by Printer objects. If it's not marked REQUIRED, then it is OPTIONAL 💅. The maximum size in octets for 'text' and 'name' attributes is shown in parentheses ✨
+----------------------------+----------------------+--------------+
| Attribute | Syntax | REQUIRED? |
+----------------------------+----------------------+--------------+
| job-uri | uri | REQUIRED |
+----------------------------+----------------------+--------------+
| job-id | integer(1:MAX) | REQUIRED |
+----------------------------+----------------------+--------------+
| job-printer-uri | uri | REQUIRED |
+----------------------------+----------------------+--------------+
| job-more-info | uri | |
+----------------------------+----------------------+--------------+
| job-name | name (MAX) | REQUIRED |
+----------------------------+----------------------+--------------+
| job-originating-user-name | name (MAX) | REQUIRED |
+----------------------------+----------------------+--------------+
| job-state | type1 enum | REQUIRED |
+----------------------------+----------------------+--------------+
| job-state-reasons | 1setOf type2 keyword | REQUIRED |
+----------------------------+----------------------+--------------+
| job-state-message | text (MAX) | |
+----------------------------+----------------------+--------------+
| job-detailed-status- | 1setOf text (MAX) | |
| messages | | |
+----------------------------+----------------------+--------------+
| job-document-access-errors | 1setOf text (MAX) | |
+----------------------------+----------------------+--------------+
| number-of-documents | integer (0:MAX) | |
+----------------------------+----------------------+--------------+
| output-device-assigned | name (127) | |
+----------------------------+----------------------+--------------+
| time-at-creation | integer (MIN:MAX) | REQUIRED |
+----------------------------+----------------------+--------------+
| time-at-processing | integer (MIN:MAX) | REQUIRED |
+----------------------------+----------------------+--------------+
| time-at-completed | integer (MIN:MAX) | REQUIRED |
+----------------------------+----------------------+--------------+
| job-printer-up-time | integer (1:MAX) | REQUIRED |
+----------------------------+----------------------+--------------+
| date-time-at-creation | dateTime | |
+----------------------------+----------------------+--------------+
| date-time-at-processing | dateTime | |
+----------------------------+----------------------+--------------+
| date-time-at-completed | dateTime | |
+----------------------------+----------------------+--------------+
| number-of-intervening-jobs | integer (0:MAX) | |
+----------------------------+----------------------+--------------+
| job-message-from-operator | text (127) | |
+----------------------------+----------------------+--------------+
| job-k-octets | integer (0:MAX) | |
+----------------------------+----------------------+--------------+
| job-impressions | integer (0:MAX) | |
+----------------------------+----------------------+--------------+
| job-media-sheets | integer (0:MAX) | |
+----------------------------+----------------------+--------------+
| job-k-octets-processed | integer (0:MAX) | |
+----------------------------+----------------------+--------------+
| job-impressions-completed | integer (0:MAX) | |
+----------------------------+----------------------+--------------+
| job-media-sheets-completed | integer (0:MAX) | |
+----------------------------+----------------------+--------------+
| attributes-charset | charset | REQUIRED |
+----------------------------+----------------------+--------------+
| attributes-natural-language| naturalLanguage | REQUIRED |
+----------------------------+----------------------+--------------+4.3.1. job-uri (uri) 🎀
okay so this one is REQUIRED 💖 it holds the URI for the job. When the Printer object gets a brand new job, it makes up a URI that identifies that Job, and it sends the job-uri value back as part of the response to a create request. The exact format of a Job URI is up to each implementation 🧚. If the Printer object supports more than one URI and the new Job URI is related to the Printer object's URI somehow, the Printer object uses the Printer URI the client gave in the create request. For example, if the create request came in over a secure channel, the new Job URI MUST use that same secure channel 🔒. The Printer object can guarantee this because it's the one making the Job URI, it knows its own security setup and policy, and it knows which Printer URI came in with the create request. literally the main character of security 💅
For a description of this attribute and how it connects to "job-id" and "job-printer-uri", check out section 2.4 on "Object Identity".
4.3.2. job-id (integer(1:MAX)) 🌸
this one is REQUIRED too 🫶. It holds the ID of the job. When the Printer gets a new job, it makes an ID that identifies that Job on that particular Printer, and it hands the job-id value back in the response to a create request. Zero is never used here, which keeps things compatible with SNMP index values since those can't be 0 either 🦋.
For a description of this attribute and how it connects to "job-uri" and "job-printer-uri", see section 2.4 on "Object Identity".
4.3.3. job-printer-uri (uri) 🍓
REQUIRED again (you're getting the vibe, bestie 😭). This attribute tells you which Printer object created this Job object. When a Printer creates a Job, it fills this in with the Printer object URI that was used in the create request. It's super useful when all a client has is the Job's URI and needs to figure out who made it 🕵️♀️. The client asks the creating Printer object which languages, charsets, and operations are supported for this Job.
For a description of this attribute and how it connects to "job-uri" and "job-id", see section 2.4 on "Object Identity".
4.3.4. job-more-info (uri) ✨
like "printer-more-info", this one holds a URI pointing at some resource with more info about this Job object 📄. Think an HTML page with details about the Job. cute and helpful 🌈.
4.3.5. job-name (name(MAX)) 💜
REQUIRED 🎀. This is the job's name, and it's way more human-friendly than the job-uri value. Jobs don't need unique names, so don't stress if two have the same one 🙈. The job-name attribute gets set to whatever the client sent in the job-name operation attribute of the create request (see Section 3.2.1.1). But if the client didn't send one, the Printer object MUST generate a name when it creates the Job 🛠️. The printer SHOULD make that name from the first of these sources that actually gives it a value:
- the "document-name" operation attribute of the first (or only) document,
- the "document-URI" attribute of the first (or only) document, or
- any other piece of Job specific and/or Document Content information.
4.3.6. job-originating-user-name (name(MAX)) 👑
REQUIRED (yep, sorry, it's a whole vibe) 💅. This one holds the name of the end user who sent the print job. The Printer object sets it to the most authenticated printable name it can get from the authentication service that the IPP operation came in over 🔐. Only if that's not available does the Printer object fall back to the value the client sent in the "requesting-user-name" operation attribute of the create operation (see Sections 4.4.2, 4.4.3, and 8).
Note: The Printer object needs to keep an internal originating user id of some form, usually as a credential of a principal, along with the Job object. Since that internal attribute is implementation-dependent and clients don't care about it, it isn't specified as a Job Description attribute. This originating user id gets used for authorization checks (if any) on all later operations 🫣.
4.3.7. job-state (type1 enum) 🦋
REQUIRED 💖. This attribute tells you what state the job is in right now. The IPP protocol defines seven job state values (plus the out-of-band 'unknown' value, see Section 4.1) 🌈, but implementations only have to support the states that make sense for them. In other words, a Printer only supports the job states that its output device implements and that the Printer object implementation can actually reach ✨.
Standard enum values look like this:
Values Symbolic Name and Description
'3' 'pending': The job is a candidate to start processing, but is
not yet processing.
'4' 'pending-held': The job is not a candidate for processing for
any number of reasons but will return to the 'pending'
state as soon as the reasons are no longer present. The
job's "job-state-reason" attribute MUST indicate why the
job is no longer a candidate for processing.
'5' 'processing': One or more of:
1. the job is using, or is attempting to use, one or
more purely software processes that are analyzing,
creating, or interpreting a PDL, etc.,
2. the job is using, or is attempting to use, one or
more hardware devices that are interpreting a PDL, making
marks on a medium, and/or performing finishing, such as
stapling, etc.,
3. the Printer object has made the job ready for
printing, but the output device is not yet printing it,
either because the job hasn't reached the output device
or because the job is queued in the output device or some
other spooler, awaiting the output device to print it.
When the job is in the 'processing' state, the entire job
state includes the detailed status represented in the
Printer object's "printer-state", "printer-state-
reasons", and "printer-state-message" attributes.
Implementations MAY, though they NEED NOT, include
additional values in the job's "job-state-reasons"
attribute to indicate the progress of the job, such as
adding the 'job-printing' value to indicate when the
output device is actually making marks on paper and/or
the 'processing-to-stop-point' value to indicate that the
IPP object is in the process of canceling or aborting the
job. Most implementations won't bother with this nuance.
'6' 'processing-stopped': The job has stopped while processing
for any number of reasons and will return to the
'processing' state as soon as the reasons are no longer
present.
The job's "job-state-reason" attribute MAY indicate why
the job has stopped processing. For example, if the
output device is stopped, the 'printer-stopped' value MAY
be included in the job's "job-state-reasons" attribute.
Note: When an output device is stopped, the device
usually indicates its condition in human readable form
locally at the device. A client can obtain more complete
device status remotely by querying the Printer object's
"printer-state", "printer-state-reasons" and "printer-
state-message" attributes.
'7' 'canceled': The job has been canceled by a Cancel-Job
operation and the Printer object has completed canceling
the job and all job status attributes have reached their
final values for the job. While the Printer object is
canceling the job, the job remains in its current state,
but the job's "job-state-reasons" attribute SHOULD
contain the 'processing-to-stop-point' value and one of
the 'canceled-by-user', 'canceled-by-operator', or
'canceled-at-device' value. When the job moves to the
'canceled' state, the 'processing-to-stop-point' value,
if present, MUST be removed, but the 'canceled-by-xxx',
if present, MUST remain.
'8' 'aborted': The job has been aborted by the system, usually
while the job was in the 'processing' or 'processing-
stopped' state and the Printer has completed aborting the
job and all job status attributes have reached their
final values for the job. While the Printer object is
aborting the job, the job remains in its current state,
but the job's "job-state-reasons" attribute SHOULD
contain the 'processing-to-stop-point' and 'aborted-by-
system' values. When the job moves to the 'aborted'
state, the 'processing-to-stop-point' value, if present,
MUST be removed, but the 'aborted-by-system' value, if
present, MUST remain.
'9' 'completed': The job has completed successfully or with
warnings or errors after processing and all of the job
media sheets have been successfully stacked in the
appropriate output bin(s) and all job status attributes
have reached their final values for the job. The job's
"job-state-reasons" attribute SHOULD contain one of:
'completed-successfully', 'completed-with-warnings', or
'completed-with-errors' values.The final value for this attribute MUST be one of: 'completed', 'canceled', or 'aborted' before the Printer removes the job altogether 🧹. How long jobs hang out in the 'canceled', 'aborted', and 'completed' states depends on the implementation. See section 4.3.7.2 ⏳.
Here's what the normal job state transitions look like 🗺️:
+----> canceled
/
+----> pending --------> processing ---------+------> completed
| ^ ^ \
--->+ | | +----> aborted
| v v /
+----> pending-held processing-stopped ---+Normally a job goes from left to right ➡️. Other transitions are unlikely, but they aren't forbidden 🤷♀️. The transitions to the 'canceled' state from 'pending', 'pending-held', and 'processing-stopped' aren't drawn in the diagram, so keep that in mind 💀.
Jobs reach one of the three terminal states, 'completed', 'canceled', or 'aborted', after the jobs have completed all activity, including stacking output media, after the jobs have completed all activity, and all job status attributes have reached their final values for the job ⭐.
4.3.7.1 Forwarding Servers ✨
Okay so bestie, just like every other IPP attribute 🎀, if the implementation can't figure out the correct value for this one, it SHOULD respond with the out-of-band value 'unknown' (see section 4.1) instead of guessing at some possibly-wrong value and giving the end user the wrong impression about the state of the Job object 😭. For example, if the implementation is just a gateway into some printing system that can normally get status but is temporarily unable to, then the implementation should return the 'unknown' value. However, if the implementation is a gateway to a printing system that never provides detailed status about the print job, the implementation MAY set the IPP Job object's state to 'completed', provided that it also sets the 'queued-in-device' value in the job's "job-state-reasons" attribute (see section 4.3.8) 💅.
4.3.7.2 Partitioning of Job States 🦋
This section splits the 7 job states into phases: Job Not Completed, Job Retention, Job History, and Job Removal 🌈. It also explains the 'job-restartable' value of the "job-state-reasons" Job Description attribute, which is used with the Restart-Job operation 🔥.
Job Not Completed: When a job is in the 'pending', 'pending-held', 'processing', or 'processing-stopped' states, the job is not completed 🍓.
Job Retention: When a job enters one of the three terminal job states, 'completed', 'canceled', or 'aborted', the IPP Printer object MAY "retain" the job in a restartable condition for an implementation-defined time period ✨. This time period MAY be zero seconds and MAY depend on the terminal job state. This phase is called Job Retention. While in the Job Retention phase, the job's document data is retained and a client may restart the job using the Restart-Job operation 💖. If the IPP object supports the Restart-Job operation, then it SHOULD indicate that the job is restartable by adding the 'job-restartable' value to the job's "job-state-reasons" attribute (see Section 4.3.8) during the Job Retention phase 🫶.
Job History: After the Job Retention phase expires for a job, the Printer object deletes the document data for the job and the job becomes part of the Job History 🧚. The Printer object MAY also delete any number of the job attributes. Since the job is no longer restartable, the Printer object MUST remove the 'job-restartable' value from the job's "job-state-reasons" attribute, if present 🙈.
Job Removal: After the job has remained in the Job History for an implementation-defined time, such as when the number of jobs exceeds a fixed number or after a fixed time period (which MAY be zero seconds), the IPP Printer removes the job from the system 👑.
Using the Get-Jobs operation and supplying the 'not-completed' value for the "which-jobs" operation attribute, a client is requesting jobs in the Job Not Completed phase 💜. Using the Get-Jobs operation and supplying the 'completed' value for the "which-jobs" operation attribute, a client is requesting jobs in the Job Retention and Job History phases. Using the Get-Job-Attributes operation, a client is requesting a job in any phase except Job Removal. After Job Removal, the Get-Job-Attributes and Get-Jobs operations no longer are capable of returning any information about a job 💀.
4.3.8 job-state-reasons (1setOf type2 keyword) 🌸
This REQUIRED attribute gives extra info about the job's current state, meaning info that augments the value of the job's "job-state" attribute 🫶.
These values MAY be used with any job state or states for which the reason makes sense. Some of these value definitions indicate conformance requirements, and the rest are OPTIONAL. Furthermore, when implemented, the Printer MUST return these values when the reason applies and MUST NOT return them when the reason no longer applies, whether the value of the Job's "job-state" attribute changed or not 🔥. When the Job does not have any reasons for being in its current state, the value of the Job's "job-state-reasons" attribute MUST be 'none' ✨.
Note: Values can't be added to the'job-state'attribute without impacting deployed clients that take actions upon receiving"job-state"values. The intent, though, is that additional"job-state-reasons"values can be defined and registered without impacting those deployed clients. In other words, the"job-state-reasons"attribute is meant to be extensible 🌈.
The following standard keyword values are defined. For ease of understanding, they're listed in the order the reasons are likely to occur (if implemented), starting with the 'job-incoming' value 🎀:
'none': There are no reasons for the job's current state. This state reason is semantically equivalent to"job-state-reasons"without any value, and it MUST be used when there is no other value, since the 1setOf attribute syntax requires at least one value 🍓.'job-incoming': Either (1) the Printer has accepted the Create-Job operation and is expecting additional Send-Document and/or Send-URI operations, or (2) the Printer is retrieving/accepting document data as a result of a Print-Job, Print-URI, Send-Document or Send-URI operation 📦.'job-data-insufficient': The Create-Job operation has been accepted by the Printer, but the Printer is expecting additional document data before it can move the job into the'processing'state. If a Printer starts processing before it has received all data, the Printer removes the'job-data-insufficient'reason, but the'job-incoming'remains. If a Printer starts processing after it has received all data, the Printer removes the'job-data-insufficient'reason and the'job-incoming'at the same time 🧠.'document-access-error': After accepting a Print-URI or Send-URI request, the Printer could not access one or more documents passed by reference. This reason is intended to cover any file access problem, including file does not exist and access denied because of an access control problem. The Printer MAY also indicate the document access error using the"job-document-access-errors"Job Description attribute (see section 4.3.11). Whether the Printer aborts the job and moves it to the'aborted'job state, or prints all accessible documents, moves the job to the'completed'job state, and adds the'completed-with-errors'value to the job's"job-state-reasons"attribute, depends on implementation and/or site policy. This value SHOULD be supported if the Print-URI or Send-URI operations are supported 🔗.'submission-interrupted': The job was not completely submitted for some unforeseen reason, such as: (1) the Printer has crashed before the job was closed by the client, (2) the Printer or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the Printer, or (3) the client crashed or failed to close the job before the time-out period. See section 4.4.31 😱.'job-outgoing': The Printer is transmitting the job to the output device 🚀.'job-hold-until-specified': The value of the job's"job-hold-until"attribute was specified with a time period that is still in the future. The job MUST NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the job. This value SHOULD be supported if the"job-hold-until"Job Template attribute is supported ⏳.'resources-are-not-ready': At least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical printers for which the job is a candidate. This condition MAY be detected when the job is accepted, or subsequently while the job is pending or processing, depending on implementation. The job may remain in its current state or be moved to the'pending-held'state, depending on implementation and/or job scheduling policy 🎨.'printer-stopped-partly': The value of the Printer's"printer-state-reasons"attribute contains the value'stopped-partly'🛑.'printer-stopped': The value of the Printer's"printer-state"attribute is'stopped'🥺.'job-interpreting': The job is in the'processing'state, but more specifically, the Printer is interpreting the document data 🤓.'job-queued': The job is in the'processing'state, but more specifically, the Printer has queued the document data 📥.'job-transforming': The job is in the'processing'state, but more specifically, the Printer is interpreting document data and producing another electronic representation 🦄.'job-queued-for-marker': The job is in any of the'pending-held','pending', or'processing'states, but more specifically, the Printer has completed enough processing of the document to be able to start marking, and the job is waiting for the marker. Systems that require human intervention to release jobs using the Release-Job operation put the job into the'pending-held'job state. Systems that automatically select a job to use the marker put the job into the'pending'job state, or keep the job in the'processing'job state while waiting for the marker, depending on implementation. All implementations put the job into (or back into) the'processing'state when marking does begin 🖍️.'job-printing': The output device is marking media. This value is useful for Printers which (1) spend a great deal of time processing when no marking is happening and then want to show that marking is now happening, or (2) when the job is in the process of being canceled or aborted while it remains in the'processing'state, but marking has not yet stopped, so impression or sheet counts are still increasing for the job 🖨️✨.'job-canceled-by-user': okay so this one is when the job owner cancels it with the Cancel-Job request, meaning the person whose authenticated identity matches the originating user who created the Job object 🫶. It also covers some other authorized end-user, like a member of the owner's security group. This value SHOULD be supported. 💅'job-canceled-by-operator': this is when an operator cancels the job with Cancel-Job, which means someone authenticated as having operator privileges, whether local or remote 👑. If the security policy lets anyone cancel anyone's job, this value may be used even when someone other than the owner cancels it. Under a policy like that, everyone is basically an operator for canceling jobs over IPP, lol 🙈. This value SHOULD be supported if the implementation lets people cancel jobs they don't own.'job-canceled-at-device': the job was canceled by an unidentified local user, aka someone standing at a console on the device 🖥️. This value SHOULD be supported if the implementation supports canceling jobs at the console.'aborted-by-system': this one is giving "the system pulled the plug" 💀. The job (1) is in the middle of being aborted, (2) got aborted by the system and was put in the'aborted'state, or (3) got aborted by the system and was put in the'pending-held'state, so a user or operator can manually retry it 🔁. This value SHOULD be supported.'unsupported-compression': the system aborted the job because, while trying to decompress the document-data, the Printer figured out the compression isn't one it supports 🗜️. This value MUST be supported, since"compressionsis a REQUIRED operation attribute, so it's non-negotiable bestie 🔥.'compression-error': the system aborted the job because the Printer hit an error in the document-data while decompressing it 😭. If the Printer posts this reason, the document-data already passed any tests that would have led to'unsupported-compression', so it's not that.'unsupported-document-format': the system aborted the job because the document-data's document-format isn't one the Printer supports 📄. If the client sets the document-format to'application/octet-stream', the printer MAY abort the job and post this reason, even if the format is in the "document-format-supported" printer attribute but not among the auto-sensed document-formats 🌈. This value MUST be supported, since "document-format" is a REQUIRED operation attribute.'document-format-error': the system aborted the job because the Printer ran into an error in the document-data while processing it 🫠. If the Printer posts this reason, the document-data already passed any tests that would have led to'unsupported-document-format'.'processing-to-stop-point': the requester issued a Cancel-Job operation, or the Printer object aborted the job, but the Printer is still doing some stuff on the job until a specified stop point happens or the cleanup is finished 🧹.
If the implementation needs some measurable time to cancel a job in the 'processing' or 'processing-stopped' job states, the IPP object MUST use this value to show that the Printer object is still doing stuff on the job while it stays in 'processing' or 'processing-stopped'. Once all the job's job description attributes have stopped incrementing, the Printer object moves the job from 'processing' to the 'canceled' or 'aborted' job states ✨.
'service-off-line': the Printer is offline and not accepting any jobs 📴. All'pending'jobs get put into'pending-held'. This could be true if the service's or document transform's input is impaired or broken 🔌.'job-completed-successfully': the job completed successfully, yay 🎉. This value SHOULD be supported.'job-completed-with-warnings': the job completed with warnings ⚠️. This value SHOULD be supported if the implementation detects warnings.'job-completed-with-errors': the job completed with errors, and maybe warnings too 💔. This value SHOULD be supported if the implementation detects errors.'job-restartable'- this job is kept (see section 4.3.7.2) and can currently be restarted with the Restart-Job operation (see section 3.3.7) 🔄. If'job-restartable'is a value of the job's'job-state-reasons'attribute, then the IPP object MUST accept a Restart-Job operation for that job. This value SHOULD be supported if the Restart-Job operation is supported.'queued-in-device': the job got forwarded to a device or print system that can't send status back 📤. The Printer sets the job's"job-state "attribute to'completed'and adds'queued-in-device'to the job's"job-state-reasons"attribute, which tells you the Printer has no extra info about the job and never will 🫡. See section 4.3.7.1.
4.3.9 job-state-message (text(MAX))
This attribute gives information about the "job-state" and "job-state-reasons" attributes in human-readable text 📝. If the Printer object supports this attribute, the Printer object MUST be able to generate this message in any of the natural languages listed in the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 3.1.4.1) 🌍.
The value SHOULD NOT contain extra info that isn't already in the values of the "job-state" and "job-states-reasons" attributes, like interpreter error info 🙅♀️. Otherwise, application programs might try to parse the localized text, and nobody wants that. For extra info like interpreter errors for application programs to use, or specific document access errors, new attributes with keyword values need to be developed and registered 🧩.
4.3.10 job-detailed-status-messages (1setOf text(MAX))
This attribute gives extra, detailed, technical info about the job 🔧. The Printer NEED NOT localize the messages, since they're meant for system administrators or other experienced technical people. Localization might blur the technical meaning, so it's better not to 🤓. Clients MUST NOT attempt to parse the value of this attribute. See "job-document-access-errors" (section 4.3.11) for more errors that a program can actually process 💜.
4.3.11 job-document-access-errors (1setOf text(MAX))
This attribute gives extra info about each document access error for this job that the Printer ran into after it already responded to the Print-URI or Send-URI operation and then tried to access the document(s) supplied in that operation 🔍. For errors in the protocol named by the URI scheme in the "document-uri" operation attribute, like 'http:' or 'ftp:', the error code goes in parentheses, followed by the URI. For example:
(404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdfMost Internet protocols use decimal error codes (unlike IPP), so the ASCII error code representation is in decimal 🔢.
4.3.12 number-of-documents (integer(0:MAX))
This attribute tells you how many documents are in the job 📚. That means the number of Send-Document, Send-URI, Print-Job, or Print-URI operations the Printer has accepted for this job, whether or not the document data has actually reached the Printer object yet 📦.
Implementations that support the OPTIONAL Create-Job/Send-Document/Send-URI operations SHOULD support this attribute, so clients can check the number of documents in each job 🧁.
4.3.13 output-device-assigned (name(127))
This attribute says which output device the Printer object assigned this job to 🖨️. If an output device has an embedded Printer object, the Printer object NEED NOT set this attribute. If a print server implements a Printer object, the value MAY be empty (a zero-length string), or it might not be returned until the Printer object assigns an output device to the job ⏳. This one is especially useful when a single Printer object supports multiple devices, which is called "fan-out" (see section 2.1) 🪭.
4.3.14 Event Time Job Description Attributes
This section defines the Job Description attributes that show when certain events happen for a job ⏰. If the job event hasn't happened yet, the IPP object MUST return the 'no-value' out-of-band value (see the beginning of Section 4.1) 🫥. The "time-at-xxx(integer)" attributes represent time as an integer, counting the seconds since the device was powered up (informally called "time ticks") ⏱️. The "date-time-at-xxx(dateTime)" attributes represent time as a dateTime, which is the date and time, including an offset from UTC 🌏.
To fill in these attributes, the Printer object copies the values of these Printer Description attributes at the moment the event happens:
- the value in the Printer's "printer-up-time" attribute for the "time-at-xxx(integer)" attributes
- the value in the Printer's "printer-current-time" attribute for the "date-time-at-xxx(dateTime)" attributes.
If the Printer resets its "printer-up-time" attribute to 1 on power-up (see section 4.4.29) and has persistent jobs, then it MUST change all of the jobs' "time-at-xxx(integer)" (time tick) job attributes whose events have already happened, either to:
- 0, to show that the event happened before the most recent power up, OR
- the negative of the number of seconds before the most recent power-up that the event took place, though the negative number NEED NOT match the exact number of seconds 🧮.
If a client queries a "time-at-xxx(integer)" time tick Job attribute and finds the value is 0 or negative, the client MUST assume the event happened in some life other than the Printer's current life 👻.
Note: A Printer does not change the values of any "date-time-at-xxx(dateTime)" job attributes on power-up 💅.
4.3.14.1 time-at-creation (integer(MIN:MAX))
This REQUIRED attribute shows when the Job object was created 🎂.
4.3.14.2 time-at-processing (integer(MIN:MAX))
This REQUIRED attribute shows when the Job object first started processing after the create operation or the most recent Restart-Job operation 🚀. The out-of-band 'no-value' value is returned if the job hasn't been in the 'processing' state yet (see the beginning of Section 4.1) 🫧.
4.3.14.3 time-at-completed (integer(MIN:MAX))
This REQUIRED attribute shows when the Job object completed (or was canceled or aborted) 🏁. The out-of-band 'no-value' value is returned if the job hasn't completed, been canceled, or been aborted yet (see the beginning of Section 4.1) 🌸.
4.3.14.4 job-printer-up-time (integer(1:MAX)) ⏰
This REQUIRED Job Description attribute tells you how long the Printer implementation has been up and running, in seconds 🕰️. It's basically an alias for the printer-up-time Printer Description attribute (see Section 4.4.29), so it's the same info, just from the job side 💅.
A client MAY request this attribute in a Get-Job-Attributes or Get-Jobs request and use the returned value together with other requested Event Time Job Description Attributes to show time info to a user 🫶. The lowkey clever part is that the difference between this attribute and the integer value of a time-at-xxx attribute is how many seconds ago that time-at-xxx event happened 🧠. So a client can work out the wall-clock time of that event by subtracting that difference from its own wall-clock time 🧮✨.
4.3.14.5 date-time-at-creation (dateTime) 🎂
This attribute tells you the date and time when the Job object was created 📅.
4.3.14.6 date-time-at-processing (dateTime) 🚀
This is the date and time when the Job object first started processing after the create operation or the most recent Restart-Job operation 🔄.
4.3.14.7 date-time-at-completed (dateTime) 🏁
This attribute is the date and time when the Job object completed (or was canceled or aborted) 💀.
4.3.15 number-of-intervening-jobs (integer(0:MAX)) 🚦
This attribute counts the jobs that are "ahead" of this one in the relative chronological order of expected time to complete, aka the current scheduled order 📋. For efficiency, it's only necessary to calculate this value when an operation actually requests this attribute 🙈.
4.3.16 job-message-from-operator (text(127)) 💌
This attribute holds a message from an operator, system administrator, or "intelligent" process. Its job is to explain to the end user why a job was modified or what other management action was taken on it 🫶.
4.3.17 Job Size Attributes 📏
This sub-section defines job attributes that describe the size of the job 🧁. These attributes aren't meant to be counters. They're meant to be useful routing and scheduling info, if known 🗺️. For these attributes, the Printer object may try to compute the value if it isn't supplied in the create request. Even if the client does supply a value for these three attributes in the create request, the Printer object MAY choose to change the value if it can compute a value that's more accurate than the client-supplied one 🎯. The Printer object may be able to determine the correct value for these attributes either right at job submission time or at any later point in time ⏳.
4.3.17.1 job-k-octets (integer(0:MAX)) 🍓
This attribute specifies the total size of the document(s) in K octets, i.e., in units of 1024 octets, requested to be processed in the job 📦. The value MUST be rounded up, so that a job between 1 and 1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2, etc. 🧮
This value MUST NOT include the multiplicative factors contributed by the number of copies specified by the copies attribute. That holds whether or not the device can process multiple copies without making multiple passes over the job or document data, and whether or not the output is collated 👯. So the value doesn't depend on the implementation. It shows the size of the document(s) in K octets no matter how many copies there are 💖.
This value MUST also not include the multiplicative factor due to a copies instruction embedded in the document data. If the document data actually includes replications of the document data, this value will include that replication 🪞. In other words, this value is always the size of the source document data, not a measure of the hardcopy output to be produced 📄✨.
4.3.17.2 job-impressions (integer(0:MAX)) 🖨️
This attribute specifies the total size, in number of impressions, of the document(s) being submitted (see the definition of impression in section 12.2.5) 🔍.
As with job-k-octets, this value MUST NOT include the multiplicative factors contributed by the number of copies specified by the copies attribute. That's true whether or not the device can process multiple copies without making multiple passes over the job or document data, and whether or not the output is collated 🙌. So the value doesn't depend on the implementation and reflects the size of the document(s) in impressions, no matter the number of copies 🎀.
As with job-k-octets, this value MUST also not include the multiplicative factor due to a copies instruction embedded in the document data. If the document data actually includes replications of the document data, this value will include that replication 🔁. In other words, this value is always the number of impressions in the source document data, not a measure of the number of impressions to be produced by the job 🌸.
4.3.17.3 job-media-sheets (integer(0:MAX)) 📑
This attribute specifies the total number of media sheets to be produced for this job 🗂️.
Unlike job-k-octets and job-impressions, this value MUST include the multiplicative factors contributed by the number of copies specified by the copies attribute, and by a 'number of copies' instruction embedded in the document data, if any 🧃. This difference lets the system administrator control the lower and upper bounds of both (1) the size of the document(s), using job-k-octets-supported and job-impressions-supported, and (2) the size of the job, using job-media-sheets-supported 👑.
4.3.18 Job Progress Attributes 📈
This sub-section defines job attributes that describe the progress of the job 🏃♀️. These attributes are meant to be counters. That means the value for a job that hasn't started processing MUST be 0 🥚. When the job's job-state is 'processing' or 'processing-stopped', the value is meant to hold how much of the job has been processed by the time the attributes are requested ⚡. When the job enters the 'completed', 'canceled', or 'aborted' states, these values are the final values for the job 🔒.
4.3.18.1 job-k-octets-processed (integer(0:MAX)) 🧩
This attribute specifies the total number of octets processed so far, in K octets, i.e., in units of 1024 octets 📊. The value MUST be rounded up, so that a job between 1 and 1024 octets inclusive MUST be indicated as being 1, 1025 to 2048 inclusive MUST be 2, etc. 🧮
For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value MUST be equal to the value of the job-k-octets attribute 🎯. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value MUST be a multiple of the value of the job-k-octets attribute 🔢.
4.3.18.2 job-impressions-completed (integer(0:MAX)) ✅
This job attribute specifies the number of impressions completed for the job so far 🖨️. For printing devices, impressions completed includes interpreting, marking, and stacking the output 📚.
4.3.18.3 job-media-sheets-completed (integer(0:MAX)) 🧻
This job attribute specifies the media sheets completed marking and stacking for the entire job so far, whether those sheets were processed on one side or on both 🌈.
4.3.19 attributes-charset (charset) 🔤
This REQUIRED attribute is populated using the value in the client-supplied attributes-charset attribute from the create request 💌. It identifies the charset (coded character set and encoding method) used by any Job attributes with attribute syntax 'text' and 'name' that the client supplied in the create request 🫧. See Section 3.1.4 for a complete description of the attributes-charset operation attribute 📖.
This attribute does NOT indicate the charset in which the 'text' and 'name' values are stored internally in the Job object. The internal charset is implementation-defined 🤫. The IPP object MUST convert from whatever the internal charset is to the charset being requested in an operation, as specified in Section 3.1.4 🔁✨.
4.3.20 attributes-natural-language (naturalLanguage) 🌍
This REQUIRED attribute is populated using the value in the client-supplied attributes-natural-language attribute from the create request 🗣️. It identifies the natural language used for any Job attributes with attribute syntax 'text' and 'name' that the client supplied in the create request 💬. See Section 3.1.4 for a complete description of the attributes-natural-language operation attribute 📖. See Sections 4.1.1.2 and 4.1.2.2 for how a Natural Language Override may be supplied explicitly for each 'text' and 'name' attribute value that differs from the value identified by the attributes-natural-language attribute 🎀.
4.4. Printer Description Attributes ✨
okay bestie, these attributes all live together in the attribute group called printer-description 🧚 the table below is your cheat sheet: it shows each attribute, its syntax, and whether it's REQUIRED for a Printer object to support 💅 anything not marked REQUIRED is OPTIONAL, so no stress 🫶 the max size in octets for text and name attributes is written in parentheses right after the type 🎀
Note: how an Administrator sets these is totally outside the scope of this IPP/1.1 document 🙈
+----------------------------+---------------------------+-----------+
| Attribute | Syntax | REQUIRED? |
+----------------------------+---------------------------+-----------+
| printer-uri-supported | 1setOf uri | REQUIRED |
+----------------------------+---------------------------+-----------+
| uri-security-supported | 1setOf type2 keyword | REQUIRED |
+----------------------------+---------------------------+-----------+
| uri-authentication- | 1setOf type2 keyword | REQUIRED |
| supported | | |
+----------------------------+---------------------------+-----------+
| printer-name | name (127) | REQUIRED |
+----------------------------+---------------------------+-----------+
| printer-location | text (127) | |
+----------------------------+---------------------------+-----------+
| printer-info | text (127) | |
+----------------------------+---------------------------+-----------+
| printer-more-info | uri | |
+----------------------------+---------------------------+-----------+
| printer-driver-installer | uri | |
+----------------------------+---------------------------+-----------+
| printer-make-and-model | text (127) | |
+----------------------------+---------------------------+-----------+
| printer-more-info- | uri | |
| manufacturer | | |
+----------------------------+---------------------------+-----------+
| printer-state | type1 enum | REQUIRED |
+----------------------------+---------------------------+-----------+
| printer-state-reasons | 1setOf type2 keyword | REQUIRED |
+----------------------------+---------------------------+-----------+
| printer-state-message | text (MAX) | |
+----------------------------+---------------------------+-----------+
| ipp-versions-supported | 1setOf type2 keyword | REQUIRED |
+----------------------------+---------------------------+-----------+
| operations-supported | 1setOf type2 enum | REQUIRED |
+----------------------------+---------------------------+-----------+
| multiple-document-jobs- | boolean | |
| supported | | |
+----------------------------+---------------------------+-----------+
| charset-configured | charset | REQUIRED |
+----------------------------+---------------------------+-----------+
| charset-supported | 1setOf charset | REQUIRED |
+----------------------------+---------------------------+-----------+
| natural-language-configured| naturalLanguage | REQUIRED |
+----------------------------+---------------------------+-----------+
| generated-natural-language-| 1setOf naturalLanguage | REQUIRED |
| supported | | |
+----------------------------+---------------------------+-----------+
| document-format-default | mimeMediaType | REQUIRED |
+----------------------------+---------------------------+-----------+
| document-format-supported | 1setOf mimeMediaType | REQUIRED |
+----------------------------+---------------------------+-----------+
| printer-is-accepting-jobs | boolean | REQUIRED |
+----------------------------+---------------------------+-----------+
| queued-job-count | integer (0:MAX) | REQUIRED |
+----------------------------+---------------------------+-----------+
| printer-message-from- | text (127) | |
| operator | | |
+----------------------------+---------------------------+-----------+
| color-supported | boolean | |
+----------------------------+---------------------------+-----------+
| reference-uri-schemes- | 1setOf uriScheme | |
| supported | | |
+----------------------------+---------------------------+-----------+
| pdl-override-supported | type2 keyword | REQUIRED |
+----------------------------+---------------------------+-----------+
| printer-up-time | integer (1:MAX) | REQUIRED |
+----------------------------+---------------------------+-----------+
| printer-current-time | dateTime | |
+----------------------------+---------------------------+-----------+
| multiple-operation-time-out| integer (1:MAX) | |
+----------------------------+---------------------------+-----------+
| compression-supported | 1setOf type3 keyword | REQUIRED |
+----------------------------+---------------------------+-----------+
| job-k-octets-supported | rangeOfInteger (0:MAX) | |
+----------------------------+---------------------------+-----------+
| job-impressions-supported | rangeOfInteger (0:MAX) | |
+----------------------------+---------------------------+-----------+
| job-media-sheets-supported | rangeOfInteger (0:MAX) | |
+----------------------------+---------------------------+-----------+
| pages-per-minute | integer(0:MAX) | |
+----------------------------+---------------------------+-----------+
| pages-per-minute-color | integer(0:MAX) | |
+----------------------------+---------------------------+-----------+4.4.1. printer-uri-supported (1setOf uri)
this one is REQUIRED 💖 a Printer object needs at least one URI, and it OPTIONALLY can have more than one 🦋 an administrator works out the URI(s) and sets this attribute to hold them, using some means that's outside the scope of this IPP/1.1 document 💅 the precise format of the URI is implementation dependent and depends on the protocol ✨ the REQUIRED companions are uri-security-supported and uri-authentication-supported (the next two sections, no cap) 🌸 check out section 2.4 for Printer object identity and section 8.2 for security and URIs if you want the deep dive 🔥
4.4.2. uri-authentication-supported (1setOf type2 keyword)
this REQUIRED Printer attribute MUST have the same cardinality (same number of values) as printer-uri-supported 🙈 that's a strict rule, but it's iconic for consistency 💜 this attribute names the Client Authentication mechanism for each URI listed in printer-uri-supported 🔐 the Printer object uses that mechanism to identify the authenticated user (see section 8.3) 🧚 the "i th" value here lines up with the "i th" value in printer-uri-supported, and it describes the authentication mechanisms the Printer uses when accessed via that URI 🦋 see [RFC2910] for more details on Client Authentication 💖
The following standard keyword values are defined:
'none': there is no authentication mechanism tied to the URI. The Printer object assumes the authenticated user is "anonymous" 👻'requesting-user-name': when a client performs an operation whose target is the associated URI, the Printer object assumes the authenticated user is specified by therequesting-user-nameOperation attribute (see section 8.3). If therequesting-user-nameattribute is absent in a request, the Printer object assumes the authenticated user is "anonymous" 🫶'basic': when a client performs an operation whose target is the associated URI, the Printer object challenges the client with HTTP basic authentication [RFC2617]. The Printer object assumes the authenticated user is the name received via the basic authentication mechanism 🌈'digest': when a client performs an operation whose target is the associated URI, the Printer object challenges the client with HTTP digest authentication [RFC2617]. The Printer object assumes the authenticated user is the name received via the digest authentication mechanism ✨'certificate': when a client performs an operation whose target is the associated URI, the Printer object expects the client to provide a certificate. The Printer object assumes the authenticated user is the textual name contained within the certificate 🎀
4.4.3 uri-security-supported (1setOf type2 keyword) 🔐
okay so this one is a REQUIRED Printer attribute 💅 and it MUST have the same cardinality as "printer-uri-supported", meaning the same number of values 🦋 it's basically a matching buddy list. The "i-th" value in "uri-security-supported" lines up with the "i-th" value in "printer-uri-supported" and tells you the security mechanisms used to reach the Printer object through that URI ✨ for more on security mechanisms, check [RFC2910] 🎀
The standard keyword values are:
'none': no secure communication channel protocols are in use for the given URI 🙈'ssl3': SSL3 [SSL] is the secure communications channel protocol in use for the given URI 🔒'tls': TLS [RFC2246] is the secure communications channel protocol in use for the given URI 💜
this attribute is orthogonal to Client Authentication, which means it's a totally separate thing 🌸 specifically, 'none' does NOT exclude Client Authentication. see section 4.4.2 for that side of things 💖
let's look at an example 👀 an admin sets up one Printer object like this:
"printer-uri-supported": 'xxx://acme.com/open-use-printer',
'xxx://acme.com/restricted-use-printer',
'xxx://acme.com/private-printer'
"uri-authentication-supported": 'none', 'digest', 'basic'
"uri-security-supported": 'none', 'none', 'tls'quick note: 'xxx' is not a valid scheme 🙃 it's just a placeholder. check the IPP/1.1 "Transport and Encoding" document [RFC2910] for the actual URI schemes to use in object target attributes ✨
so this single Printer object has three URIs, and each one is its own little main character 👑
- for the first one,
'xxx://acme.com/open-use-printer', the'none'in "uri-security-supported" means there's no secure channel protocol configured to run under HTTP 🍓 and the'none'in "uri-authentication-supported" means everyone is 'anonymous' 🫶 no challenge happens, and the Printer will ignore "requesting-user-name" 🧚 - for the second one,
'xxx://acme.com/restricted-use-printer', the'none'in "uri-security-supported" again means no secure channel protocol is configured under HTTP 🌈 the'digest'in "uri-authentication-supported" means the Printer will issue a challenge and will use the name supplied by the digest mechanism to figure out the authenticated user (see section 8.3) 🔥 - for the third one,
'xxx://acme.com/private-printer', the'tls'in "uri-security-supported" means TLS is securing the channel 🔐 the client SHOULD be ready to use TLS framing to negotiate an acceptable ciphersuite for talking to the Printer object 💅 the name kinda implies a secure channel, but the'tls'value makes it explicit, so the client doesn't have to guess from naming conventions or parse the URI to figure out which security is implied ✨ the'basic'in "uri-authentication-supported" means the Printer will issue a challenge and will use the name supplied by the digest mechanism to determine the authenticated user (see section 8.3) 🦋 and because this challenge happens inside a tls session, the channel is secure 🫶
it's expected that a lot of IPP Printer objects will only support one channel (TLS or not) and only one authentication mechanism 🌸 those Printer objects only list one URI in "printer-uri-supported" 💖 but no matter how the Printer object is configured, whether it has one URI or several, a client MUST supply only one URI in the target "printer-uri" operation attribute 🚨
4.4.4 printer-name (name(127)) 🎀
this REQUIRED Printer attribute holds the name of the Printer object 💖 it's way more end-user friendly than a URI 🌸 an administrator picks the printer's name and sets this attribute to it 🧚 the name may be the last part of the printer's URI, or it may be totally unrelated 🙈 and in non-US-English locales, a name may contain characters that aren't allowed in a URI 🌍 ngl that's a whole vibe 💅
4.4.5 printer-location (text(127)) 📍
this Printer attribute tells you where the device is located 🗺️ it could be something like: "in Room 123A, second floor of building XYZ" 🏢
4.4.6 printer-info (text(127)) 📝
this Printer attribute holds descriptive info about this Printer object ✨ examples from the original include: "This printer can be used for printing color transparencies for HR presentations", or "Out of courtesy for others, please print only small (1-5 page) jobs at this printer", or even "This printer is going away on July 1, 1997, please find a new printer" 😭 the 1997 one is a whole time capsule 🕰️
4.4.7 printer-more-info (uri) 🌐
this Printer attribute contains a URI for getting more info about this specific Printer object 🦋 for example, it could be an HTTP type URI pointing to an HTML page a Web Browser can open 💻 the info is meant for end users 🫶 features outside the scope of IPP can be reached from this URI too 🔥 the info is supposed to be specific to this printer instance and to site-specific services (like job pricing, services offered, end user assistance) 🍓 the device manufacturer may initially fill this one in 💜
4.4.8 printer-driver-installer (uri) 🛠️
this Printer attribute contains a URI used to locate the driver installer for this Printer object 🤖 it's meant for automata to consume 🧚 how print driver installation actually works is outside the scope of this IPP/1.1 document 🙃 the device manufacturer may initially fill this one in too 🌸
4.4.9 printer-make-and-model (text(127)) 🖨️
this Printer attribute identifies the make and model of the device ✨ the device manufacturer may initially populate it 💖
4.4.10 printer-more-info-manufacturer (uri) 🏭
this Printer attribute contains a URI for getting more info about this type of device 🌈 the info is for end users 🫶 features outside the scope of IPP can be reached from this URI, like latest firmware, upgrades, print drivers, optional features available, or details on color support 🔥 the info is meant to be germane to this printer without caring about site-specific modifications or services 💅 the device manufacturer may initially populate this one too 🍓
4.4.11 printer-state (type1 enum) 🚦
this REQUIRED Printer attribute tells you the current state of the device 💜 the "printer-state reasons" attribute sits alongside it and gives more detailed info about the Printer in whatever state it's in 🎀
a Printer object only needs to update this attribute before responding to an operation that asks for it 🧚 the Printer object NEED NOT update it continually, since asynchronous event notification is not part of IPP/1.1 🙈 and a Printer NEED NOT implement every value if they don't apply to its implementation 🌸
the standard enum values are:
Value Symbolic Name and Description
'3' 'idle': Indicates that new jobs can start processing without
waiting.
'4' 'processing': Indicates that jobs are processing; new jobs
will wait before processing.
'5' 'stopped': Indicates that no jobs can be processed and
intervention is required.values of "printer-state-reasons", like 'spool-area-full' and 'stopped-partly', MAY be used to give extra info 🦋 it's like the printer's little explanation note 📎
4.4.12 printer-state-reasons (1setOf type2 keyword) 🎀
This REQUIRED Printer attribute is the tea on what's actually going on with the device 🍓 It gives extra detail about the device's state. Some of these value definitions are conformance requirements, and the rest are OPTIONAL 💅
Each keyword value MAY have a suffix that shows how severe it is 🔥 There are three levels: report (least severe), warning, and error (most severe).
-report: This suffix means the reason is a "report". An implementation may choose to omit some or all reports. Some reports get more specific about the printer state, and others are a precursor to a warning. A report MUST contain nothing that could affect the printed output.-warning: This suffix means the reason is a "warning". An implementation may choose to omit some or all warnings. Warnings are a precursor to an error. A warning MUST contain nothing that prevents a job from completing, though in some cases the output may be of lower quality.-error: This suffix means the reason is an "error" 😭 An implementation MUST include all errors. If this attribute contains one or more errors, the printer MUST be in the stopped state.
If the implementation doesn't add any of the three suffixes, all parties MUST assume that the reason is an "error" 🙈
If a Printer object controls more than one output device, each value of this attribute MAY apply to one or more of those devices. An error on one output device that doesn't stop the Printer object as a whole MAY appear as a warning in the Printer's "printer-state-reasons attribute". If the "printer-state" for such a Printer is 'stopped', then there MUST be an error reason among the values in the "printer-state-reasons" attribute. Main character energy, honestly 👑
The following standard keyword values are defined ✨
'other': The device has detected an error that isn't listed in this document.'none': There are no reasons. This state reason is semantically equivalent to "printer-state-reasons" without any value, and it MUST be used, since the 1setOf attribute syntax requires at least one value.'media-needed': A tray has run out of media.'media-jam': The device has a media jam.'moving-to-paused': Someone has paused the Printer object using the Pause-Printer operation (see section 3.2.7) or some other means, but the device(s) are taking an appreciable time to stop. Later, when all output has stopped, the "printer-state" becomes'stopped', and the'paused'value replaces the'moving-to-paused'value in the "printer-state-reasons" attribute. This value MUST be supported if the Pause-Printer operation is supported and the implementation takes significant time to pause a device in certain circumstances 🌸'paused': Someone has paused the Printer object using the Pause-Printer operation (see section 3.2.7) or some other means, and the Printer object's "printer-state" is'stopped'. In this state, a Printer MUST NOT produce printed output, but it MUST perform other operations requested by a client. If a Printer had been printing a job when it was paused, the Printer MUST resume printing that job when it's no longer paused and leave no evidence in the printed output of such a pause 🦋 This value MUST be supported if the Pause-Printer operation is supported.'shutdown': Someone has removed a Printer object from service, and the device may be powered down or physically removed. In this state, a Printer object MUST NOT produce printed output, and unless the Printer object is realized by a print server that is still active, the Printer object MUST perform no other operations requested by a client, including returning this value. If a Printer object had been printing a job when it was shut down, the Printer NEED NOT resume printing that job when it's no longer shut down. If the Printer does resume printing such a job, it may leave evidence in the printed output of that shutdown, e.g. the part printed before the shutdown may be printed a second time after it 💀'connecting-to-device': The Printer object has scheduled a job on the output device and is in the process of connecting to a shared network output device. It might not be able to actually start printing the job for an arbitrarily long time, depending on how much other servers on the network are using the output device 🧚'timed-out': The server was able to connect to the output device (or is always connected), but couldn't get a response from the output device.'stopping': The Printer object is in the process of stopping the device and will be stopped in a while. When the device is stopped, the Printer object will change its state to'stopped'. The'stopping-warning'reason is never an error, even for a Printer with a single output device. When an output device stops accepting jobs, the Printer will have this reason while the output device finishes printing 🫶'stopped-partly': When a Printer object controls more than one output device, this reason indicates that one or more output devices are stopped. If the reason is a report, fewer than half of the output devices are stopped. If the reason is a warning, fewer than all of the output devices are stopped.'toner-low': The device is low on toner.'toner-empty': The device is out of toner.'spool-area-full': The limit of persistent storage allocated for spooling has been reached, so the Printer is temporarily unable to accept more jobs. The Printer will remove this value when it can accept more jobs again. This value SHOULD be used by a non-spooling Printer that only accepts one or a small number of jobs at a time, or by a spooling Printer that has filled its spool space 🎀'cover-open': One or more covers on the device are open.'interlock-open': One or more interlock devices on the printer are unlocked.'door-open': One or more doors on the device are open.'input-tray-missing': One or more input trays are not in the device.'media-low': At least one input tray is low on media.'media-empty': At least one input tray is empty.'output-tray-missing': One or more output trays are not in the device.'output-area-almost-full': One or more output areas are almost full (e.g. tray, stacker, collator).'output-area-full': One or more output areas are full (e.g. tray, stacker, collator).'marker-supply-low': The device is low on at least one marker supply (e.g. toner, ink, ribbon).'marker-supply-empty': The device is out of at least one marker supply (e.g. toner, ink, ribbon).'marker-waste-almost-full': The device's marker supply waste receptacle is almost full.'marker-waste-full': The device's marker supply waste receptacle is full.'fuser-over-temp': The fuser temperature is above normal.'fuser-under-temp': The fuser temperature is below normal.'opc-near-eol': The optical photo conductor is near end of life.'opc-life-over': The optical photo conductor is no longer functioning.'developer-low': The device is low on developer.'developer-empty': The device is out of developer.'interpreter-resource-unavailable': An interpreter resource is unavailable (i.e. font, form).
4.4.13 printer-state-message (text(MAX)) 💬
This Printer attribute specifies information about the "printer-state" and "printer-state-reasons" attributes in human-readable text. If the Printer object supports this attribute, the Printer object MUST be able to generate this message in any of the natural languages identified by the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 3.1.4.1) 🌈
4.4.14 ipp-versions-supported (1setOf type2 keyword) 🧁
This REQUIRED attribute identifies the IPP protocol version(s) that this Printer supports, including major and minor versions. That means the version numbers for which this Printer implementation meets the conformance requirements. For version number validation, the Printer matches the (two-octet binary) "version-number" parameter supplied by the client in each request (see sections 3.1.1 and 3.1.8) with the (US-ASCII) keyword values of this attribute 🔍
The following standard keyword values are defined ✨
'1.0': Meets the conformance requirement of IPP version 1.0 as specified in RFC 2566 [RFC2566] and RFC 2565 [RFC2565], including any extensions registered according to Section 6 and any extension defined in this version or any future version of the IPP "Model and Semantics" document or the IPP "Encoding and Transport" document, following the rules (if any) when the "version-number" parameter is'1.0'.'1.1': Meets the conformance requirement of IPP version 1.1 as specified in this document and [RFC2910], including any extensions registered according to Section 6 and any extension defined in any future versions of the IPP "Model and Semantics" document or the IPP Encoding and Transport document, following the rules (if any) when the "version-number" parameter is'1.1'. 🦋
4.4.15 operations-supported (1setOf type2 enum) 🚀
This REQUIRED Printer attribute specifies the set of supported operations for this Printer object and its contained Job objects.
This attribute is encoded as any other enum attribute syntax according to [RFC2910] as 32-bits. However, all 32-bit enum values for this attribute MUST NOT exceed 0x00008FFF, because these same values are also passed in two octets in the "operation-id" parameter (see section 3.1.1) in each Protocol request, with the two high-order octets omitted, to indicate the operation being performed [RFC2910] 🙈
The following standard enum and "operation-id" (see section 3.1.2) values are defined 👑
Value Operation Name
----------------- -------------------------------------
0x0000 reserved, not used
0x0001 reserved, not used
0x0002 Print-Job
0x0003 Print-URI
0x0004 Validate-Job
0x0005 Create-Job
0x0006 Send-Document
0x0007 Send-URI
0x0008 Cancel-Job
0x0009 Get-Job-Attributes
0x000A Get-Jobs
0x000B Get-Printer-Attributes
0x000C Hold-Job
0x000D Release-Job
0x000E Restart-Job
0x000F reserved for a future operation
0x0010 Pause-Printer
0x0011 Resume-Printer
0x0012 Purge-Jobs
0x0013-0x3FFF reserved for future IETF standards track
operations (see section 6.4)
0x4000-0x8FFF reserved for vendor extensions (see section 6.4)4.4.16. multiple-document-jobs-supported (boolean) 📄✨
okay so this Printer attribute tells you whether the printer can handle more than one document per job 💅 that means more than one Send-Document or Send-Data operation carrying document data. and if the printer supports Create-Job and Send-Document (see Section 3.2.4 and 3.3.1), it MUST support this attribute. no skipping it, bestie 🫶
4.4.17. charset-configured (charset) 🔤
this one is REQUIRED 💖 and it tells you which charset the Printer object has been set up to use for the 'text' and 'name' Printer attributes that the operator, system administrator, or manufacturer set. so we're talking about printer-name (name), printer-location (text), printer-info (text), and printer-make-and-model (text) 🎀 which means the value of charset-configured MUST also be one of the values in charset-supported 🔥
4.4.18. charset-supported (1setOf charset) 🌈
also REQUIRED 🙌 this is the whole set of charsets that the Printer and its Job objects support for attributes with 'text' and 'name' syntax. at minimum, utf-8 MUST be in there, because IPP objects MUST support the UTF-8 [RFC2279] charset. no exceptions, it's giving main character 👑
here's the vibe: if a Printer object supports a charset, then for every 'text' and 'name' attribute the IPP object MUST (1) accept that charset in requests and return it in responses as needed. 🦋
if the printer supports more charsets than UTF-8, the IPP object MUST do charset conversion between them, as described in Section 3.1.4.2 ✨
4.4.19. natural-language-configured (naturalLanguage) 🗣️
REQUIRED again 💅 this is the natural language the Printer object has been configured to use for those same 'text' and 'name' attributes (printer-name, printer-location, printer-info, and printer-make-and-model) that the operator, system administrator, or manufacturer set 🌸
when the printer returns these attributes, it MAY return them in this configured natural language, instead of the one the client asked for in the attributes-natural-language operation attribute. the printer can do this even though it's not the client's pick 🙈 For the OPTIONAL multiple natural language support, see Section 3.1.4.1. and yeah, the value of natural-language-configured MUST also be one of the values in generated-natural-language-supported 💜
4.4.20. generated-natural-language-supported (1setOf naturalLanguage) 🌍
this REQUIRED attribute lists the natural languages the Printer object and its Job objects support for 'text' and 'name' attributes 🫧 which languages those are depends on the implementation and/or configuration.
here's the big difference from charsets: IPP objects MUST accept requests in any natural language or any Natural Language Override, whether or not that language is supported 🦄
if a Printer object supports a natural language, then for anything it generates messages for (the job-state-message and printer-state-message attributes, plus Operation Messages in operation responses, see Section 3.1.5), the Printer and Job objects MUST be able to produce those messages in any of the Printer's supported natural languages 🍓 see section 3.1.4 for the definition of 'text' and 'name' attributes in operation requests and responses.
Note: A Printer object that supports multiple natural languages often has separate message catalogs, one for each natural language it supports. 📚
4.4.21. document-format-default (mimeMediaType) 📎
REQUIRED 🎀 this is the document format the Printer object has been configured to assume when the client doesn't supply a document-format operation attribute in any operation request that carries document data. the standard values are Internet Media types (sometimes called MIME types) 💖 for the full scoop, check the 'mimeMediaType' attribute syntax in Section 4.1.9 🧚
4.4.22. document-format-supported (1setOf mimeMediaType) 📑
REQUIRED ✨ this is the set of document formats that the Printer object and its Job objects can support. for more details, see the 'mimeMediaType' attribute syntax in Section 4.1.9 🦋
4.4.23. printer-is-accepting-jobs (boolean) 🚪
REQUIRED 💅 this one tells you whether the printer can take jobs right now, meaning it's accepting Print-Job, Print-URI, and Create-Job requests 🫶
if the value is 'true', the printer is accepting jobs. if it's 'false', the Printer object is rejecting any jobs submitted to it, and it returns the 'server-error-not-accepting-jobs' status code. 🙅♀️
this value is independent of printer-state and printer-state-reasons because it's about future jobs, not the current one 🔮 so when it's 'false', the printer rejects jobs even if printer-state is 'idle'. and when it's 'true', the printer accepts jobs even if printer-state is 'stopped'. wild, right? 💀
4.4.24. queued-job-count (integer(0:MAX)) 🔢
REQUIRED 💖 this is a count of the jobs that are 'pending', 'processing', 'pending-held', or 'processing-stopped' ✨ the Printer object sets it itself.
4.4.25. printer-message-from-operator (text(127)) 📣
this Printer attribute carries a message from an operator, system administrator, or "intelligent" process 🧠 it's there to tell end users what's going on with the printer, like why it's unavailable or when it's expected back 🌸
4.4.26. color-supported (boolean) 🌈
this Printer attribute says whether the device can do any kind of color printing at all, highlight color included 🎨 all the document instructions about color are embedded in the document PDL, since none of them are external IPP attributes in IPP/1.1 📄
Note: end-users can find out the nature and details of the color support by querying the printer-more-info-manufacturer Printer attribute. 🫶
4.4.27. reference-uri-schemes-supported (1setOf uriScheme) 🔗
this Printer attribute lists which URI schemes can be used in the document-uri operation attribute of the Print-URI or Send-URI operation 🦋 if a Printer object supports these optional operations, it MUST support the reference-uri-schemes-supported Printer attribute with at least this schemed URI value:
'ftp': The Printer object will use an FTP 'get' operation as
defined in RFC 2228 [RFC2228] using FTP URLs as defined by
[RFC2396] and [RFC2316].the Printer object MAY OPTIONALLY support other URI schemes too (see section 4.1.6) 💜
4.4.28. pdl-override-supported (type2 keyword) 🛠️
REQUIRED 💅 this one shows whether a Printer implementation tries to override the instructions in the document data with IPP attributes or doesn't ✨ it takes one of these keyword values:
- 'attempted': the Printer object tries to make the IPP attribute values win over the instructions embedded in the document data, but there's no guarantee 🤞
- 'not-attempted': the Printer object makes no attempt to make the IPP attribute values win over embedded instructions 🙅♀️
Section 15 has the full rundown on how this attribute interacts with the other IPP attributes, especially ipp-attribute-fidelity 🎀
4.4.29. printer-up-time (integer(1:MAX)) ⏰
REQUIRED 💖 this is how long (in seconds) this Printer instance has been up and running 🧚 the value goes up steadily, starting from 1 when the Printer object starts up (initialized, booted, etc.). the value feeds the Event Time Job Description attributes time-at-creation, time-at-processing, and time-at-completed (see Section 4.3.14) ⭐
if the Printer object goes down at some value 'n' and comes back up, the implementation MAY:
- know how long it was down, and pick up at some value greater than 'n', or
- restart from 1.
so basically, if the device or devices the Printer object represents get restarted or power cycled, the Printer object MAY keep counting or MAY reset to 1, depending on the implementation 🔄 but if the Printer object software stops running and restarts without knowing the last printer-up-time value, the implementation MUST reset this value to 1 🚨 and if it resets and the Printer has persistent jobs, the Printer MUST reset the "time-at-xxx(integer)" Event Time Job Description attributes according to Section 4.3.14 😭 an implementation MAY use both alternatives, depending on whether it's a warm or cold start 🌈
4.4.30. printer-current-time (dateTime) 🕰️
this Printer attribute is the current date and time 🕐 it populates the Event Time Job Description attributes date-time-at-creation, date-time-at-processing, and date-time-at-completed (see Section 4.3.14) 🫶
the date and time is a "best efforts basis" thing and doesn't have to be super precise to work in practice 🙈 the Printer implementation sets it by getting the date and time through some implementation-dependent means, like a network time server, being initialized at manufacture, or an administrator setting it. see [IPP-IIG] for examples 🧚 if the implementation supports this attribute and knows it hasn't been set yet, it MUST return the out-of-band 'no-value' meaning not configured for it. see the beginning of section 4.1 💅
the time zone of this attribute NEED NOT be the time zone used by people near the Printer object or device 🌍 the client MUST NOT expect any received 'dateTime' value to be in the client's time zone or in the time zone of people near the printer 🙅♀️
the client SHOULD display any dateTime attributes in client local time, by converting the 'dateTime' value from the server into the client's time zone 💖 that's better than using the time zone the Printer returns in attributes that use the 'dateTime' syntax ✨
4.4.31. multiple-operation-time-out (integer(1:MAX)) ⏳
this Printer attribute identifies the minimum time (in seconds) the Printer object waits for more Send-Document or Send-URI operations to follow a still-open Job object, before it takes any recovery actions, like the ones in Section 3.3.1 🫧 if the Printer object supports the Create-Job and Send-Document operations (see Section 3.2.4 and 3.3.1), it MUST support this attribute 🔥
it is RECOMMENDED that vendors supply a value for this attribute between 60 and 240 seconds 🍓 an implementation MAY let a system administrator set this attribute (by means outside this IPP/1.1 document), and if so, the system administrator MAY be able to set values outside that range 🎀
4.4.32 compression-supported (1setOf type3 keyword) 🗜️
Okay so this one is a REQUIRED Printer attribute, no cap, and it lists which compression algorithms the printer can handle for the document data 📦. Compression only applies to the document data. It does NOT apply to the encoding of the IPP operation itself, so don't mix those up, bestie 🙈. The values listed here are what get used to check the client's "compression" operation attributes in Print-Job, Send-Document, and Send-URI requests ✨.
Standard keyword values are:
none: no compression is used 🫧deflate: ZIP (public domain inflate/deflate) compression technology in RFC 1951 [RFC1951] 🗜️gzip: GNU zip compression technology described in RFC 1952 [RFC1952] 🎀compress: UNIX compression technology in RFC 1977 [RFC1977] 🦋
4.4.33 job-k-octets-supported (rangeOfInteger(0:MAX)) 🌸
This Printer attribute gives the lower and upper bounds for total job sizes, measured in K octets (so units of 1024 octets) 💅. The supported values are used to validate the client's "job-k-octets" operation attributes in create requests. The matching job description attribute, "job-k-octets", is defined in section 4.3.17.1 🧚.
4.4.34 job-impressions-supported (rangeOfInteger(0:MAX)) 🖨️
This Printer attribute gives the lower and upper bounds for the number of impressions per job ✨. The supported values are used to validate the client's "job-impressions" operation attributes in create requests. The corresponding job description attribute, "job-impressions", is defined in section 4.3.17.2 💖.
4.4.35 job-media-sheets-supported (rangeOfInteger(0:MAX)) 📄
This Printer attribute gives the lower and upper bounds for the number of media sheets per job 🫶. The supported values are used to validate the client's "job-media-sheets" operation attributes in create requests. The corresponding Job attribute, "job-media-sheets", is defined in section 4.3.17.3 🌈.
4.4.36 pages-per-minute (integer(0:MAX)) ⏱️
This Printer attribute gives the nominal number of pages per minute, rounded to the nearest whole number, that this printer can produce (for example, simplex, black-and-white) 📑. It's informative, NOT a service guarantee, so don't come for the printer if it's off, periodt 💀. Generally, it's the number you'd see in the marketing literature for the device 👑.
A value of 0 means the device takes more than two minutes to process a page 🐢.
4.4.37 pages-per-minute-color (integer(0:MAX)) 🌈
This Printer attribute gives the nominal number of pages per minute, rounded to the nearest whole number, that this printer can produce when printing in color (for example, simplex, color) 🎨. For this attribute, "color" means the same thing it does for "color-supported", so the device can do any kind of color printing at all, including highlight color ✨. Like the one above, it's informative, not a service guarantee. Usually it's the number from the marketing literature about the device's color abilities 💅.
A value of 0 means the device takes more than two minutes to process a page 🐌.
If a color device has several color modes, it MAY use the pages-per-minute value for this attribute that matches the mode giving the highest number 🦋.
Black and white only printers MUST NOT support this attribute 🙅♀️. If this attribute is present, then the "color-supported" Printer description attribute MUST be present and have a 'true' value 💖.
The values of these two attributes returned by the Get-Printer-Attributes operation MAY be affected by the "document-format" attribute the client supplied in the Get-Printer-Attributes request 🧠. In other words, the implementation MAY have different speeds depending on the document format it's processing 🏃♀️. See section 3.2.5.1 Get-Printer-Attributes 🔗.
5. Conformance 🎀
This section covers the conformance issues and requirements 📋. This document introduces model entities such as objects, operations, attributes, attribute syntaxes, and attribute values 🧩. The conformance sections describe the conformance requirements that apply to these model entities 💜.
5.1 Client Conformance Requirements 💌
This section describes the conformance requirements for a client (see section 2.1), whether it's:
- contained within software controlled by an end user, e.g. activated by the "Print" menu item in an application that sends IPP requests, or
- the print server component that sends IPP requests to either an output device or another "downstream" print server 🖨️.
A conforming client MUST support all REQUIRED operations as defined in this document 🫶. For each attribute included in an operation request, a conforming client MUST supply a value whose type and value syntax conforms to the requirements of the Model document as specified in Sections 3 and 4 ✨. A conforming client MAY supply any IETF standards track extensions and/or vendor extensions in an operation request, as long as the extensions meet the requirements in Section 6 🦋.
Otherwise, there are no conformance requirements placed on the user interfaces provided by IPP clients or their applications 💅. For example, one app might not let an end user submit multiple documents per job, while another one does 🌸. One app might query a Printer object first so it can fill a graphical user interface (GUI) dialogue box with supported and default values, whereas a different implementation might not 🧚.
When sending a request, an IPP client need not supply any attributes that are optionally supplied by the client 🙌.
A client MUST be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range, that may be returned to it in a response from a Printer object 💖. In particular, for each attribute the client supports whose attribute syntax is 'text', the client MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms 🌈. Similarly, for each attribute the client supports whose attribute syntax is 'name', the client MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms 🎀. For presentation purposes, truncating long attribute values is not recommended 🙅♀️. A recommended approach is for the client implementation to let the user scroll through long attribute values 👑.
A response MAY contain attribute groups, attributes, attribute syntaxes, values, and status codes that the client doesn't expect 🫧. So a client implementation MUST gracefully handle such responses and not refuse to inter-operate with a conforming Printer that returns IETF standards track extensions or vendor extensions 🦋. That includes attribute groups, attributes, attribute syntaxes, attribute values, status codes, and out-of-band attribute values that conform to Section 6 💫. Clients may choose to ignore any parameters, attribute groups, attributes, attribute syntaxes, or values they don't understand 💅.
While a client is sending data to a printer, it SHOULD do its best to keep a channel from being closed by a lower layer when the channel is blocked (that is, flow-controlled off) for whatever reason, e.g. 'out of paper' or 'job ahead hasn't freed up enough memory' 🍓. However, the layer that launched the print submission (e.g. an end user) MAY close the channel in order to cancel the job 🙈. When a client closes a channel, a Printer MAY print all or part of the received portion of the document 🖨️. See the "Encoding and Transport" document [RFC2910] for more details 🔗.
A client MUST support Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910] 🔐. A client SHOULD support Operation Privacy and Server Authentication as defined in the same document [RFC2910] 🫶. See also section 8 of this document ✨.
5.2 IPP Object Conformance Requirements 🧚
This section specifies the conformance requirements for conforming implementations of IPP objects (see section 2) 💜. These requirements apply to an IPP object whether it is:
- an (embedded) device component that accepts IPP requests and controls the device, or
- a component of a print server that accepts IPP requests (where the print server controls one or more networked devices using IPP or other protocols) 🖨️.
5.2.1 Objects 🌟
Conforming implementations MUST implement all of the model objects as defined in this document in the indicated sections:
Section 2.1 - Printer Object
Section 2.2 - Job Object5.2.2 Operations 🎯
Conforming IPP object implementations MUST implement all of the REQUIRED model operations, including REQUIRED responses, as defined in this document in the indicated sections:
For a Printer object:
Print-Job (section 3.2.1) REQUIRED
Print-URI (section 3.2.2) OPTIONAL
Validate-Job (section 3.2.3) REQUIRED
Create-Job (section 3.2.4) OPTIONAL
Get-Printer-Attributes (section 3.2.5) REQUIRED
Get-Jobs (section 3.2.6) REQUIRED
Pause-Printer (section 3.2.7) OPTIONAL
Resume-Printer (section 3.2.8) OPTIONAL
Purge-Jobs (section 3.2.9) OPTIONAL
For a Job object:
Send-Document (section 3.3.1) OPTIONAL
Send-URI (section 3.3.2) OPTIONAL
Cancel-Job (section 3.3.3) REQUIRED
Get-Job-Attributes (section 3.3.4) REQUIRED
Hold-Job (section 3.3.5) OPTIONAL
Release-Job (section 3.3.6) OPTIONAL
Restart-Job (section 3.3.7) OPTIONALConforming IPP objects MUST support all REQUIRED operation attributes and all values of such attributes if so indicated in the description 💅. Conforming IPP objects MUST ignore all unsupported or unknown operation attributes or operation attribute groups received in a request 🫧, but MUST reject a request that contains a supported operation attribute that contains an unsupported value ⛔.
Conforming IPP objects MAY return operation responses that contain attribute groups, attribute names, attribute syntaxes, attribute values, and status codes that are extensions to this standard 🌈. The additional attribute groups MAY occur in any order 🎀.
The following section on object attributes specifies the support required for object attributes ✨.
5.2.3 IPP Object Attributes 🦋
Conforming IPP objects MUST support all of the REQUIRED object attributes, as defined in this document in the indicated sections 💖.
If an object supports an attribute, it MUST support only those values specified in this document or through the extension mechanism described in section 5.2.4 🌸. It MAY support any non-empty subset of these values 🧚. That is, it MUST support at least one of the specified values and at most all of them 💜.
5.2.4 Versions ✨
Okay bestie, IPP/1.1 clients MUST meet the conformance requirements for clients in this document and [RFC2910] 💅 They MUST also send requests with a "version-number" parameter set to '1.1' 🎀
IPP/1.1 Printer and Job objects MUST meet the conformance requirements for IPP objects in this document and [RFC2910] 🦋 They MUST accept requests with a "version-number" parameter set to '1.1' (or reject the request if the operation is not supported). No cap, that's the rule. 🫶
This spec doesn't go as far as making conformance with older versions mandatory. But IPP/1.1 was deliberately designed to make supporting previous versions easy, which is so smart 🧠✨ It's worth noting that, back when this was written (1999), we'd expect IPP/1.1 Printer implementations to:
- understand any valid request in the format of IPP/1.0, or 1.1;
- respond appropriately with a response containing the same
"version-number"parameter value the client used in the request.
And we'd expect IPP/1.1 clients to:
- understand any valid response in the format of IPP/1.0, or 1.1.
It is recommended that IPP/1.1 clients try supplying alternate version numbers if they get a 'server-error-version-not-supported' error return in a response. Lowkey a great comeback move 🌈
5.2.5 Extensions 🌸
A conforming IPP object MAY support IETF standards track extensions and vendor extensions, as long as those extensions meet the requirements in Section 6. Ate that, no notes 💖
For each attribute included in an operation response, a conforming IPP object MUST return a value whose type and value syntax conforms to the requirement of the Model document, as specified in Sections 3 and 4. Iconic behaviour, honestly 👑
5.2.6 Attribute Syntaxes 🧚
An IPP object MUST be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range, in any operation where a client may supply attributes or the system administrator may configure attributes (by means outside the scope of this IPP/1.1 document). Main character energy 💅
Specifically, for each attribute the IPP object supports whose attribute syntax is 'text', the IPP object MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. Same deal for 'name': for each supported attribute with that syntax, the IPP object MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. 🎀
And finally, an IPP object MUST return attributes to the client in operation responses that conform to the syntax in Section 4.1, including their full range if a client supplied them previously. Consistency is everything, periodt 🍓
5.2.7 Security 🔐
An IPP Printer implementation SHOULD contain support for Client Authentication, as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY let an administrator configure the Printer so that all, some, or none of the users are authenticated. See also Section 8 of this document 🫣
An IPP Printer implementation SHOULD also contain support for Operation Privacy and Server Authentication, as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY let an administrator configure the degree of support for Operation Privacy and Server Authentication. See also Section 8 of this document 💜
🚨 Serious bestie moment: Security MUST NOT be compromised when a client supplies a lower"version-number"parameter in a request. For example, if an IPP/1.1 conforming Printer object accepts version'1.0'requests and is configured to enforce Digest Authentication, it MUST do the same for a version'1.0'request. No downgrade shenanigans allowed, we are NOT letting that slide 😤💀
5.3 Charset and Natural Language Requirements 🌍
All clients and IPP objects MUST support the 'utf-8' charset, as defined in Section 4.1.7. Non-negotiable, the baseline 🩷
IPP objects MUST be able to accept any client request that correctly uses the "attributes-natural-language" operation attribute, or the Natural Language Override mechanism on any individual attribute, whether or not the IPP object supports that natural language. If an IPP object supports a natural language, then it MUST be able to translate (perhaps by table lookup) all generated 'text' or 'name' attribute values into one of the supported languages (see Section 3.1.4). The IPP object that supports a natural language NEED NOT be a general purpose translator of any arbitrary 'text' or 'name' value the client supplies into that natural language. However, the object MUST be able to translate (automatically generate) any of its own attribute values and messages into that natural language. Translator levels: its own stuff, yes; everything a client throws at it, not required 🦋✨
6. IANA Considerations 📋
This section describes the procedures for defining semantics for the following IETF standards track extensions and vendor extensions to the IPP/1.1 Model and Semantics document:
- keyword attribute values
- enum attribute values
- attributes
- attribute syntaxes
- operations
- attribute groups
- status codes
- out-of-band attribute values
Extensions registered for use with IPP/1.1 are OPTIONAL for client and IPP object conformance to the IPP/1.1 "Model and Semantics" document (this document). Optional but still iconic 💖
These extension procedures are aligned with the guidelines set forth by the IESG [IANA-CON]. Section 11 describes how to propose new registrations for consideration. IANA will reject registration proposals that leave out required information or don't follow the appropriate format described in Section 11. The IPP/1.1 Model and Semantics document may also be extended by an appropriate RFC that specifies any of the above extensions. Paperwork is a whole vibe, but it keeps things clean 📝
6.1 Typed 'keyword' and 'enum' Extensions 🏷️
IPP allows for 'keyword' and 'enum' extensions (see Sections 4.1.2.3 and 4.1.4). This document uses prefixes on the 'keyword' and 'enum' basic attribute syntax types to communicate extra information to the reader through the name. This extra information is not represented in the protocol, because it's unimportant to a client or Printer object. The list below describes the prefixes and what they mean 🌈
"type1": This IPP specification document must be revised (or another IETF standards track document which augments this document) to add a new keyword or a new enum. No vendor defined keywords or enums are allowed. Strict era, no freelancing 🔒"type2": Implementers can, at any time, add new keyword or enum values by proposing the complete specification to IANA at:
iana@iana.org
IANA will forward the registration proposal to the IPP Designated Expert, who will review the proposal with a mailing list that the Designated Expert keeps for this purpose. Initially, that list will be the mailing list used by the IPP WG:
ipp@pwg.org
even after the IPP WG is disbanded, as permitted by [IANA-CON].
The IPP Designated Expert is appointed by the IESG Area Director responsible for IPP, according to [IANA-CON].
When a type2 keyword or enum is approved, the IPP Designated Expert becomes the point of contact for any future maintenance that might be required for that registration. Their name is on it now 🎓
"type3": Implementers can, at any time, add new keyword and enum values by submitting the complete specification to IANA, as for type2, who will forward the proposal to the IPP Designated Expert. While no additional technical review is required, the IPP Designated Expert may, at his/her discretion, forward the proposal to the same mailing list as for type2 registrations for advice and comment.
When a type3 keyword or enum is approved by the IPP Designated Expert, the original proposer becomes the point of contact for any future maintenance that might be required for that registration. Proposer gets the maintenance glow-up ✨
For type2 and type3 keywords, the proposer includes the name of the keyword in the registration proposal, and the name is part of the technical review. Name it right, babe 💅
After type2 and type3 enum specifications are approved, the IPP Designated Expert, in consultation with IANA, assigns the next available enum number for each enum value 🔢
IANA will publish approved type2 and type3 keyword and enum attribute value registration specifications in:
ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txtwhere xxx is the attribute name that specifies the initial values, and yyy.txt is a descriptive file name that contains one or more enums or keywords approved at the same time. For example, if several additional enums for stapling are approved for use with the "finishings" attribute (and the "finishings-default" and "finishings-supported" attributes), IANA will publish the additional values in the file:
ftp.isi.edu/iana/assignments/ipp/attribute-
values/finishings/stapling.txtNote: Some attributes are defined to be 'type3 keywords' | 'name', which allows attribute values to be extended by a site administrator with administrator defined names. Such names are not registered with IANA. Admin-made names, no paperwork needed 🙈
By definition, each of the three types above asserts some sort of registry or review process in order for extensions to be considered valid. Each higher numbered level (1, 2, 3) tends to be decreasingly less stringent than the previous level. Therefore, any typeN value MAY be registered using a process for some typeM, where M is less than N; however, such registration is NOT REQUIRED. For example, a type3 value MAY be registered in a type 1 manner (by being included in a future version of an IPP specification); however, it is NOT REQUIRED. Choose your path, it's a whole gradient 🌸
This document defines keyword and enum values for all of the above types, including type3 keywords. Every type gets a seat at the table 🪑💜
For vendor keyword extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, such as "xxx-", where xxx follows the syntax rules for keywords (see Section 4.1.3) and is the (lowercase) fully qualified company name registered with IANA for use in domain names [RFC1035]. For example, if the company XYZ Corp. had obtained the domain name "XYZ.com", then a vendor keyword 'abc' would be: 'xyz.com-abc'. Brand it, but make it lowercase 🏢✨
Note: RFC 1035 [RFC1035] indicates that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. Also, the labels in a domain name must follow the rules for ARPANET host names: they must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. Labels must be 63 characters or less. Labels are separated by the "." character. Case doesn't matter, but the label rules are strict 🧐
For vendor enum extensions, implementers MUST use values in the reserved integer range, which is 2**30 to 2**31-1. Strict on the numbers, no vibes-based picking here 🔢🩷
6.2 Attribute Extensibility ✨
Okay so attribute names (see section 4.1.3) are type2 keywords 🎀 That means new attributes can be registered and get the same status as the attributes in this document, as long as they follow the type2 extension rules. For vendor attribute extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, as described in Section 6.1 💅
IANA publishes approved attribute registration specifications as separate files, like this:
ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txtwhere "xxx-yyy" is the new attribute name 🦋
If a new Printer object attribute is defined and its values can be affected by a specific document format, its specification needs to contain the following sentence:
"The value of this attribute returned in a Get-Printer-
Attributes response MAY depend on the "document-format"
attribute supplied (see Section 3.2.5.1)."If the specification doesn't say that, then its value in the Get-Printer-Attributes response MUST NOT depend on the "document-format" supplied in the request 🙈 When a new Job Template attribute is registered, the value of the Printer attributes MAY vary with "document-format" supplied in the request, and the specification doesn't have to mention it at all 💜
6.3 Attribute Syntax Extensibility 🌸
Attribute syntaxes (see section 4.1) are basically like type2 enums 🧚 So new attribute syntaxes can be registered and get the same status as the attribute syntaxes in this document, by following the type2 extension rules described in Section 6.1. The initial set of value codes that identify each attribute syntax was assigned in the "Encoding and Transport" document [RFC2910], which also includes a designated range for vendor extension ✨
For attribute syntaxes, the IPP Designated Expert, working with IANA, assigns the next attribute syntax code in the appropriate range, as specified in [RFC2910]. IANA publishes approved attribute syntax registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txtwhere 'xxx-yyy' is the new attribute syntax name 🍓
6.4 Operation Extensibility 💖
Operations (see section 3) can also be registered using the type2 procedures described in Section 6.1, though major new operations will usually be done by a new standards track RFC that augments this document 👑 For vendor operation extensions, implementers MUST use the range for the "operation-id" in requests specified in Section 4.4.15 "operations-supported" Printer attribute. Make sure you check that one, bestie 🫶
For operations, the IPP Designated Expert, working with IANA, assigns the next operation-id code as specified in Section 4.4.15. IANA publishes approved operation registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txtwhere "Xxx-Yyy" is the new operation name 🌈
6.5 Attribute Group Extensibility 🦋
Attribute groups (see section 3.1.3) that get passed in requests and responses can be registered using the type2 procedures described in Section 6.1. The initial set of attribute group tags was assigned in the "Encoding and Transport" document [RFC2910], which also has a designated range for vendor extension 💅
For attribute groups, the IPP Designated Expert, working with IANA, assigns the next attribute group tag code in the appropriate range, as specified in [RFC2910]. IANA publishes approved attribute group registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
tag.txtwhere 'xxx-yyy-tag' is the new attribute group tag name ✨
6.6 Status Code Extensibility 🔥
Operation status codes (see section 3.1.6.1) can also be registered using the type2 procedures described in Section 6.1. The values for status codes are allocated in ranges, as specified in Section 14 for each status code class 🌸 The classes are:
"informational" - Request received, continuing process
"successful" - The action was successfully received, understood, and
accepted
"redirection" - Further action must be taken in order to complete the
request
"client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid requestFor vendor operation status code extensions, implementers MUST use the top of each range, as specified in Section 13. Hard rule, no exceptions 😭
For operation status codes, the IPP Designated Expert, working with IANA, assigns the next status code in the appropriate class range, as specified in Section 13. IANA publishes approved status code registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txtwhere "xxx-yyy" is the new operation status code keyword 💜
6.7 Out-of-band Attribute Value Extensibility 🧚
Out-of-band attribute values (see the beginning of section 4.1) that get passed in requests and responses can be registered using the type2 procedures described in Section 6.1. The initial set of out-of-band attribute value tags was assigned in the "Encoding and Transport" document [RFC2910] 🍓
For out-of-band attribute value tags, the IPP Designated Expert, working with IANA, assigns the next out-of-band attribute value tag code in the appropriate range, as specified in [RFC2910]. IANA publishes approved out-of-band attribute value tag registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/out-of-band-attribute-value-
tags/xxx-yyy-tag.txtwhere 'xxx-yyy-tag' is the new out-of-band attribute value tag name 🌈
6.8 Registration of MIME types/sub-types for document-formats 📄
The "document-format" attribute's syntax is 'mimeMediaType'. That means valid values are Internet Media Types (see Section 4.1.9). RFC 2045 [RFC2045] defines the syntax for valid Internet media types, and IANA is the registry for all Internet media types 🫶
6.9 Registration of charsets for use in 'charset' attribute values 🌷
The "attributes-charset" attribute's syntax is 'charset'. That means valid values are charsets names. When a charset in the IANA registry has more than one name (alias), the name labeled as "(preferred MIME name)", if present, MUST be used (see Section 4.1.7). IANA is the registry for charsets, following the procedures of [RFC2278] 💖
7. Internationalization Considerations ✨
Okay, so some attributes hold text strings and names meant for humans to read, not machines 🌍 (see the text and name attribute syntaxes in Sections 4.1.1 and 4.1.2).
In every operation request, the client does two things 💖:
- identifies the charset and natural language of the request that applies to each supplied
textandnameattribute value, and - requests the charset and natural language for attributes returned by the IPP object in operation responses (as described in Section 3.1.4.1).
Also, the client MAY separately and individually identify the Natural Language Override of a supplied text or name attribute, using the textWithLanguage and nameWithLanguage technique described in section 4.1.1.2 and 4.1.2.2 respectively 🎀.
All IPP objects MUST support the UTF-8 [RFC2279] charset in all text and name attributes supported. If an IPP object supports more than the UTF-8 charset, the object MUST convert between them so it can return the requested charset to the client, according to Section 3.1.4.2. If an IPP object supports more than one natural language, the object SHOULD return text and name values in the natural language requested, where those values are generated by the Printer (see Section 3.1.4.1). This part is giving main character energy 👑
For Printers that support multiple charsets and/or multiple natural languages in text and name attributes, different jobs may have been submitted in differing charsets and/or natural languages 🌈. All responses MUST be returned in the charset requested by the client. However, the Get-Jobs operation uses the textWithLanguage and nameWithLanguage mechanism to identify the differing natural languages with each job attribute returned 🦋.
The Printer object also has configured charset and natural language attributes 🧚. The client can query the Printer object to find out the list of charsets and natural languages it supports, and what its configured values are. See the "charset-configured", "charset-supported", "natural-language-configured", and "generated-natural-language-supported" Printer description attributes for more details.
The "charset-supported" attribute identifies the supported charsets. If a charset is supported, the IPP object MUST be capable of converting to and from that charset into any other supported charset. In many cases, an IPP object will support only one charset, and it MUST be the UTF-8 charset 💅.
The "charset-configured" attribute identifies the one supported charset that is the native charset, given the current configuration of the IPP object (as defined by the administrator) 🍓.
The "generated-natural-language-supported" attribute identifies the set of supported natural languages for generated messages. It is not related to the set of natural languages that must be accepted for client-supplied text and name attributes. For client-supplied text and name attributes, an IPP object MUST accept ALL supplied natural languages. Just because a Printer object is currently configured to support en-us does not mean that the Printer object should reject a job if the client supplies a job name in fr-ca 🙈.
The "natural-language-configured" attribute identifies the one supported natural language for generated messages that is the native natural language, given the current configuration of the IPP object (as defined by the administrator) 🌸.
Attributes of type text and name are populated from different sources. These attributes can be sorted into the following groups, depending on where the attribute comes from ✨:
- Some attributes are supplied by the client. For example, the client-supplied "job-name", "document-name", and "requesting-user-name" operation attributes, along with the corresponding Job object's "job-name" and "job-originating-user-name" attributes. The IPP object MUST accept these attributes in any natural language, no matter what the set of supported languages for generated messages is.
- Some attributes are supplied by the system administrator. For example, the Printer object's "printer-name" and "printer-location" attributes. These too can be in any natural language. If the natural language for these attributes is different from what a client requests, then they must be reported using the Natural Language Override mechanism.
- Some attributes are supplied by the device manufacturer. For example, the Printer object's "printer-make-and-model" attribute. These too can be in any natural language. If the natural language for these attributes is different from what a client requests, then they must be reported using the Natural Language Override mechanism.
- Some attributes are supplied by the operator. For example, the Job object's "job-message-from-operator" attribute. These too can be in any natural language. If the natural language for these attributes is different from what a client requests, then they must be reported using the Natural Language Override mechanism.
- Some attributes are generated by the IPP object. For example, the Job object's "job-state-message" attribute, the Printer object's "printer-state-message" attribute, and the "status-message" operation attribute. These attributes can only be in one of the "generated-natural-language-supported" natural languages. If a client requests a natural language for these attributes other than one of the supported values, the IPP object SHOULD respond using the value of the "natural-language-configured" attribute (using the Natural Language Override mechanism if needed).
The text and name attributes specified in this version of this document are listed below. Additional ones will be registered according to the procedures in Section 6 🦋:
Attributes Source
Operation Attributes:
job-name (name) client
document-name (name) client
requesting-user-name (name) client
status-message (text) Job or Printer object
detailed-status-message (text) Job or Printer object -
see rule 1
document-access-error (text) Job or Printer object -
see rule 1
Job Template Attributes:
job-hold-until (keyword | name) client matches
administrator-configured
job-hold-until-default (keyword | name) client matches
administrator-configured
job-hold-until-supported (keyword | client matches
name) administrator-configured
job-sheets (keyword | name) client matches
administrator-configured
job-sheets-default (keyword | name) client matches
administrator-configured
job-sheets-supported (keyword | name) client matches
administrator-configured
media (keyword | name) client matches
administrator-configured
media-default (keyword | name) client matches
administrator-configured
media-supported (keyword | name) client matches
administrator-configured
media-ready (keyword | name) client matches
administrator-configured
Job Description Attributes:
job-name (name) client or Printer object
job-originating-user-name (name) Printer object
job-state-message (text) Job or Printer object
output-device-assigned (name(127)) administrator
job-message-from-operator (text(127)) operator
job-detailed-status-messages (1setOf Job or Printer object -
text) see rule 1
job-document-access-errors (1setOf Job or Printer object -
text) see rule 1
Printer Description Attributes:
printer-name (name(127)) administrator
printer-location (text(127)) administrator
printer-info (text(127)) administrator
printer-make-and-model (text(127)) administrator or
manufacturer
printer-state-message (text) Printer object
printer-message-from-operator operator
(text(127))Rule 1: Neither the Printer nor the client localizes these message attributes, since they are intended for use by the system administrator or other experienced technical people 🧐.
8. Security Considerations 🔐
Okay, real talk bestie, it is really hard to predict every security risk an IPP environment might have 😭. For example, if IPP is used inside a corporation over a private network, the risk of exposing document data may be low enough that the corporation decides not to encrypt that data. However, if the connection between the client and the IPP object goes over a public network, the client may want to protect the content of the information during transmission through the network with encryption 🔒.
Furthermore, how valuable the printed information is can change from one IPP environment to the next. Printing payroll checks, for example, is worth a lot more than printing public information from a file 💸. There is also the possibility of denial-of-service attacks. Denial-of-service attacks against printing resources are not well understood, though, and there are no published precedents for this scenario 💀.
Once the authenticated identity of the requester has been supplied to the IPP object, the object uses that identity to enforce any authorization policy that might be in place. For example, one site's policy might be that only the job owner is allowed to cancel a job 🙅♀️. The details and mechanisms for setting up a particular access control policy are not part of IPP/1.1. They must be established through some other type of administrative or access control framework. However, there are operation status codes that let an IPP server return information to a client about any potential access control violations for an IPP object 🚨.
During a create operation, the client's identity is recorded in the Job object, in an implementation-defined attribute. This information can be used to verify a client's identity for later operations on that Job object, so that any access control policy in effect can be enforced. See section 8.3 below for more details 🫶.
Since the security levels, or the specific threats that an IPP system administrator may be worried about, cannot be predicted, IPP MUST be capable of operating with different security mechanisms and security policies, as required by the individual installation. Security policies might vary from very strong, to very weak, to none at all, and corresponding security mechanisms will be required 👑.
8.1 Security Scenarios
okay bestie, this part walks through some specific security attacks that IPP environments could face 🔥 the examples are just illustrative vibes, not a full list of every possible situation 💅 ngl not all of these environments will necessarily be handled in the first implementations of IPP, so don't panic if they show up later 🫶
8.1.1 Client and Server in the Same Security Domain
picture this: an internal network where office workers print stuff from their personal productivity apps onto shared work-group printers 🖨️, or batch apps spit their output onto big production printers 🏭. even though the identity of the user may be trusted here 🙈, a user might still want to protect the content of a document from attacks like eavesdropping, replaying or tampering 🔐
8.1.2 Client and Server in Different Security Domains
examples: printing a doc the client made on a publicly available printer, like at a commercial print shop 🏪, or printing remotely on a business associate's printer 💼. that second one is functionally the same as faxing the document to your business associate 📠
printing sensitive info on a Printer in a different security domain needs strong security measures 🛡️ no cap, this is serious
in this environment, authentication of the printer is required, plus protection against unauthorized use of print resources 🚫. since the document crosses security domains, protection against eavesdropping and document tampering are also required 👀. it's also important to protect Printers against "spamming" and malicious document content 🗑️
8.1.3 Print by Reference
when the doc isn't stored on the client, printing can happen by reference 🧚 so the print request contains a pointer (a reference) to the doc instead of the doc itself (see sections 3.2.2 and 3.3.2) ✨. standard methods don't exist yet for remote entities to "assume" the credentials of a client when forwarding requests to a 3rd party 😬. it's expected that Print-By-Reference will be used to access "public" documents, and sophisticated methods for authenticating "proxies" aren't specified in this document 🙅
8.2 URIs in Operation, Job, and Printer attributes
the "printer-uri-supported" attribute holds the Printer object's URI(s) 🔗. its bestie attribute, "uri-security-supported", identifies the security mechanism used for each URI listed in "printer-uri-supported" 🔐. for each Printer operation request, a client MUST supply only one URI in the "printer-uri" operation attribute 🎯. so even if the Printer supports more than one URI, the client only interacts with the Printer object using one of its URIs 💅
this duality isn't needed for Job objects, because the Printer object is the factory for Job objects, and it generates the correct URI for new Job objects based on its own security configuration 🏭✨
8.3 URIs for each authentication mechanisms
each URI has an authentication mechanism attached to it 🔑. if the URI is the i'th element of "printer-uri-supported", then the authentication mechanism is the "i th" element of "uri-authentication-supported" 🧠. for a list of possible authentication mechanisms, see section 4.4.2 📋
the Printer object uses an authentication mechanism to figure out the name of the user performing an operation 🕵️. this user is called the "authenticated user" 💁. the credibility of the authentication depends on the mechanism the Printer uses to get the user's name 🤔. when the authentication mechanism is 'none', all authenticated users are "anonymous" 👻
during job creation operations, the Printer sets the "job-originating-user-name" attribute (see section 4.3.6) to be the authenticated user 📝. in this case, the authenticated user is called the "job owner" 👑
if an implementation can be configured to support more than one authentication mechanism (see section 4.4.2), then it MUST implement rules for determining equality of authenticated user names that were authenticated via different authentication mechanisms 🚨. one possible policy is that identical names authenticated via different mechanisms are different 🙅♀️. for example, a user can cancel his job only if he uses the same authentication mechanism for both Cancel-Job and Print-Job 🙃
another policy is that identical names authenticated via different mechanisms are the same if the authentication mechanism for the later operation is not less strong than the authentication mechanism for the earlier job creation operation 💪. for example, a user can cancel his job only if he uses the same or stronger authentication mechanism for Cancel-Job and Print-Job ✨. with this second policy, a job submitted via 'requesting-user-name' authentication could be canceled via 'digest' authentication 🎉. with the first policy, the job could not be canceled in this way 🚫
a client is able to determine the authentication mechanism used to create a job 🕵️♀️. it is the i'th value of the Printer's "uri-authentication-supported" attribute (see section 4.4.2), where i is the index of the element of the Printer's "printer-uri-supported" attribute (see section 4.4.1) equal to the job's "job-printer-uri" attribute (see section 4.3.3) 🧩
8.4 Restricted Queries
in lots of IPP operations, a client supplies a list of attributes to be returned in the response 📬. for security reasons, an IPP object may be configured not to return every attribute (or every value) that a client requests 🙈. the job attributes returned MAY depend on whether the requesting user is the same as the user that submitted the job 👀. the IPP object MAY even return none of the requested attributes 😶. in such cases, the status returned is the same as if the object had returned all requested attributes ✨. the client can't tell from such a response whether the requested attribute was present or absent on the object 🫥
8.5 Operations performed by operators and system administrators
for the three printer operations Pause-Printer, Resume-Printer, and Purge-Jobs (see sections 3.2.7, 3.2.8 and 3.2.9), the requesting user is intended to be an operator or administrator of the Printer object (see section 1) 👩💼. otherwise, the IPP Printer MUST reject the operation and return 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate 🚫
for operations on jobs, the requesting user is intended to be the job owner, or may be an operator or administrator of the Printer object 🧑💻. the means for authorizing an operator or administrator of the Printer object are not specified in this document 🤷
8.6 Queries on jobs submitted using non-IPP protocols
if the device that an IPP Printer is representing is able to accept jobs using other job submission protocols in addition to IPP 🖨️, it is RECOMMENDED that such an implementation at least allow those "foreign" jobs to be queried using Get-Jobs, returning "job-id" and "job-uri" as 'unknown' 🔍. such an implementation NEED NOT support all of the same IPP job attributes as for IPP jobs 🙃. the IPP object returns the 'unknown' out-of-band value for any requested attribute of a foreign job that is supported for IPP jobs but not for foreign jobs 🫠
it is further RECOMMENDED, that the IPP Printer generate "job-id" and "job-uri" values for such "foreign jobs", if possible 🪄, so they may be targets of other IPP operations, such as Get-Job-Attributes and Cancel-Job 🎯. such an implementation also needs to deal with the problem of authentication of such foreign jobs 🔐. one approach would be to treat all such foreign jobs as belonging to users other than the user of the IPP client 👯. another approach would be for the foreign job to belong to 'anonymous' 👻
only if the IPP client has been authenticated as an operator or administrator of the IPP Printer object could the foreign jobs be queried by an IPP request 👩💼. alternatively, if the security policy is to allow users to query other users' jobs, then the foreign jobs would also be visible to an end-user IPP client using Get-Jobs and Get-Job-Attributes obsessed with how much thought went into this 💖
9. References ✨
Okay bestie, this is where the document shows its receipts 💅 Every doc it leans on gets listed here with all the details, nothing skipped 📚
These are the receipts, so they stay exactly as written, typos and all 🙈
[ASME-Y14.1M] Metric Drawing Sheet Size and Format, ASME Y14.1M-1995.
This standard defines metric sheet sizes and formats
for engineering drawings.
[ASCII] Coded Character Set - 7-bit American Standard Code for
Information Interchange (ASCII), ANSI X3.4-1986. This
standard is the specification of the US-ASCII charset.
[BCP-11] Bradner S. and R. Hovey, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[HTPP] J. Barnett, K. Carter, R. DeBry, "Initial Draft -
Hypertext Printing Protocol - HTPP/1.0", October 1996,
ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/overview.ps.gz
[IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[IANA-CS] IANA Registry of Coded Character Sets:
ftp://ftp.isi.edu/in-notes/iana/assignments/character-
sets
[IANA-MT] IANA Registry of Media Types: ftp://ftp.isi.edu/in-
notes/iana/assignments/media-types/
[IPP-IIG] Hastings, T., Manros, C., Kugler, C., Holst, H., and P.
Zehler, "Internet Printing Protocol/1.1: draft-ietf-
ipp-implementers-guide-v11-01.txt, work in progress,
May 30, 2000.
[ISO10646-1] ISO/IEC 10646-1:1993, "Information technology --
Universal Multiple-Octet Coded Character Set (UCS) -
Part 1: Architecture and Basic Multilingual Plane,
JTC1/SC2."
[ISO8859-1] ISO/IEC 8859-1:1987, "Information technology -- 8-bit
One-Byte Coded Character Set - Part 1: Latin Alphabet
Nr 1", 1987, JTC1/SC2.
[ISO10175] ISO/IEC 10175 Document Printing Application (DPA), June
1996.
[LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D.
Taylor, P. Zehler, "LDPA - Lightweight Document
Printing Application", October 1996,
ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz
[P1387.4] Kirk, M. (editor), POSIX System Administration - Part
4: Printing Interfaces, POSIX 1387.4 D8, 1994.
[PSIS] Herriot, R. (editor), X/Open A Printing System
Interoperability Specification (PSIS), August 1995.
[PWG] Printer Working Group, http://www.pwg.org.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC
1179, August 1990.
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3 ", RFC 1951, May 1996.
[RFC1952] Deutsch, P., "GZIP file format specification version
4.3", RFC 1952, May 1996.
[RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
August 1996.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2045] Freed, N. and N. Borenstein, ", Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extension (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions",
RFC 2228, October 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages" BCP 18, RFC 2277, January 1998.
[RFC2278] Freed, N. and J. Postel: "IANA CharSet Registration
Procedures", BCP 19, RFC 2278, January 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2565, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569,
April 1999.
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A. and L. Stewart, "HTTP
Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
[RFC2639] Hastings, T. and C. Manros, "Internet Printing
Protocol/1.0: Encoding and Transport", RFC 2639, July
1999.
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
[SSL] Netscape, The SSL Protocol, Version 3, (Text version
3.02), November 1996.
[SWP] P. Moore, B. Jahromi, S. Butler, "Simple Web Printing
SWP/1.0", May 7, 1997,
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf10. Authors' Addresses ✨
okay bestie, here are the humans behind this spec 🫶 the editor and authors are listed first, then the IPP mailing list details, then a whole squad of other participants who helped make it happen 🎀
Scott A. Isaacson, Editor
Novell, Inc.
122 E 1700 S
Provo, UT 84606
Phone: 801-861-7366
Fax: 801-861-2517
EMail: sisaacson@novell.com
Tom Hastings
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
Robert Herriot
Xerox Corp.
3400 Hill View Ave, Building 1
Palo Alto, CA 94304
Phone: 650-813-7696
Fax: 650-813-6860
EMail: robert.herriot@pahv.xerox.com
Roger deBry
Utah Valley State College
Orem, UT 84058
Phone: (801) 222-8000
EMail: debryro@uvsc.edu
Patrick Powell
Astart Technologies
9475 Chesapeake Dr., Suite D
San Diego, CA 95123
Phone: (619) 874-6543
Fax: (619) 279-8424
EMail: papowell@astart.com
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.orgokay so if you want in on the IPP conversation, here's how to join the mailing list 💌
- send it to
majordomo@pwg.org - leave the subject line blank
- put the following two lines in the message body:
subscribe ipp
endimplementers of this spec are super encouraged to join the IPP Mailing List 🦋 that's where you talk through clarification issues and review registration proposals for new attributes and values. main character energy for sure 💅
Other Participants:
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Cannon Devon Taylor - Novell
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Toshiba Lloyd Young - Lexmark
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang- Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon Information
Systems11. Formats for IPP Registration Proposals 🎀
okay so if you wanna propose an IPP extension for registration, you have to send an application to IANA. you can email iana@iana.org or fill out the form on the IANA web pages (http://www.iana.org) 📮 this section lays out the info you need and the formats for proposing each kind of extension that Section 6 talks about, which is:
- type2 'keyword' attribute values
- type3 'keyword' attribute values
- type2 'enum' attribute values
- type3 'enum' attribute values
- attributes
- attribute syntaxes
- operations
- status codes
- out-of-band attribute values
11.1 Type2 keyword attribute values registration,
okay, the template for a type2 keyword is below. just fill in the blanks 💖
Type of registration: type2 keyword attribute value
Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this keyword value:
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):
Name of proposer:
Address of proposer:
Email address of proposer:note 🫶 for type2 keywords, the Designated Expert is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.2 Type3 keyword attribute values registration
same vibe for type3 keywords, just a different template 🌸
Type of registration: type3 keyword attribute value
Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this keyword value:
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):
Name of proposer:
Address of proposer:
Email address of proposer:note 🦋 for type3 keywords, the proposer is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.3 Type2 enum attribute values registration
enums need a numeric value too, so this template has an extra field 🔢
Type of registration: type2 enum attribute value
Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA):
Specification of this enum value (follow the style of IPP Model
Section 4.1.4):
Name of proposer:
Address of proposer:
Email address of proposer:note 💜 for type2 enums, the Designated Expert is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.4 Type3 enum attribute values registration
type3 enums get the same numeric value field 🍓
Type of registration: type3 enum attribute value
Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA):
Specification of this enum value (follow the style of IPP Model
Section 4.1.4):
Name of proposer:
Address of proposer:
Email address of proposer:note ✨ for type3 enums, the proposer is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.5 Attribute registration
attributes get the biggest form, because there's a lot to think about 👑
Type of registration: attribute
Proposed keyword name of this attribute:
Types of attribute (Operation, Job Template, Job Description, Printer
Description):
Operations to be used with if the attribute is an operation attribute:
Object (Job, Printer, etc. if bound to an object):
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
If attribute syntax is 'keyword' or 'enum', is it type2 or type3:
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2):
If this is a Job Template attribute, how does its specification depend
on the value of the "multiple-document-handling" attribute:
Specification of this attribute (follow the style of IPP Model Section
4.2):
Name of proposer:
Address of proposer:
Email address of proposer:note 🌈 for attributes, the IPP Designated Expert is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.6 Attribute Syntax registration
attribute syntaxes have their own form too, and it cites [RFC2910] 💅
Type of registration: attribute syntax
Proposed name of this attribute syntax:
Type of attribute syntax (integer, octetString, character-string, see
[RFC2910]):
Numeric tag according to [RFC2910] (to be assigned by the IPP
Designated Expert in consultation with IANA):
Specification of this attribute (follow the style of IPP Model Section
4.1):
Name of proposer:
Address of proposer:
Email address of proposer:note 🦋 for attribute syntaxes, the IPP Designated Expert is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.7 Operation registration
operations need a name, an operation-id, and an object target 🎯
Type of registration: operation
Proposed name of this operation:
Numeric operation-id value according to section 4.4.15 (to be assigned
by the IPP Designated Expert in consultation with IANA):
Object Target (Job, Printer, etc. that operation is upon):
Specification of this operation (follow the style of IPP Model Section
3):
Name of proposer:
Address of proposer:
Email address of proposer:note 🫶 for operations, the IPP Designated Expert is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.8 Attribute Group registration
attribute groups are next, and this one asks where the group shows up in each operation 🧚
Type of registration: attribute group
Proposed name of this attribute group:
Numeric tag according to [RFC2910] (to be assigned by the IPP
Designated Expert in consultation with IANA):
Operation requests and group number for each operation in which the
attribute group occurs:
Operation responses and group number for each operation in which the
attribute group occurs:
Specification of this attribute group (follow the style of IPP Model
Section 3):
Name of proposer:
Address of proposer:
Email address of proposer:note 💖 for attribute groups, the IPP Designated Expert is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.9 Status code registration
last but not least, status codes 🚦
Type of registration: status code
Keyword symbolic name of this status code value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA):
Operations that this status code may be used with:
Specification of this status code (follow the style of IPP Model
Section 13 APPENDIX B: Status Codes and Suggested Status Code
Messages):
Name of proposer:
Address of proposer:
Email address of proposer:note 🌸 for status codes, the Designated Expert is the point of contact for the approved registration spec, if any maintenance of it is needed.
11.10 Out-of-band Attribute Value registration ✨
Okay bestie, this is the form for registering an out-of-band attribute value 🎀 Here's the template you fill in:
Type of registration: out-of-band attribute value
Proposed name of this out-of-band attribute value:
Numeric tag according to [RFC2910] (to be assigned by the IPP Designated
Expert in consultation with IANA):
Operations that this out-of-band attribute value may be used with:
Attributes that this out-of-band attribute value may be used with:
Specification of this out-of-band attribute value (follow the style of
the beginning of IPP Model Section 4.1):
Name of proposer:
Address of proposer:
Email address of proposer:Note: For out-of-band attribute values, the IPP Designated Expert will be the point of contact for the approved registration specification, if any maintenance of the registration specification is needed. 🫶
12. APPENDIX A: Terminology 📖
This specification document uses the terminology defined in this section, so this is the glossary moment, bestie 💜
12.1 Conformance Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These are the official BCP 14 words, so treat them like sacred scripture 🔥
12.1.1 NEED NOT
This term is not included in RFC 2119. The verb "NEED NOT" indicates an action that the subject of the sentence does not have to implement in order to claim conformance to the standard. The verb "NEED NOT" is used instead of "MAY NOT" since "MAY NOT" sounds like a prohibition. Not me being dramatic about wording, but the wording really matters 💅
12.2 Model Terminology
12.2.1 Keyword
Keywords are used within this document as identifiers of semantic entities within the abstract model (see section 4.1.2.3). Attribute names, some attribute values, attribute syntaxes, and attribute group names are represented as keywords. Think of them as the name tags on everything in the model 🏷️
12.2.2 Attributes
An attribute is an item of information that is associated with an instance of an IPP object. An attribute consists of an attribute name and one or more attribute values. Each attribute has a specific attribute syntax. All object attributes are defined in section 4 and all operation attributes are defined in section 3.
Job Template Attributes are described in section 4.2. The client optionally supplies Job Template attributes in a create request (operation requests that create Job objects). The Printer object has associated attributes which define supported and default values for the Printer. 🖨️✨
12.2.2.1 Attribute Name
Each attribute is uniquely identified in this document by its attribute name. An attribute name is a keyword. The keyword attribute name is given in the section header describing that attribute. In running text in this document, attribute names are indicated inside double quotation marks (") where the quotation marks are not part of the keyword itself. 🎀
12.2.2.2 Attribute Group Name
Related attributes are grouped into named groups. The name of the group is a keyword. The group name may be used in place of naming all the attributes in the group explicitly. Attribute groups are defined in section 3. Group chat, but for attributes 🫶
12.2.2.3 Attribute Value
Each attribute has one or more values. Attribute values are represented in the syntax type specified for that attribute. In running text in this document, attribute values are indicated inside single quotation marks ('), whether their attribute syntax is keyword, integer, text, etc. where the quotation marks are not part of the value itself. 🍓
12.2.2.4 Attribute Syntax
Each attribute is defined using an explicit syntax type. In this document, each syntax type is defined as a keyword with specific meaning. The "Encoding and Transport" document [RFC2910] indicates the actual "on-the-wire" encoding rules for each syntax type. Attribute syntax types are defined in section 4.1. 🧚
12.2.3 Supports
By definition, a Printer object supports an attribute only if that Printer object responds with the corresponding attribute populated with some value(s) in a response to a query for that attribute. A Printer object supports an attribute value if the value is one of the Printer object's "supported values" attributes. The device behind a Printer object may exhibit a behavior that corresponds to some IPP attribute, but if the Printer object, when queried for that attribute, doesn't respond with the attribute, then as far as IPP is concerned, that implementation does not support that feature. If the Printer object's "xxx-supported" attribute is not populated with a particular value (even if that value is a legal value for that attribute), then that Printer object does not support that particular value. Be honest, the printer has to say it out loud or it doesn't count 🙈
A conforming implementation MUST support all REQUIRED attributes. However, even for REQUIRED attributes, conformance to IPP does not mandate that all implementations support all possible values representing all possible job processing behaviors and features. For example, if a given instance of a Printer supports only certain document formats, then that Printer responds with the "document-format-supported" attribute populated with a set of values, possibly only one, taken from the entire set of possible values defined for that attribute. This limited set of values represents the Printer's set of supported document formats. Supporting an attribute and some set of values for that attribute enables IPP end users to be aware of and make use of those features associated with that attribute and those values. If an implementation chooses to not support an attribute or some specific value, then IPP end users would have no ability to make use of that feature within the context of IPP itself. However, due to existing practice and legacy systems which are not IPP aware, there might be some other mechanism outside the scope of IPP to control or request the "unsupported" feature (such as embedded instructions within the document data itself). 👑
For example, consider the "finishings-supported" attribute.
- If a Printer object is not physically capable of stapling, the "finishings-supported" attribute MUST NOT be populated with the value of
'staple'. - A Printer object is physically capable of stapling, however an implementation chooses not to support stapling in the IPP "finishings" attribute. In this case,
'staple'MUST NOT be a value in the "finishings-supported" Printer object attribute. Without support for the value'staple', an IPP end user would have no means within the protocol itself to request that a Job be stapled. However, an existing document data formatter might be able to request that the document be stapled directly with an embedded instruction within the document data. In this case, the IPP implementation does not "support" stapling, however the end user is still able to have some control over the stapling of the completed job. 🧷 - A Printer object is physically capable of stapling, and an implementation chooses to support stapling in the IPP "finishings" attribute. In this case,
'staple'MUST be a value in the "finishings-supported" Printer object attribute. Doing so, would enable end users to be aware of and make use of the stapling feature using IPP attributes. ⭐
Even though support for Job Template attributes by a Printer object is OPTIONAL, it is RECOMMENDED that if the device behind a Printer object is capable of realizing any feature or function that corresponds to an IPP attribute and some associated value, then that implementation SHOULD support that IPP attribute and value. Optional, but very much encouraged 🌈
The set of values in any of the supported value attributes is set (populated) by some administrative process or automatic sensing mechanism that is outside the scope of this IPP/1.1 document. For administrative policy and control reasons, an administrator may choose to make only a subset of possible values visible to the end user. In this case, the real output device behind the IPP Printer abstraction may be capable of a certain feature, however an administrator is specifying that access to that feature not be exposed to the end user through the IPP protocol. Also, since a Printer object may represent a logical print device (not just a physical device) the actual process for supporting a value is undefined and left up to the implementation. However, if a Printer object supports a value, some manual human action may be needed to realize the semantic action associated with the value, but no end user action is required. 🫧
For example, if one of the values in the "finishings-supported" attribute is 'staple', the actual process might be an automatic staple action by a physical device controlled by some command sent to the device. Or, the actual process of stapling might be a manual action by an operator at an operator attended Printer object. 🧑🔧
For another example of how supported attributes function, consider a system administrator who desires to control all print jobs so that no job sheets are printed in order to conserve paper. To force no job sheets, the system administrator sets the only supported value for the "job-sheets-supported" attribute to 'none'. In this case, if a client requests anything except 'none', the create request is rejected or the "job-sheets" value is ignored (depending on the value of "ipp-attribute-fidelity"). To force the use of job start/end sheets on all jobs, the administrator does not include the value 'none' in the "job-sheets-supported" attribute. In this case, if a client requests 'none', the create request is rejected or the "job-sheets" value is ignored (again depending on the value of "ipp-attribute-fidelity"). 🙃
12.2.4 print-stream page
A "print-stream page" is a page according to the definition of pages in the language used to express the document data. 📄
12.2.5 impression
An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page. 🦋
13. APPENDIX B: Status Codes and Suggested Status Code Messages ✨
okay so this section is all about the status code enum keywords and values 🎀, which are how an operation response tells you what happened. Every operation response MUST include a status code, no exceptions, bestie 💅. The response MAY also contain a status message with a short textual description. The status code is for the automata 🤖, and the status message is for the human end user 🫶. Because the status message is an OPTIONAL part of the response, an IPP application (a browser, GUI, print driver or gateway, etc.) is NOT REQUIRED to check or display it, since it MAY not be returned to the application at all 🙈.
The prefix of the status keyword tells you the class of response:
"informational" - Request received, continuing process
"successful" - The action was successfully received, understood,
and accepted
"redirection" - Further action must be taken in order to complete
the request
"client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid requestJust like type2 enums, IPP status codes are extensible 🌈. IPP clients are NOT REQUIRED to know what every registered status code means, though honestly it's obviously desirable 😭. However, IPP clients MUST understand the class of any status code from its prefix, and treat any unrecognized response as the first status code of that class, with one twist: an unrecognized response MUST NOT be cached. For example, if a client gets an unrecognized client-error-xxx-yyy, it can safely assume something was wrong with its request and treat it like client-error-bad-request ✨. In cases like this, IPP applications SHOULD show the OPTIONAL message (if there is one) to the end user, because it's likely to have human readable info that explains the weird status 🧚. The name of the enum is the suggested status message for US English.
The status code values range from 0x0000 to 0x7FFF. Here's how each class is laid out:
"successful" - 0x0000 to 0x00FF
"informational" - 0x0100 to 0x01FF
"redirection" - 0x0200 to 0x02FF
"client-error" - 0x0400 to 0x04FF
"server-error" - 0x0500 to 0x05FFThe top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0 to 5) is reserved for vendor use within each class 🍓. Values 0x0600 to 0x7FFF are reserved for future assignment by IETF standards track documents, and they MUST NOT be used 🚫.
13.1 Status Codes
Each status code is described below 💖. Section 13.1.5.9 has a table showing which status codes apply to which operations. The Implementer's Guide [IPP-IIG] describes the suggested steps for processing IPP attributes for all operations, including returning status codes 📚.
13.1.1 Informational
This class is for provisional responses, and it's for informational purposes only 🦋.
There are no status codes defined in IPP/1.1 for this class.
13.1.2 Successful Status Codes
This class means the client's request was successfully received, understood, and accepted 🎉.
13.1.2.1 successful-ok (0x0000)
The request succeeded and no request attributes were substituted or ignored 💅. For a response to a create request, successful-ok means the request was received and validated and the Job object was created. It does NOT mean the job has been processed 👀. The only sign the job has been printed is when the Job object transitions into the 'completed' state 🖨️✨.
13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)
The request succeeded, but some supplied attributes were ignored, or unsupported values were swapped for supported ones or ignored so the operation could go through without being rejected 🌸. Unsupported attributes, attribute syntaxes, or values MUST be returned in the Unsupported Attributes group of the response for all operations. There's one exception for the query operations (Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes), and it's only for the "requested-attributes" operation attribute. If the supplied values of "requested-attributes" ask for attributes that aren't supported, the IPP object MAY, but is NOT REQUIRED to, return the "requested-attributes" attribute in the Unsupported Attribute response group (with the unsupported values only) 🙃. See sections 3.1.7 and 3.2.1.2.
13.1.2.3 successful-ok-conflicting-attributes (0x0002)
The request succeeded, but some supplied attribute values clashed with other supplied attributes 💀. Those conflicting values were either (1) swapped for supported values or (2) the attributes were removed, so the job could be processed without being rejected 🔥. Attributes or values that conflict and got substituted or ignored MUST be returned in the Unsupported Attributes group for all operations, as the client supplied them. See sections 3.1.7 and 3.2.1.2.
13.1.3 Redirection Status Codes
This class means further action needs to be taken to fulfill the request 🧭.
There are no status codes defined in IPP/1.1 for this class.
13.1.4 Client Error Status Codes
This class is for when the client seems to have messed up 🙈. The IPP object SHOULD return a message explaining the error and whether it's a temporary or permanent condition 💬.
13.1.4.1 client-error-bad-request (0x0400)
The IPP object couldn't understand the request because of malformed syntax, such as a fixed length attribute whose value doesn't match its prescribed length (see the Implementer's Guide [IPP-IIG]) 🧩. The IPP application SHOULD NOT repeat the request without modifications.
13.1.4.2 client-error-forbidden (0x0401)
The IPP object understood the request but is refusing to fulfill it 🚪. Extra authentication info or authorization credentials won't help, so the request SHOULD NOT be repeated. This code is commonly used when the IPP object doesn't want to reveal exactly why the request was refused, or when no other response fits 🤐.
13.1.4.3 client-error-not-authenticated (0x0402)
The request needs user authentication 🔐. The IPP client MAY repeat the request with suitable authentication information. If the request already included authentication info, this code means authorization was refused for those credentials. If this response has the same challenge as the prior response, and the user agent has already tried authenticating at least once, the response message MAY contain relevant diagnostic information. This status code reveals more info than "client-error-forbidden" 👀.
13.1.4.4 client-error-not-authorized (0x0403)
The requester isn't authorized to perform the request 🛑. Extra authentication info or authorization credentials won't help, so the request SHOULD NOT be repeated. This code is used when the IPP object wants to make it clear that the authentication info is understandable, but the requester is explicitly not allowed to do the thing 😤. This status code reveals more info than "client-error-forbidden" and "client-error-not-authenticated" 💅.
13.1.4.5 client-error-not-possible (0x0404)
This code is for requests for something that can't happen 🙅♀️. For example, a request to cancel a job that was already canceled or aborted by the system. The IPP client SHOULD NOT repeat the request.
13.1.4.6 client-error-timeout (0x0405)
The client didn't produce a request within the time the IPP object was prepared to wait ⏰. For example, a client sent a Create-Job operation and then, after a long wait, sent a Send-Document operation, and this error was returned in response to the Send-Document request (see section 3.3.1) 😭. The IPP object might have had to clean up resources it was holding for the Documents it was waiting on. It was forced to close the Job because the client took too long. The client SHOULD NOT repeat the request without modifications.
13.1.4.7 client-error-not-found (0x0406)
The IPP object couldn't find anything matching the request URI 🔍. No info is given on whether the condition is temporary or permanent. For example, a client with an old reference to a Job (a URI) tries to cancel it, but in the meantime the Job might have completed and all record of it at the Printer was deleted 🫠. This code, 'client-error-not-found', is returned to say the referenced Job can't be found. This error is also used when a client gives a URI as a reference to the document data in a Print-URI or Send-URI operation, but the document can't be found 📄.
In practice, an IPP application should avoid a not found situation by first querying and showing the end-user a list of valid Printer URIs and Job URIs 🧚♀️✨.
13.1.4.8 client-error-gone (0x0407)
The requested object is no longer available and no forwarding address is known 👋. This condition should be considered permanent. Clients with link editing capabilities should delete references to the request URI after user approval. If the IPP object doesn't know, or has no way to figure out, whether the condition is permanent, the status code "client-error-not-found" should be used instead 🗑️.
This response is mainly meant to help with maintenance by telling the recipient the resource is intentionally unavailable, and that the IPP object administrator wants remote links to that resource removed 🧹. It's NOT necessary to mark every permanently unavailable resource as "gone", or to keep the mark for any length of time. That's up to the discretion of the IPP object administrator and/or Printer implementation 💜.
13.1.4.9 client-error-request-entity-too-large (0x0408)
The IPP object is refusing to process a request because the request entity is bigger than the IPP object is willing or able to handle 🐘. An IPP Printer returns this code when it limits the size of print jobs and gets a job that goes over that limit, or when there are so many attributes that their encoding pushes the request entity over IPP object capacity 📏.
13.1.4.10 client-error-request-value-too-long (0x0409) 🎀
okay bestie, this one is about a request that's got a value that's way too long 📏 The IPP object is refusing to service the request because one or more of the client-supplied attributes has a variable-length value that's longer than the maximum length for that attribute. 😭 The object might not have enough resources (memory, buffers, etc.) to process, interpret, or ignore a value that big, even for a moment. There's also a second case: the object can handle a large value that's still under the max, but while it's handling the whole request, it passes the value along to some other system component that can't take it. 💀 For more details, check the Implementer's Guide [IPP-IIG].
Note: for attribute values that are URIs, this is a rare situation. It usually only happens when a client sent a request with long query info (like when an IPP app lets an end-user type in a URI that isn't valid), when the client got stuck in a URI "black hole" of redirection (like a redirected URI prefix that points to a suffix of itself), or when the IPP object is under attack from a client trying to exploit security holes in IPP objects that use fixed-length buffers to read or handle the Request-URI. 🚨 Not cute, but it's important to know what's going on!
13.1.4.11 client-error-document-format-not-supported (0x040A) 📄
the IPP object is refusing to service the request because the document data is in a format (given in the "document-format" operation attribute) that the Printer object doesn't support 🙅♀️ This error comes back no matter what the client set for "ipp-attribute-fidelity". The Printer object MUST return this status code, even if other Job Template attributes aren't supported too, because this error is a way bigger problem than the Job Template ones 😤 See sections 3.1.6.1, 3.1.7, and 3.2.1.1.
13.1.4.12 client-error-attributes-or-values-not-supported (0x040B) 🧐
in a create request, if the Printer object doesn't support one or more attributes, attribute syntaxes, or attribute values from the request, AND the client set "ipp-attribute-fidelity" to 'true', the Printer object MUST return this status code. ✨ The Printer object MUST also return all the unsupported attributes and/or values the client sent in the Unsupported Attributes Group. See section 3.1.7. For example: the request asks for 'iso-a4' media, but that media type isn't supported by the Printer object. Or the client sends a Job Template attribute that the Printer doesn't support at all. 🙃 If "ipp-attribute-fidelity" is 'false', the Printer MUST ignore or substitute values for unsupported Job Template attributes and values, instead of rejecting the request and returning this status code. 💅
For any operation where a client asks for attributes (like Get-Jobs, Get-Printer-Attributes, or Get-Job-Attributes), if the IPP object doesn't support one or more of the requested attributes, it just ignores those and processes the request as though they hadn't been asked for. 🫶 It does NOT return this status code in that case. Instead, the IPP object MUST return the 'successful-ok-ignored-or-substituted-attributes' status code, and MAY return the unsupported attributes as values of the "requested-attributes" in the Unsupported Attributes Group (see section 13.1.2.2). 🌸
13.1.4.13 client-error-uri-scheme-not-supported (0x040C) 🔗
the scheme of the client-supplied URI in a Print-URI or Send-URI operation isn't supported. Simple as that! See sections 3.1.6.1 and 3.1.7. 🦋
13.1.4.14 client-error-charset-not-supported (0x040D) 🔤
for any operation, if the IPP Printer doesn't support the charset the client sent in the "attributes-charset" operation attribute, the Printer MUST reject the operation and return this status, along with any 'text' or 'name' attributes in the 'utf-8' charset (see Section 3.1.4.1). 🙈 See sections 3.1.6.1 and 3.1.7.
13.1.4.15 client-error-conflicting-attributes (0x040E) ⚡
the request gets rejected because some attribute values clash with the values of other attributes, and this document doesn't allow those to be swapped out or ignored 🥊 The Printer object MUST also return the conflicting attributes the client sent in the Unsupported Attributes Group. See sections 3.1.7 and 3.2.1.2.
13.1.4.16 client-error-compression-not-supported (0x040F) 🗜️
the IPP object is refusing to service the request because the document data, as given in the "compression" operation attribute, is compressed in a way the Printer object doesn't support 🙅♀️ This error comes back no matter what the client set for "ipp-attribute-fidelity". The Printer object MUST return this status code, even if other Job Template attributes aren't supported either, since this error is a bigger problem than the Job Template ones. See sections 3.1.6.1, 3.1.7, and 3.2.1.1.
13.1.4.17 client-error-compression-error (0x0410) 💥
the IPP object is refusing to service the request because the document data can't be decompressed using the algorithm given in the "compression" operation attribute. 😵 This error comes back no matter what the client set for "ipp-attribute-fidelity". The Printer object MUST return this status code, even if there are Job Template attributes that aren't supported too, since this error is a bigger problem than the Job Template ones. See sections 3.1.7 and 3.2.1.1.
13.1.4.18 client-error-document-format-error (0x0411) 🧾
the IPP object is refusing to service the request because the Printer ran into an error in the document data while trying to interpret it 🫠 This error comes back no matter what the client set for "ipp-attribute-fidelity". The Printer object MUST return this status code, even if there are Job Template attributes that aren't supported too, since this error is a bigger problem than the Job Template ones. See sections 3.1.7 and 3.2.1.1.
13.1.4.19 client-error-document-access-error (0x0412) 🔐
the IPP object is refusing to service the Print-URI or Send-URI request because the Printer hit an access error while trying to check that the document data in the "document-uri" operation attribute is accessible, or while trying to access it 🚧 The Printer MAY also return a specific document access error code using the "document-access-error" operation attribute (see section 3.1.6.4). This error comes back no matter what the client set for "ipp-attribute-fidelity". The Printer object MUST return this status code, even if there are Job Template attributes that aren't supported too, since this error is a bigger problem than the Job Template ones. See sections 3.1.6.1 and 3.1.7.
13.1.5 Server Error Status Codes 🛠️
okay, this whole class is for when the IPP object knows it messed up or just can't do the request right now 🥲 The IPP object SHOULD include a message explaining the error and whether it's a temporary or permanent problem. 💜
13.1.5.1 server-error-internal-error (0x0500) 🧯
the IPP object ran into an unexpected condition that stopped it from fulfilling the request. This one is different from "server-error-temporary-error" because it implies a more permanent kind of internal error 🪦 It's also different from "server-error-device-error", because that one is about an expected (if annoying) problem like a paper jam or being out of toner, while this one is an unexpected condition. This status code means some knowledgeable human probably needs to step in 🧑💻
13.1.5.2 server-error-operation-not-supported (0x0501) 🙅
the IPP object doesn't support the functionality needed to fulfill the request. This is the right response when the IPP object doesn't recognize an operation, or can't support it at all. See sections 3.1.6.1 and 3.1.7. 🫥
13.1.5.3 server-error-service-unavailable (0x0502) 🚦
the IPP object can't handle the request right now because it's temporarily overloaded or under maintenance 🛠️ The vibe is that this is a temporary situation that'll get better after some delay. If the length of the delay is known, it can be put in the message 🕰️ If no delay is given, the IPP application should handle the response the same way it would for a "server-error-temporary-error" response. If the situation is more permanent, the error status codes "client-error-gone" or "client-error-not-found" could be used instead. 🪧
13.1.5.4 server-error-version-not-supported (0x0503) 🔢
the IPP object doesn't support the IPP protocol version given as the value of the "version-number" operation parameter in the request, or it refuses to. 🙅♀️ Basically, the IPP object says it can't or won't finish the request using the same major and minor version number the client sent, except with this error message. The error response SHOULD contain a "status-message" attribute (see section 3.1.6.2) that explains why that version isn't supported and which other versions the IPP object does support. See sections 3.1.6.1, 3.1.7, and 3.1.8. 📚
The error response MUST identify, in the "version-number" operation parameter, the closest version number that the IPP object does support. 🎯 For example: if a client sends version '1.0' and an IPP/1.1 object supports version '1.0', then it responds with version '1.0' in all responses to that request. If the IPP/1.1 object doesn't support version '1.0', it should accept the request and respond with version '1.1', or it may reject the request and respond with this error code and version '1.1'. If a client sends version '1.2', the IPP/1.1 object should accept the request and return version '1.1', or it may reject the request and respond with this error code and version '1.1'. See sections 3.1.8 and 4.4.14. ✨
13.1.5.5 server-error-device-error (0x0504) 🖨️
a printer error, like a paper jam, happens while the IPP object is processing a Print or Send operation 📃 The response contains the true Job Status (the values of the "job-state" and "job-state-reasons" attributes). Extra info can come back in the OPTIONAL "job-state-message" attribute value, or in the OPTIONAL status message that describes the error in more detail. 🧠 This error status code only comes back when the Printer can't accept the create request because of that kind of device error. For example, if the Printer can't spool and can only take one job at a time, the reason it might reject a create request is that it currently has a paper jam 🫠 In lots of cases, though, the Printer object can accept the request even while the Printer has some error condition, and then the 'successful-ok' status code gets returned. 🌈 In that situation, the client should look at the returned Job Object Attributes, or ask the Printer later to figure out its state and state reasons. 💖
13.1.5.6 server-error-temporary-error (0x0505) 🌧️
okay so this one is a temporary error 🥺 Stuff like a buffer full write error, a memory overflow (aka the document data is bigger than the Printer's memory), or a disk full situation can happen while the IPP Printer is processing an operation. The client MAY try the unmodified request again later, hoping the temporary internal error has cleared up 💖 Or, as an implementation option, a Printer object MAY delay the response until the temporary condition is cleared, so no error gets returned at all ✨
13.1.5.7 server-error-not-accepting-jobs (0x0506) 🙅♀️
this is a temporary error saying the Printer isn't accepting jobs right now, because the administrator set the Printer's "printer-is-accepting-jobs" attribute to 'false' 💅 (and that happens by means outside the scope of this IPP/1.1 document, so not our problem here 🙈)
13.1.5.8 server-error-busy (0x0507) 🐝
another temporary one! The Printer is just too busy processing jobs and/or other requests 😭 The client SHOULD try the unmodified request again later, expecting the busy condition to have been cleared 🫶
13.1.5.9 server-error-job-canceled (0x0508) 🚫
this error means the job got canceled by an operator or the system while the client was still sending the data to the IPP Printer 💀 If a job-id and job-uri had already been created, they get returned in the Print-Job, Send-Document, or Send-URI response as usual 🎀 Otherwise, no job-id and job-uri come back in the response.
13.1.5.10 server-error-multiple-document-jobs-not-supported (0x0509) 🙃
the IPP object doesn't support multiple documents per job, and a client tried to send document data with a second Send-Document or Send-URI operation. Not it, sweetie 🍓
13.2 Status Codes for IPP Operations 📋
okay the tables are giving main character energy 🦋 Here's the key first:
PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document
SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and
Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job
IPP Operations
IPP Status Keyword PJ PU CJ SD SU V GA GJ C
------------------ -- -- -- -- -- - -- -- -
successful-ok x x x x x x x x x
successful-ok-ignored-or-substituted- x x x x x x x x x
attributes
successful-ok-conflicting-attributes x x x x x x x x x
client-error-bad-request x x x x x x x x x
client-error-forbidden x x x x x x x x x
client-error-not-authenticated x x x x x x x x x
client-error-not-authorized x x x x x x x x x
client-error-not-possible x x x x x x x x x
client-error-timeout x x
client-error-not-found x x x x x x x x x
client-error-gone x x x x x x x x x
client-error-request-entity-too-large x x x x x x x x x
client-error-request-value-too-long x x x x x x x x x
client-error-document-format-not- x x x x x x
supported
client-error-attributes-or-values-not- x x x x x x x x x
supported
client-error-uri-scheme-not-supported x x
client-error-charset-not-supported x x x x x x x x x
client-error-conflicting-attributes x x x x x x x x x
client-error-compression-not-supported x x x x x
client-error-compression-error x x x x
client-error-document-format-error x x x x
client-error-document-access-error x x
server-error-internal-error x x x x x x x x x
server-error-operation-not-supported x x x x
server-error-service-unavailable x x x x x x x x x
server-error-version-not-supported x x x x x x x x x
server-error-device-error x x x x x
server-error-temporary-error x x x x x
server-error-not-accepting-jobs x x x x
server-error-busy x x x x x x x x x
server-error-job-canceled x x x
server-error-multiple-document-jobs- x x
not-supportedand here's the second batch, for the rest of the operations 💜
HJ = Hold-Job, RJ = Release-Job, RS = Restart-Job
PP = Pause-Printer, RP = Resume-Printer, PJ = Purge-Jobs
IPP Operations (cont.)
IPP Status Keyword HJ RJ RS PP RP PJ
------------------ -- -- -- -- -- --
successful-ok x x x x x x
successful-ok-ignored-or-substituted- x x x x x x
attributes
successful-ok-conflicting-attributes x x x x x x
client-error-bad-request x x x x x x
client-error-forbidden x x x x x x
client-error-not-authenticated x x x x x x
client-error-not-authorized x x x x x x
client-error-not-possible x x x x x x
client-error-timeout
client-error-not-found x x x x x x
client-error-gone x x x x x x
client-error-request-entity-too-large x x x x x x
client-error-request-value-too-long x x x x x x
client-error-document-format-not-
supported
client-error-attributes-or-values-not- x x x x x x
supported
client-error-uri-scheme-not-supported
client-error-charset-not-supported x x x x x x
client-error-conflicting-attributes x x x x x x
client-error-compression-not-supported
client-error-compression-error
client-error-document-format-error
client-error-document-access-error
server-error-internal-error x x x x x x
server-error-operation-not-supported x x x x x x
server-error-service-unavailable x x x x x x
server-error-version-not-supported x x x x x x
server-error-device-error
server-error-temporary-error x x x x x x
server-error-not-accepting-jobs
server-error-busy x x x x x x
server-error-job-canceled
server-error-multiple-document-jobs-
not-supported14. APPENDIX C: "media" keyword values 🎀
okay so standard keyword values come from a few different places 🧚 Standard values are defined (taken from DPA[ISO10175] and the Printer MIB[RFC1759]):
'default': The default medium for the output device'iso-a4-white': Specifies the ISO A4 white medium: 210 mm x 297 mm'iso-a4-colored': Specifies the ISO A4 colored medium: 210 mm x 297 mm'iso-a4-transparent'Specifies the ISO A4 transparent medium: 210 mm x 297 mm'iso-a3-white': Specifies the ISO A3 white medium: 297 mm x 420 mm'iso-a3-colored': Specifies the ISO A3 colored medium: 297 mm x 420 mm'iso-a5-white': Specifies the ISO A5 white medium: 148 mm x 210 mm'iso-a5-colored': Specifies the ISO A5 colored medium: 148 mm x 210 mm'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm'iso-b4-colored': Specifies the ISO B4 colored medium: 250 mm x 353 mm'iso-b5-white': Specifies the ISO B5 white medium: 176 mm x 250 mm'iso-b5-colored': Specifies the ISO B5 colored medium: 176 mm x 250 mm'jis-b4-white': Specifies the JIS B4 white medium: 257 mm x 364 mm'jis-b4-colored': Specifies the JIS B4 colored medium: 257 mm x 364 mm'jis-b5-white': Specifies the JIS B5 white medium: 182 mm x 257 mm'jis-b5-colored': Specifies the JIS B5 colored medium: 182 mm x 257 mm
for North American paper, the standard values are 🇺🇸
'na-letter-white': Specifies the North American letter white medium'na-letter-colored': Specifies the North American letter colored medium'na-letter-transparent': Specifies the North American letter transparent medium'na-legal-white': Specifies the North American legal white medium'na-legal-colored': Specifies the North American legal colored medium
and for envelopes, the standard values are 💌
'iso-b4-envelope': Specifies the ISO B4 envelope medium'iso-b5-envelope': Specifies the ISO B5 envelope medium'iso-c3-envelope': Specifies the ISO C3 envelope medium'iso-c4-envelope': Specifies the ISO C4 envelope medium'iso-c5-envelope': Specifies the ISO C5 envelope medium'iso-c6-envelope': Specifies the ISO C6 envelope medium'iso-designated-long-envelope': Specifies the ISO Designated Long envelope medium'na-10x13-envelope': Specifies the North American 10x13 envelope medium'na-9x12-envelope': Specifies the North American 9x12 envelope medium'monarch-envelope': Specifies the Monarch envelope'na-number-10-envelope': Specifies the North American number 10 business envelope medium'na-7x9-envelope': Specifies the North American 7x9 inch envelope'na-9x11-envelope': Specifies the North American 9x11 inch envelope'na-10x14-envelope': Specifies the North American 10x14 inch envelope'na-number-9-envelope': Specifies the North American number 9 business envelope'na-6x9-envelope': Specifies the North American 6x9 inch envelope'na-10x15-envelope': Specifies the North American 10x15 inch envelope
the following standard values are defined for the less commonly used media: ✨
'executive-white': Specifies the white executive medium
'folio-white': Specifies the folio white medium
'invoice-white': Specifies the white invoice medium
'ledger-white': Specifies the white ledger medium
'quarto-white': Specified the white quarto medium
'iso-a0-white': Specifies the ISO A0 white medium: 841 mm x 1189 mm
'iso-a0-transparent': Specifies the ISO A0 transparent medium: 841 mm
x 1189 mm
'iso-a0-translucent': Specifies the ISO A0 translucent medium: 841 mm
x 1189 mm
'iso-a1-white': Specifies the ISO A1 white medium: 594 mm x 841 mm
'iso-a1-transparent': Specifies the ISO A1 transparent medium: 594 mm
x 841 mm
'iso-a1-translucent': Specifies the ISO A1 translucent medium: 594 mm
x 841 mm
'iso-a2-white': Specifies the ISO A2 white medium: 420 mm x 594 mm
'iso-a2-transparent': Specifies the ISO A2 transparent medium: 420 mm
x 594 mm
'iso-a2-translucent': Specifies the ISO A2 translucent medium: 420 mm
x 594 mm
'iso-a3-transparent': Specifies the ISO A3 transparent medium: 297 mm
x 420 mm
'iso-a3-translucent': Specifies the ISO A3 translucent medium: 297 mm
x 420 mm
'iso-a4-translucent': Specifies the ISO A4 translucent medium: 210 mm
x 297 mm
'iso-a5-transparent': Specifies the ISO A5 transparent medium: 148 mm
x 210 mm
'iso-a5-translucent': Specifies the ISO A5 translucent medium: 148 mm
x 210 mm
'iso-a6-white': Specifies the ISO A6 white medium: 105 mm x 148 mm
'iso-a7-white': Specifies the ISO A7 white medium: 74 mm x 105 mm
'iso-a8-white': Specifies the ISO A8 white medium: 52 mm x 74 mm
'iso-a9-white': Specifies the ISO A9 white medium: 37 mm x 52 mm
'iso-a10-white': Specifies the ISO A10 white medium: 26 mm x 37 mm
'iso-b0-white': Specifies the ISO B0 white medium: 1000 mm x 1414 mm
'iso-b1-white': Specifies the ISO B1 white medium: 707 mm x 1000 mm
'iso-b2-white': Specifies the ISO B2 white medium: 500 mm x 707 mm
'iso-b3-white': Specifies the ISO B3 white medium: 353 mm x 500 mm
'iso-b6-white': Specifies the ISO B6 white medium: 125 mm x 176 mm
'iso-b7-white': Specifies the ISO B7 white medium: 88 mm x 125 mm
'iso-b8-white': Specifies the ISO B8 white medium: 62 mm x 88 mm
'iso-b9-white': Specifies the ISO B9 white medium: 44 mm x 62 mm
'iso-b10-white': Specifies the ISO B10 white medium: 31 mm x 44 mm
'jis-b0-white': Specifies the JIS B0 white medium: 1030 mm x 1456 mm
'jis-b0-transparent': Specifies the JIS B0 transparent medium: 1030
mm x 1456 mm
'jis-b0-translucent': Specifies the JIS B0 translucent medium: 1030
mm x 1456 mm
'jis-b1-white': Specifies the JIS B1 white medium: 728 mm x 1030 mm
'jis-b1-transparent': Specifies the JIS B1 transparent medium: 728 mm
x 1030 mm
'jis-b1-translucent': Specifies the JIS B1 translucent medium: 728 mm
x 1030 mm
'jis-b2-white': Specifies the JIS B2 white medium: 515 mm x 728 mm
'jis-b2-transparent': Specifies the JIS B2 transparent medium: 515 mm
x 728 mm
'jis-b2-translucent': Specifies the JIS B2 translucent medium: 515 mm
x 728 mm
'jis-b3-white': Specifies the JIS B3 white medium: 364 mm x 515 mm
'jis-b3-transparent': Specifies the JIS B3 transparent medium: 364 mm
x 515 mm
'jis-b3-translucent': Specifies the JIS B3 translucent medium: 364 mm
x 515 mm
'jis-b4-transparent': Specifies the JIS B4 transparent medium: 257 mm
x 364 mm
'jis-b4-translucent': Specifies the JIS B4 translucent medium: 257 mm
x 364 mm
'jis-b5-transparent': Specifies the JIS B5 transparent medium: 182 mm
x 257 mm
'jis-b5-translucent': Specifies the JIS B5 translucent medium: 182 mm
x 257 mm
'jis-b6-white': Specifies the JIS B6 white medium: 128 mm x 182 mm
'jis-b7-white': Specifies the JIS B7 white medium: 91 mm x 128 mm
'jis-b8-white': Specifies the JIS B8 white medium: 64 mm x 91 mm
'jis-b9-white': Specifies the JIS B9 white medium: 45 mm x 64 mm
'jis-b10-white': Specifies the JIS B10 white medium: 32 mm x 45 mmOkay, next up is the American Standard (i.e. ANSI) engineering media crew 📐✨ these are the ones you'll see on the engineering side of things 💜
'a-white': Specifies the engineering ANSI A size white medium: 8.5
inches x 11 inches
'a-transparent': Specifies the engineering ANSI A size transparent
medium: 8.5 inches x 11 inches
'a-translucent': Specifies the engineering ANSI A size translucent
medium: 8.5 inches x 11 inches
'b-white': Specifies the engineering ANSI B size white medium: 11
inches x 17 inches
'b-transparent': Specifies the engineering ANSI B size transparent
medium: 11 inches x 17 inches)
'b-translucent': Specifies the engineering ANSI B size translucent
medium: 11 inches x 17 inches
'c-white': Specifies the engineering ANSI C size white medium: 17
inches x 22 inches
'c-transparent': Specifies the engineering ANSI C size transparent
medium: 17 inches x 22 inches
'c-translucent': Specifies the engineering ANSI C size translucent
medium: 17 inches x 22 inches
'd-white': Specifies the engineering ANSI D size white medium: 22
inches x 34 inches
'd-transparent': Specifies the engineering ANSI D size transparent
medium: 22 inches x 34 inches
'd-translucent': Specifies the engineering ANSI D size translucent
medium: 22 inches x 34 inches
'e-white': Specifies the engineering ANSI E size white medium: 34
inches x 44 inches
'e-transparent': Specifies the engineering ANSI E size transparent
medium: 34 inches x 44 inches
'e-translucent': Specifies the engineering ANSI E size translucent
medium: 34 inches x 44 inchesNow the synchro-cut ones 🔪✂️ these are for devices that can do the "synchro-cut" feature (see section 14.1) 💅
'axsynchro-white': Specifies the roll paper having the width of the
longer edge (11 inches) of the engineering ANSI A size white medium
and cuts synchronizing with data.
'axsynchro-transparent': Specifies the roll paper having the width of
the longer edge (11 inches) of the engineering ANSI A size
transparent medium and cuts synchronizing with data.
'axsynchro-translucent': Specifies the roll paper having the width of
the longer edge (11 inches) of the engineering ANSI A size
translucent medium and cuts synchronizing with data.
'bxsynchro-white': Specifies the roll paper having the width of the
longer edge (17 inches) of the engineering ANSI B size white medium
and cuts synchronizing with data.
'bxsynchro-transparent': Specifies the roll paper having the width of
the longer edge (17 inches) of the engineering ANSI B size
transparent medium and cuts synchronizing with data.
'bxsynchro-translucent': Specifies the roll paper having the width of
the longer edge (17 inches) of the engineering ANSI B size
translucent medium and cuts synchronizing with data.
'cxsynchro-white': Specifies the roll paper having the width of the
longer edge (22 inches) of the engineering ANSI C size white medium
and cuts synchronizing with data.
'cxsynchro-transparent': Specifies the roll paper having the width of
the longer edge (22 inches) of the engineering ANSI C size
transparent medium and cuts synchronizing with data.
'cxsynchro-translucent': Specifies the roll paper having the width of
the longer edge (22 inches) of the engineering ANSI C size
translucent medium and cuts synchronizing with data.
'dxsynchro-white': Specifies the roll paper having the width of the
longer edge (34 inches) of the engineering ANSI D size white medium
and cuts synchronizing with data.
'dxsynchro-transparent': Specifies the roll paper having the width of
the longer edge (34 inches) of the engineering ANSI D size
transparent medium and cuts synchronizing with data.
'dxsynchro-translucent': Specifies the roll paper having the width of
the longer edge (34 inches) of the engineering ANSI D size
translucent medium and cuts synchronizing with data.
'exsynchro-white': Specifies the roll paper having the width of the
longer edge (44 inches) of the engineering ANSI E size white medium
and cuts synchronizing with data.
'exsynchro-transparent': Specifies the roll paper having the width of
the longer edge (44 inches) of the engineering ANSI E size
transparent medium and cuts synchronizing with data.
'exsynchro-translucent': Specifies the roll paper having the width of
the longer edge (44 inches) of the engineering ANSI E size
translucent medium and cuts synchronizing with data.Next is the American Architectural engineering crew 🏛️🌸 these are the architectural sizes, and they're a whole different vibe 🦋
'arch-a-white': Specifies the Architectural A size white medium: 9
inches x 12 inches
'arch-a-transparent': Specifies the Architectural A size transparent
medium: 9 inches x 12 inches
'arch-a-translucent': Specifies the Architectural A size translucent
medium: 9 inches x 12 inches
'arch-b-white': Specifies the Architectural B size white medium: 12
inches x 18 inches
'arch-b-transparent': Specifies the Architectural B size transparent
medium: 12 inches x 18 inches
'arch-b-translucent': Specifies the Architectural B size translucent
medium: 12 inches x 18 inches
'arch-c-white': Specifies the Architectural C size white medium: 18
inches x 24 inches
'arch-c-transparent': Specifies the Architectural C size transparent
medium: 18 inches x 24 inches
'arch-c-translucent': Specifies the Architectural C size translucent
medium: 18 inches x 24 inches
'arch-d-white': Specifies the Architectural D size white medium: 24
inches x 36 inches
'arch-d-transparent': Specifies the Architectural D size transparent
medium: 24 inches x 36 inches
'arch-d-translucent': Specifies the Architectural D size translucent
medium: 24 inches x 36 inches
'arch-e-white': Specifies the Architectural E size white medium: 36
inches x 48 inches
'arch-e-transparent': Specifies the Architectural E size transparent
medium: 36 inches x 48 inches
'arch-e-translucent': Specifies the Architectural E size translucent
medium: 36 inches x 48 inchesAnd last but not least, the architectural synchro-cut ones 🪄 same deal as before, for devices with the "synchro-cut" feature (see section 14.1) 🫶
'arch-axsynchro-white': Specifies the roll paper having the width of
the longer edge (12 inches) of the Architectural A size white
medium and cuts synchronizing with data.
'arch-axsynchro-transparent': Specifies the roll paper having the
width of the longer edge (12 inches) of the Architectural A size
transparent medium and cuts synchronizing with data.Okay so the arch sizes are giving big roll-paper energy 🎀 Each one is the width of the longer edge, and every single one of them cuts in sync with the data ✂️
arch-axsynchro-translucent: roll paper that's 12 inches across the longer edge, matching the Architectural A size translucent medium, with cuts synchronizing with data 🦋arch-bxsynchro-white: roll paper that's 18 inches across the longer edge, matching the Architectural B size white medium, with cuts synchronizing with data 🤍arch-bxsynchro-transparent: roll paper that's 18 inches across the longer edge, matching the Architectural B size transparent medium, with cuts synchronizing with data 🫧arch-bxsynchro-translucent: roll paper that's 18 inches across the longer edge, matching the Architectural B size translucent medium, with cuts synchronizing with data 🌸arch-cxsynchro-white: roll paper that's 24 inches across the longer edge, matching the Architectural C size white medium, with cuts synchronizing with data ✨arch-cxsynchro-transparent: roll paper that's 24 inches across the longer edge, matching the Architectural C size transparent medium, with cuts synchronizing with data 💜arch-cxsynchro-translucent: roll paper that's 24 inches across the longer edge, matching the Architectural C size translucent medium, with cuts synchronizing with data 🧚arch-dxsynchro-white: roll paper that's 36 inches across the longer edge, matching the Architectural D size white medium, with cuts synchronizing with data 👑arch-dxsynchro-transparent: roll paper that's 36 inches across the longer edge, matching the Architectural D size transparent medium, with cuts synchronizing with data 🍓arch-dxsynchro-translucent: roll paper that's 36 inches across the longer edge, matching the Architectural D size translucent medium, with cuts synchronizing with data 🌈arch-exsynchro-white: roll paper that's 48 inches across the longer edge, matching the Architectural E size white medium, with cuts synchronizing with data 🔥arch-exsynchro-transparent: roll paper that's 48 inches across the longer edge, matching the Architectural E size transparent medium, with cuts synchronizing with data 💅arch-exsynchro-translucent: roll paper that's 48 inches across the longer edge, matching the Architectural E size translucent medium, with cuts synchronizing with data 🫶
Next up are the ISO engineering media 🗂️ These are Japanese and European Standard (i.e. ISO) sizes, and they're long fixed sizes [ASME-Y14.1M]. The ones below are the ISO A1 family, where the longer edge is 841 mm. Quick heads-up, bestie: the quotes and that stray space in a couple of these keywords are exactly how the original spells them, so I kept them 1:1 💖
'iso-a1x3-white': the ISO A1X3 white medium, with the longer edge at 841 mm of the ISO A1 medium ⭐'iso-a1x3-transparent': the ISO A1X3 transparent medium, with the longer edge at 841 mm of the ISO A1 medium 🦋'iso-a1x3-translucent': the ISO A1X3 translucent medium, with the longer edge at 841 mm of the ISO A1 medium 🌸'iso-a1x4-white': the ISO A1X4 white medium, with the longer edge at 841 mm of the ISO A1 medium 🤍'iso-a1x4-transparent': the ISO A1X4 transparent medium, with the longer edge at 841 mm of the ISO A1 medium 🫧'iso-a1x4- translucent': the ISO A1X4 translucent medium, with the longer edge at 841 mm of the ISO A1 medium 🎀
Now the ISO A2 family, where the longer edge is 594 mm 📐
'iso-a2x3-white': the ISO A2X3 white medium, with the longer edge at 594 mm of the ISO A2 medium ✨'iso-a2x3-transparent': the ISO A2X3 transparent medium, with the longer edge at 594 mm of the ISO A2 medium 💜'iso-a2x3-translucent': the ISO A2X3 translucent medium, with the longer edge at 594 mm of the ISO A2 medium 🧚'iso-a2x4-white': the ISO A2X4 white medium, with the longer edge at 594 mm of the ISO A2 medium 👑'iso-a2x4-transparent': the ISO A2X4 transparent medium, with the longer edge at 594 mm of the ISO A2 medium 🍓'iso-a2x4-translucent': the ISO A2X4 translucent medium, with the longer edge at 594 mm of the ISO A2 medium 🌈'iso-a2x5-white': the ISO A2X5 white medium, with the longer edge at 594 mm of the ISO A2 medium 🔥'iso-a2x5-transparent': the ISO A2X5 transparent medium, with the longer edge at 594 mm of the ISO A2 medium 💅'iso-a2x5-translucent': the ISO A2X5 translucent medium, with the longer edge at 594 mm of the ISO A2 medium 🫶
Next, the ISO A3 family, where the longer edge is 420 mm 🌷
'iso-a3x3-white': the ISO A3X3 white medium, with the longer edge at 420 mm of the ISO A3 medium 🤍'iso-a3x3-transparent': the ISO A3X3 transparent medium, with the longer edge at 420 mm of the ISO A3 medium 🫧'iso-a3x3-translucent': the ISO A3X3 translucent medium, with the longer edge at 420 mm of the ISO A3 medium 🎀'iso-a3x4-white': the ISO A3X4 white medium, with the longer edge at 420 mm of the ISO A3 medium ⭐'iso-a3x4-transparent': the ISO A3X4 transparent medium, with the longer edge at 420 mm of the ISO A3 medium 🦋'iso-a3x4-translucent': the ISO A3X4 translucent medium, with the longer edge at 420 mm of the ISO A3 medium 🌸'iso-a3x5-white': the ISO A3X5 white medium, with the longer edge at 420 mm of the ISO A3 medium ✨'iso-a3x5-transparent': the ISO A3X5 transparent medium, with the longer edge at 420 mm of the ISO A3 medium 💜'iso-a3x5-translucent': the ISO A3X5 translucent medium, with the longer edge at 420 mm of the ISO A3 medium 🧚'iso-a3x6-white': the ISO A3X6 white medium, with the longer edge at 420 mm of the ISO A3 medium 👑'iso-a3x6-transparent': the ISO A3X6 transparent medium, with the longer edge at 420 mm of the ISO A3 medium 🍓'iso-a3x6-translucent': the ISO A3X6 translucent medium, with the longer edge at 420 mm of the ISO A3 medium 🌈'iso-a3x7-white': the ISO A3X7 white medium, with the longer edge at 420 mm of the ISO A3 medium 🔥'iso-a3x7-transparent': the ISO A3X7 transparent medium, with the longer edge at 420 mm of the ISO A3 medium 💅'iso-a3x7-translucent'': the ISO A3X7 translucent' medium (the stray quote is in the original too 🙈), with the longer edge at 420 mm of the ISO A3 medium 🫶
Then the ISO A4 family, where the longer edge is 297 mm 📄
'iso-a4x3-white': the ISO A4X3 white medium, with the longer edge at 297 mm of the ISO A4 medium 🤍'iso-a4x3-transparent': the ISO A4X3 transparent medium, with the longer edge at 297 mm of the ISO A4 medium 🫧'iso-a4x3-translucent'': the ISO A4X3 translucent' medium, with the longer edge at 297 mm of the ISO A4 medium 🎀'iso-a4x4-white': the ISO A4X4 white medium, with the longer edge at 297 mm of the ISO A4 medium ⭐'iso-a4x4-transparent': the ISO A4X4 transparent medium, with the longer edge at 297 mm of the ISO A4 medium 🦋'iso-a4x4-translucent': the ISO A4X4 translucent medium, with the longer edge at 297 mm of the ISO A4 medium 🌸'iso-a4x5-white': the ISO A4X5 white medium, with the longer edge at 297 mm of the ISO A4 medium ✨'iso-a4x5-transparent': the ISO A4X5 transparent medium, with the longer edge at 297 mm of the ISO A4 medium 💜'iso-a4x5-translucent': the ISO A4X5 translucent medium, with the longer edge at 297 mm of the ISO A4 medium 🧚'iso-a4x6-white': the ISO A4X6 white medium, with the longer edge at 297 mm of the ISO A4 medium 👑'iso-a4x6-transparent': the ISO A4X6 transparent medium, with the longer edge at 297 mm of the ISO A4 medium 🍓'iso-a4x6-translucent': the ISO A4X6 translucent medium, with the longer edge at 297 mm of the ISO A4 medium 🌈'iso-a4x7-white': the ISO A4X7 white medium, with the longer edge at 297 mm of the ISO A4 medium 🔥'iso-a4x7-transparent': the ISO A4X7 transparent medium, with the longer edge at 297 mm of the ISO A4 medium 💅'iso-a4x7-translucent': the ISO A4X7 translucent medium, with the longer edge at 297 mm of the ISO A4 medium 🫶'iso-a4x8-white': the ISO A4X8 white medium, with the longer edge at 297 mm of the ISO A4 medium 🤍'iso-a4x8-transparent': the ISO A4X8 transparent medium, with the longer edge at 297 mm of the ISO A4 medium 🫧'iso-a4x8-translucent': the ISO A4X8 translucent medium, with the longer edge at 297 mm of the ISO A4 medium 🎀'iso-a4x9-white': the ISO A4X9 white medium, with the longer edge at 297 mm of the ISO A4 medium ⭐'iso-a4x9-transparent': the ISO A4X9 transparent medium, with the longer edge at 297 mm of the ISO A4 medium 🦋'iso-a4x9-translucent': the ISO A4X9 translucent medium, with the longer edge at 297 mm of the ISO A4 medium 🌸
Last but not least, the ISO sizes that come either as a long fixed size [ASME-Y14.1M] or as roll feed, for devices that offer the "synchro-cut" feature (see section 14.1) 🎬
'iso-a0xsynchro-white': the paper with the longer edge at 1189 mm of the ISO A0 white medium, with cuts synchronizing with data 👑✨'iso-a0xsynchro-transparent': Specifies the paper having the width of the longer edge (1189 mm) of the ISO A0 transparent medium and cuts synchronizing with data. 🦋'iso-a0xsynchro-translucent': Specifies the paper having the width of the longer edge (1189 mm) of the ISO A0 translucent medium and cuts synchronizing with data. 🌸'iso-a1xsynchro-white': Specifies the paper having the width of the longer edge (841 mm) of the ISO A1 white medium and cuts synchronizing with data. ✨'iso-a1xsynchro-transparent': Specifies the paper having the width of the longer edge (841 mm) of the ISO A1 transparent medium and cuts synchronizing with data. 🧚'iso-a1xsynchro-translucent': Specifies the paper having the width of the longer edge (841 mm) of the ISO A1 translucent medium and cuts synchronizing with data. 💜'iso-a2xsynchro-white': Specifies the paper having the width of the longer edge (594 mm) of the ISO A2 white medium and cuts synchronizing with data. 🎀'iso-a2xsynchro-transparent': Specifies the paper having the width of the longer edge (594 mm) of the ISO A2 transparent medium and cuts synchronizing with data. 🍓'iso-a2xsynchro-translucent': Specifies the paper having the width of the longer edge (594 mm) of the ISO A2 translucent medium and cuts synchronizing with data. 💖'iso-a3xsynchro-white': Specifies the paper having the width of the longer edge (420 mm) of the ISO A3 white medium and cuts synchronizing with data. 🌈'iso-a3xsynchro-transparent': Specifies the paper having the width of the longer edge (420 mm) of the ISO A3 transparent medium and cuts synchronizing with data. ⭐'iso-a3xsynchro-translucent': Specifies the paper having the width of the longer edge (420 mm) of the ISO A3 translucent medium and cuts synchronizing with data. 🫶'iso-a4xsynchro-white': Specifies the paper having the width of the longer edge (297 mm) of the ISO A4 white medium and cuts synchronizing with data. 💅'iso-a4xsynchro-transparent': Specifies the paper having the width of the longer edge (297 mm) of the ISO A4 transparent medium and cuts synchronizing with data. 👑'iso-a4xsynchro-translucent': Specifies the paper having the width of the longer edge (297 mm) of the ISO A4 transparent medium and cuts synchronizing with data. 🙈
Okay so these next ones are for the big engineering stuff 📐 Bestie, these come from American Standard (ANSI) engineering media, American Architectural engineering media, and Japanese and European Standard (ISO) engineering media. They're either a long fixed size [ASME-Y14.1M] or roll feed, and they're for devices that do the synchro-cut feature and/or the auto-select feature (see section 14.1). Main character energy, honestly. 💖
'auto-white': Specifies that the printer selects the white medium with the appropriate fixed size (e.g. a1, a2, etc.) or data-synchro size, and the selection is implementation-defined. ✨'auto-transparent': Specifies that the printer selects the transparent medium with the appropriate fixed size (e.g. a1, a2, etc.) or data-synchro size, and the selection is implementation-defined. 🦋'auto-translucent': Specifies that the printer selects the translucent medium with the appropriate fixed size (e.g. a1, a2, etc.) or data-synchro size, and the selection is implementation-defined. 🌸'auto-fixed-size-white': Specifies that the printer selects the white medium with the appropriate fixed size (e.g. a1, a2, etc.) or the appropriate long fixed size listed above. 🧚'auto-fixed-size-transparent': Specifies that the printer selects the transparent medium with the appropriate fixed size (e.g. a1, a2, etc.) or the appropriate long fixed size listed above. 💜'auto-fixed-size-translucent': Specifies that the printer selects the translucent medium with the appropriate fixed size (e.g. a1, a2, etc.) or the appropriate long fixed size listed above. 🎀'auto-synchro-white': Specifies that the printer selects the white paper with the appropriate width and cuts it synchronizing with data. 🍓'auto-synchro-transparent': Specifies that the printer selects the transparent paper with the appropriate width and cuts it synchronizing with data. 🌈'auto-synchro-translucent': Specifies that the printer selects the translucent paper with the appropriate width and cuts it synchronizing with data. ⭐
Next up are the input trays, which are pulled from ISO DPA and the Printer MIB. Think of it as the printer's little drawers 🗄️
'top': The top input tray in the printer. 🎀'middle': The middle input tray in the printer. 🍓'bottom': The bottom input tray in the printer. 💖'envelope': The envelope input tray in the printer. ✉️'manual': The manual feed input tray in the printer. 🫶'large-capacity': The large capacity input tray in the printer. 👑'main': The main input tray 🌈'side': The side input tray 🦋
Now the media sizes, which come from ISO DPA. Bestie, the ISO A and B series are giving pure symmetry 😭🔥
'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined in ISO 216 ✨'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in ISO 216 🧚'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in ISO 216 💜'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in ISO 216 🎀'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in ISO 216 🍓'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in ISO 216 🌸'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in ISO 216 💖'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in ISO 216 🌈'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in ISO 216 ⭐'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in ISO 216 🫶'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in ISO 216 💅'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined in ISO 216 👑'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined in ISO 216 🙈'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in ISO 216 🦋'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in ISO 216 🌸'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 🧚'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in ISO 216 💜'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in ISO 216 🎀'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in ISO 216 🍓'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in ISO 216 💖'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in ISO 216 🌈'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in ISO 216 ⭐'na-letter': Specifies the North American letter size: 8.5 inches by 11 inches 🇺🇸'na-legal': Specifies the North American legal size: 8.5 inches by 14 inches 💅'na-8x10': Specifies the North American 8 inches by 10 inches 🫶'na-5x7': Specifies the North American 5 inches by 7 inches 👑'executive': Specifies the executive size (7.25 X 10.5 in) 🙈'folio': Specifies the folio size (8.5 X 13 in) 🦋'invoice': Specifies the invoice size (5.5 X 8.5 in) 🌸'ledger': Specifies the ledger size (11 X 17 in) 🧚'quarto': Specifies the quarto size (8.5 X 10.83 in) 💜'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in ISO 269 🎀'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in ISO 269 🍓'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in ISO 269 💖'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in ISO 269 🌈'iso-designated-long': Specifies the ISO Designated Long size: 110 mm by 220 mm as defined in ISO 269 ⭐'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches ✉️'na-9x12-envelope': Specifies the North American 9x12 size: 9 inches by 12 inches 🫶'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches 💅'na-7x9-envelope': Specifies the North American 7x9 inch envelope size 👑'na-9x11-envelope': Specifies the North American 9x11 inch envelope size 🙈'na-10x14-envelope': Specifies the North American 10x14 inch envelope size 🦋'na-number-9-envelope': Specifies the North American number 9 business envelope size 🌸'na-6x9-envelope': Specifies the North American 6x9 envelope size 🧚'na-10x15-envelope': Specifies the North American 10x15 envelope size 💜'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 🎀'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm 🍓'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm 💖'jis-b2': Specifies the JIS B2 size: 515mm x 728mm 🌈'jis-b3': Specifies the JIS B3 size: 364mm x 515mm ⭐'jis-b4': Specifies the JIS B4 size: 257mm x 364mm 🫶'jis-b5': Specifies the JIS B5 size: 182mm x 257mm 💅'jis-b6': Specifies the JIS B6 size: 128mm x 182mm 👑'jis-b7': Specifies the JIS B7 size: 91mm x 128mm 🙈'jis-b8': Specifies the JIS B8 size: 64mm x 91mm 🦋'jis-b9': Specifies the JIS B9 size: 45mm x 64mm 🌸'jis-b10': Specifies the JIS B10 size: 32mm x 45mm 🧚
Last bit, the American engineering sizes! These are the ANSI ones, bestie 📐
'a': Specifies the engineering ANSI A size medium: 8.5 inches x 11 inches 🎀'b': Specifies the engineering ANSI B size medium: 11 inches x 17 inches 🍓'c': Specifies the engineering ANSI C size medium: 17 inches x 22 inches 💖'd': Specifies the engineering ANSI D size medium: 22 inches x 34 inches 🌈'e': Specifies the engineering ANSI E size medium: 34 inches x 44 inches ⭐
And the American Architectural engineering sizes, which are giving architect girlie energy 🏛️
'arch-a': Specifies the Architectural A size medium: 9 inches x 12 inches 🫶'arch-b': Specifies the Architectural B size medium: 12 inches x 18 inches 💅'arch-c': Specifies the Architectural C size medium: 18 inches x 24 inches 👑'arch-d': Specifies the Architectural D size medium: 24 inches x 36 inches 🙈'arch-e': Specifies the Architectural E size medium: 36 inches x 48 inches 🦋
14.1. Examples
okay so here are some examples to supplement the engineering media value definitions 🧚✨
Example 1: "Synchro-Cut", a device cutting the roll paper in sync with the data 🎀
data height: A1 height
data width (shaded): A1 width < data width < (A1 width) x 2
specified value: 'iso-a1xsynchro-white' | |
|<--- data width --->|
| |
| | | |
|<- A1 width ->|<- A1 width ->|
| | | |
cross ^ | | | |
feed | +--------------------------------------------/
direction | |//////////////|/////| | ^ /
| |//////////////|/////| | | /
| |//////////////|/////| | | /
| |//////////////|/////| | | \
<-----------+- |//////////////|/////| | A1 \ roll
feed | |//////////////|/////| | height \ paper
direction |//////////////|/////| | | \
|//////////////|/////| | | /
|//////////////|/////| | v /
+------------------------------------------/
|
|
|<------ CUT HERE (to synchronize
| with data width)
|Example 2: "Auto-Cut", a device cutting the roll paper at multiples of a fixed-size media width 🦋
data height: A1 height
data width (shaded): A1 width < data width < (A1 width) x 2
specified value: 'auto-fixed-size-white' | |
|<--- data width --->|
| |
| | | |
|<- A1 width ->|<- A1 width ->|
| | | |
cross ^ | | | |
feed | +--------------------------------------------/
direction | |//////////////|/////| | ^ /
| |//////////////|/////| | | /
| |//////////////|/////| | | /
| |//////////////|/////| | | \
<-----------+- |//////////////|/////| | A1 \ roll
feed | |//////////////|/////| | height \ paper
direction |//////////////|/////| | | \
|//////////////|/////| | | /
|//////////////|/////| | v /
+------------------------------------------/
|
|
|<--- CUT HERE
| (to synchronize
| with data width)Example 3: the 'iso-a4x4-white' fixed size paper 📄
paper height: A4 height
paper width: (A4 width) x 4
specified value: 'iso-a4x4-white' | | | | |
|<- A4 width ->|<- A4 width ->|<- A4 width ->|<- A4 width ->|
| | | | |
| | | | |
+-----------------------------------------------------------+
| ^ | | | |
| | | | | |
| | | | | |
| A4 | | | |
| height | | | |
| | | | | |
| | | | | |
| | | | | |
| v | | | |
+-----------------------------------------------------------+Example 4: "Synchro-Cut", a device cutting the fixed size paper in sync with the data 💜
data height: A4 height
data width (shaded): (A4 width) x 2 < data width < (A4 width) x 3
specified value: 'iso-a4xsynchro-white' | |
|<---------- data width ----------->|
| |
| | | | |
|<- A4 width ->|<- A4 width ->|<- A4 width ->|
| | | | |
cross ^ | | | | |
feed | +--------------------------------------------+
direction | |//////////////|//////////////|/////| ^ |
| |//////////////|//////////////|/////| | |
| |//////////////|//////////////|/////| | |
| |//////////////|//////////////|/////| | |
<-----------+- |//////////////|//////////////|/////| A4 |
feed | |//////////////|//////////////|/////| height |
direction |//////////////|//////////////|/////| | |
|//////////////|//////////////|/////| | |
|//////////////|//////////////|/////| v |
+--------------------------------------------+
|
CUT HERE ---->|
(to synchronize |
with data width) |15. APPENDIX D: Processing IPP Attributes 🌈
okay bestie, so when you send a print job to a Printer object, the IPP model lets the client attach operation and Job Template attributes along with the document data. Those Job Template attributes in the create request shape how the documents in the job get rendered, produced and finished 🖨️✨ The print data can carry its own instructions too, so they're embedded right inside the document. On top of that, the Printer has its own set of attributes that list which rendering and finishing options it actually supports.
This model is super flexible and powerful, but it also means the client's attributes can clash at submission time with:
- what the implementation can actually do (so, what the Printer supports), and
- the instructions embedded in the print data itself.
The next sections explain how the IPP model handles these two kinds of conflicts 💅
15.1 Fidelity
so when what the client asks for doesn't match what a Printer object supports, the client gets to pick one of two conflict handling mechanisms 🎀
- reject the job, because it can't be processed exactly as specified, or
- let the Printer make whatever changes it needs so it can process the Job the best it can.
With the first option, the client is basically saying "print it exactly as I wrote it, no exceptions, and if that's impossible, don't even bother printing." With the second, the client is saying "getting it printed matters more than getting it processed exactly; just make sure it comes out, even if some of my attributes have to be changed or ignored." 🫶
The IPP model handles this with an ipp-attribute-fidelity attribute 🧚
In a create request, ipp-attribute-fidelity is a boolean operation attribute that the client can optionally supply. The value true means total fidelity to the client's Job Template attributes and values is required. The client is asking for the Job to be printed exactly as specified, and if that's not possible, the job MUST be rejected instead of being processed incorrectly 🙅♀️ The value false means a reasonable attempt to print the Job is fine. If a Printer doesn't support some of the client's Job Template attributes or values, the Printer MUST ignore them or swap in a supported value for the unsupported ones, respectively. The Printer can choose to use the default value for that attribute, or pick some other supported value that's similar to the one that was requested. For example, if a client supplies a media value of 'na-letter', the Printer may choose to substitute 'iso-a4' instead of the default value of 'envelope'. If the client doesn't supply ipp-attribute-fidelity at all, the Printer assumes false 💖
Each Printer implementation MUST support both types of fidelity printing (whether the client supplies 'true' or 'false'):
- If the client supplies
'false', or doesn't supply the attribute at all, the Printer object MUST always accept the request by ignoring unsupported Job Template attributes and by replacing unsupported values of supported Job Template attributes with supported values. - If the client supplies
'true', the Printer object MUST reject the request if the client supplies unsupported Job Template attributes.
Since a client can always ask a Printer exactly what it does and doesn't support, ipp-attribute-fidelity set to 'false' is really useful when:
- The End-User is using a command line interface and asks for attributes that might not be supported 💻
- In a GUI context, the End User thinks the job might get moved to another printer and would rather have a sub-optimal result than nothing at all 🌸
- The End User just wants something reasonable instead of nothing at all 🍓
15.2 Page Description Language (PDL) Override ✨
okay so bestie, what happens when the job's settings and the document itself disagree? 💅 If an IPP Job Template attribute conflicts with a matching instruction inside the document data, the IPP attribute SHOULD take precedence over the document instruction. 🎀
Picture this: someone has a file that's already formatted, and it has embedded commands to load 'iso-a4' paper 📄. But the person printing it only has a printer with 'na-letter' loaded 😭. They'd obviously want to send it to an IPP Printer with the media Job Template attribute set to 'na-letter', so the job submission attribute should win over the baked-in PDL instruction. The tea is that until the companies that make document data interpreters let outside IPP attributes beat embedded job instructions, a Printer might not be able to actually support that. 🥺
The IPP model handles this with a "pdl-override-supported" attribute, which tells you what the Printer object can do about overriding instructions embedded in the PDL data stream. How that value gets set is outside the scope of this IPP/1.1 document 🔧.
This REQUIRED Printer attribute can be one of these values:
'attempted': the Printer object tries to make the IPP attribute values win over embedded instructions in the document data, but there's no guarantee 🤞.'not-attempted': the Printer object makes no attempt to make the IPP attribute values win over embedded instructions in the document data 🙅♀️.
At job processing time, an implementation that supports 'attempted' might do any of these things:
- Generate an output device specific command sequence that realizes the feature the IPP attribute value represents.
- Parse the document data itself and swap the conflicting embedded instruction for a new one that matches the intent of the IPP attribute value.
- Tell the Printer that externally supplied attributes take precedence over embedded instructions, then pass those external IPP attribute values to the document data interpreter.
- Anything else that gives the semantics that IPP attributes override embedded document data instructions 🧚.
Since 'attempted' doesn't promise anything, a Printer object might not be super "good" at trying to get IPP attributes to beat the embedded instructions, and it would still be a conforming implementation 🌸.
At job processing time, an implementation that supports 'not-attempted' might do one of the following:
- Simply pre-pend the document data with the PDL instruction that matches the client-supplied PDL attribute. If the document data has the same PDL instruction too, it overrides what the Printer object pre-pended. In other words, this implementation handles client-supplied IPP attributes the same way it handles the Printer object's defaults 🍓.
- Parse the document data and replace the conflicting embedded instruction with a new one that approximates, but doesn't match, the semantic intent of the IPP attribute value.
Note: the "ipp-attribute-fidelity" attribute is about whether the Printer accepts or rejects other unsupported Job Template attributes 👀. So if "ipp-attribute-fidelity" is set to 'true', a Job is accepted if and only if the client-supplied Job Template attributes and values are supported by the Printer. Whether those attributes actually change how the Job gets processed when the document data has embedded instructions depends on whether the Printer can override those instructions with the semantics of the IPP attributes. If the document data can be overridden ("pdl-override-supported" set to 'attempted'), the Printer tries to use the IPP attributes when processing the Job 💪. If the document data can't be overridden ("pdl-override-supported" set to 'not-attempted'), the Printer makes no attempt to override the embedded document data instructions with the IPP attributes. That means the IPP attributes may fail to affect the Job processing and output when the matching instruction is embedded in the document data 💀.
15.3 Using Job Template Attributes During Document Processing.
okay now the fun part: how the Printer object actually uses a Job's Job Template attributes while it processes each document's data 🧠. These include, but aren't limited to, "orientation-requested", "number-up", "sides", "media", and "copies" 🎀. Every document in a Job Object MUST follow the steps below 📋. These steps are only there to show when and how the attributes get used in processing document data. Any alternative steps that get the same effect can be used to implement this specification document ✨.
- Use the client-supplied "document-format" attribute, or some form of document format detection algorithm if "document-format" isn't specific enough, to figure out whether the document data has already been formatted for printing. If it has, go to step 2. Otherwise, the document data MUST be formatted. The formatting detection algorithm is implementation defined and isn't specified by this document 🤷♀️. Formatting the document data uses the "orientation-requested" attribute to decide how the formatted print data should be placed on a print-stream page. See section 4.2.10 for the details 📐.
- The document data is a print-stream in a known media type 🎞️. The "page-ranges" attribute picks out, as specified in section 4.2.7, a sub-sequence of the pages in the print-stream that are to be processed and images.
- The input to this step is a sequence of print-stream pages 📚. This step is controlled by the "number-up" attribute. If the value of "number-up" is N, then while the print-stream pages are processed, each group of N print-stream pages gets positioned, as specified in section 4.2.9, to create a single impression 🖼️. If a given document doesn't have N more print-stream pages, the completion of the impression is controlled by the "multiple-document-handling" attribute, as described in section 4.2.4. When that attribute's value is 'single-document' or 'single-document-new-sheet', the print-stream pages from subsequent documents are used to complete the impression 🧩.
The size (scaling), position (translation) and rotation of the print-stream pages on the impression is implementation defined 🌀. During this process, the print-stream pages may be rendered into a form suitable for placing on the impression. That rendering is controlled by the values of the "printer-resolution" and "print-quality" attributes, as described in sections 4.2.12 and 4.2.13 🖨️. When N=1, the impression is almost the same as the print-stream page. The only differences would be the size, position and rotation of the print-stream page, and/or any decoration (like a frame around the page) that the implementation adds 🖤.
- The collection of impressions gets placed, in sequence, onto the sides of the media sheets 📑. This placement is controlled by the "sides" attribute and the orientation of the print-stream page, as described in section 4.2.8. The orientation of the print-stream pages affects the orientation of the impression. For example, if "number-up" equals 2, then typically two portrait print-stream pages become one landscape impression 🔄. Also, the placement of impressions onto media sheets is controlled by the "multiple-document-handling" attribute, as described in section 4.2.4 💜.
- The "copies" and "multiple-document-handling" attributes decide how many copies of each media instance get created and in what order. See sections 4.2.5 and 4.2.4 for the details 👯.
- Once the correct number of copies exists, the media instances get finished according to the values of the "finishings" attribute, as described in 4.2.6 🎉. Heads up: sometimes finishing operations need manual intervention to be performed on the copies, especially uncollated copies 🙈. This document allows any or all of the processing steps to be performed automatically or manually, at the discretion of the Printer object 🫶.
16. APPENDIX E: Generic Directory Schema ✨
okay so this section is all about a generic schema for an entry in a directory service 📂. A directory service is basically how service users find service providers 🔍. In IPP land, an IPP Printer can get registered as a directory entry of type printer, either automatically or with a little help from an admin 🧚. The how is up to the implementation (entry attributes, entry type fields, specific branches, whatever works). Directory clients can search or browse for printer entries, look things up by naming or organizational context, or run filtered searches on attribute values. For example, a client can find every printer in the "Local Department" context 🏢. Authentication and authorization usually come along for the ride too, so an admin can limit end users to only finding entries they have the access rights for 🔒. IPP itself doesn't require any specific directory service protocol or provider, so no commitments there 💅.
Note: some directory implementations support "aliasing" 🎭. That means one directory entry object can show up as multiple directory entry objects, each with a different name. Every alias points back to the same directory entry object, and that one entry refers to a single IPP Printer object.
The generic schema is a subset of the IPP Printer Job Template and Printer Description attributes (Sections 4.2 and 4.4). These attributes get labeled as either RECOMMENDED or OPTIONAL for the directory entry itself. This labeling is NOT the same labeling used for attributes of IPP Printer objects 🙈. The labeling in this Appendix is meant for directory templates and for IPP Printer implementations that sign up by adding one or more entries to a directory. RECOMMENDED attributes SHOULD be associated with each directory entry. OPTIONAL attributes MAY be associated with the directory entry (if known or supported). On top of that, all directory entry attributes SHOULD reflect the current attribute values of the corresponding Printer object 💜.
Names of attributes in the directory schema and in entries SHOULD match the IPP Printer attribute names as closely as possible ✨.
So how does the directory actually connect to the IPP Printer object? 🌉 One of the RECOMMENDED directory entry attributes is the Printer object's "printer-uri-supported" attribute. The directory client queries "printer-uri-supported" (or its equivalent) in the directory entry, and then the IPP client talks to the IPP Printer object using one of its URIs 🦋. The "uri-security-supported" attribute tells you which protocol (if any) is used to secure a channel 🔐.
The following attributes define the generic schema for directory entries of type PRINTER:
printer-uri-supported RECOMMENDED Section 4.4.1
uri-authentication-supported RECOMMENDED Section 4.4.2
uri-security-supported RECOMMENDED Section 4.4.3
printer-name RECOMMENDED Section 4.4.4
printer-location RECOMMENDED Section 4.4.5
printer-info OPTIONAL Section 4.4.6
printer-more-info OPTIONAL Section 4.4.7
printer-make-and-model RECOMMENDED Section 4.4.9
ipp-versions-supported RECOMMENDED Section 4.4.14
multiple-document-jobs-supported OPTIONAL Section 4.4.16
charset-supported OPTIONAL Section 4.4.18
generated-natural-language-
supported OPTIONAL Section 4.4.20
document-format-supported RECOMMENDED Section 4.4.22
color-supported RECOMMENDED Section 4.4.26
compression-supported RECOMMENDED Section 4.4.32
pages-per-minute OPTIONAL Section 4.4.36
pages-per-minute-color OPTIONAL Section 4.4.37
finishings-supported OPTIONAL Section 4.2.6
number-up-supported OPTIONAL Section 4.2.7
sides-supported RECOMMENDED Section 4.2.8
media-supported RECOMMENDED Section 4.2.11
printer-resolution-supported OPTIONAL Section 4.2.12
print-quality-supported OPTIONAL Section 4.2.1317. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1 "Model and Semantics" Documents 📝
This Appendix is split into two lists that sum up the differences between IPP/1.1 (this document) and IPP/1.0 [RFC2566] 🧁. The section numbers point to this document, and some of them have shifted since RFC 2566. When one change touches several sections, it's listed once, under the first section affected, and the other affected section numbers get mentioned alongside it.
The first list covers extensions and clarifications, and the second covers changes in semantics or conformance. Heads up though: client and IPP object implementations of IPP/1.0 MAY implement any of the extensions and clarifications in this document 🌸.
The following extensions and clarifications have been folded into this document:
- Section 2.1 - clarified that the term "client" can be either contained in software controlled by an end user or a part of a print server that controls devices.
- Section 2 - clarified that the term "IPP object" and "Printer object" can either be embedded in a device object or part of a print server that accepts IPP requests.
- Section 2.4 - added the description of the new "uri-authentication-supported" Printer Description attribute.
- Section 3.1.3, 3.1.6, 3.2.5.2, and 3.2.6.2 - clarified the error handling for operation attributes that have their own status code.
- Section 3.1.3 - clarified that multiple occurrences of the same attribute in an attribute group is mal-formed. An IPP Printer MAY reject the request or choose one of the attributes.
- Section 3.1.6 - reorganized this section into sub-sections to separately describe "status-code", "status-message", "detailed-status-message", and "document-access-error" attributes.
- Section 3.1.6.1 - clarified the error status codes and their relationship to operation attributes.
- Section 3.1.6.3 - Added the OPTIONAL "detailed-status-message (text(MAX))" operation attribute to provide additional, more detailed information about a response.
- Section 3.1.6.4 and 3.2.2 - Added the OPTIONAL "document-access-error (text(MAX))" operation attribute for use with Print-URI and Send-URI responses.
- Sections 3.1.7 - Added this new section to clarify returning Unsupported Attributes for all operations, including only returning attributes that were in the request. Moved the text from section 3.2.1.2 Unsupported Attributes to this section.
- Sections 3.1.7 and 4.1 - clarified the encoding of the "out-of-band" 'unsupported' and 'unknown' values.
- Section 3.1.8 - clarified that only the version number parameter will be carried forward into future major or minor versions of the protocol.
- Section 3.1.8 - relaxed the requirements to increment the major version number in future versions of the Model and Semantics document.
- Section 3.1.9, and 3.2.5 - added the 'processing' state to the list of job states that a job can be in after a Create-Job operation.
- Section 3.1.9 - clarified that a non-spooling Printer MAY accept zero or more subsequent jobs while processing a job and flow control them down. Subsequent create requests are rejected with the 'server-error-busy' error status.
- Section 3.2.1.1 - clarified the validation of the "compression" operation attribute and its relationship to the validation of the "document-format" attribute and returning Unsupported Attributes.
- Sections 3.2.1.1, 4.3.8, 13.1.4.16, and 13.1.4.17 - added the 'client-error-compression-not-supported' and 'client-error-compression-error' status codes and the 'unsupported-compression' and 'compression-error' job-state-reasons.
- Sections 3.2.1.1 and 4.3.8 - added 'unsupported-document-format' and 'document-format-error' job-state-reasons.
- Sections 3.2.2, 4.3.8 and 13.1.4.19 - added 'client-error-document-access-error' status code and 'document-access-error' job state reason.
- Section 3.2.5.2 and 3.2.6.2 - clarified that the Unsupported Attributes group MUST NOT include attributes not requested in the Get-Printer-Attributes request.
- Section 3.2.6 - clarified that "limit" takes precedence over "which-jobs" and "my-jobs'.
- Section 3.2.6.2 - clarified that Get-Jobs returns 'successful-ok' when no jobs to return.
- Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause-Printer, Resume-Printer, and Purge-Jobs operations.
- Section 3.3.1 - clarified that the authorization required for a Send-Document request MUST be the same user as the Create-Job or an operator.
- Section 3.3.1.1 - clarified that a Create-Job Send-Document with "last-document" = 'true' and no data is not an error; it's a job with no documents.
- Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold-Job, Release-Job, and Restart-Job operations. Clarified the Restart-Job operation so that the Printer MUST re-fetch any documents passed by-reference (Print-URI or Send-URI).
- Section 4.1 - clarified that the encoding of the out-of-band values are specified in the "Encoding and Transport" document.
- Section 4.1 - Clarified that the requirement that clients MUST NOT send "out-of-band" values in requests applies only to operations defined in this document. Other operations are allowed to define "out-of-band" values that clients can supply.
- Okay so Sections 4.1.1 and 4.1.2 got a glow-up 💅. The max
textandnamevalues of 1023 and 255 are for thetextWithoutLanguagepart of thetextWithLanguageform, so the max octets for the actual text and name data is the same with or without language. ThenaturalLanguagepart is extra on top 🫶 - Section 4.1.9 says
mimeMediaTypevalues can include any parameters from the IANA Registry, not just charset parameters 🦋 - Section 4.1.9.1 says
application/octet-streamauto-sensing can happen at create request time and/or job/document processing time ⏰ - Section 4.1.9.1 says auto-sensing means the Printer examines some number of octets of document data using an implementation-dependent method 🔍
- Section 4.1.14 says the client's localization of dateTime now includes the time zone 🌍
- Section 4.2 has xxx-supported attributes with multiple keywords and/or names, so the table got parentheses:
(1setOf (type3 keyword | name))🎀 - Section 4.2.2 added the
'indefinite'keyword to "job-hold-until" for the create operations and the Hold-Job and Restart-Job operations 🌙 - Section 4.2.6 added more enum values to the "finishings" Job Template attribute 🧁
- Section 4.2.6 clarified that landscape is a rotation of the image with respect to the medium 🔄
- Section 4.3.7 says a forwarding server that cannot get any job state MAY return the job's state as
'completed', as long as it also returns the new'queued-in-device'job state reason 📦 - Section 4.3.7.2 added the Partitioning of Job States section to clarify Job Retention, Job History, and Job Removal 🗂️
- Section 4.3.8 added the
'job-data-insufficient'job state reason to show whether enough data has arrived for the document to start being processed 📥 - Section 4.3.8 added the
'document-access-error'job state reason for an access error of any kind 🚪 - Section 4.3.8 added the
'job-queued-for-marker'job state reason to show whether the job has done some processing and is waiting for the marker 🖍️ - Section 4.3.8 added the
'unsupported-compression'and'compression-error'job state reasons for compression not supported, or a compression processing error, after the create has been accepted 🗜️ - Section 4.3.8 added the
'unsupported-document-format'and'document-format-error'job state reasons for a document not supported, or a document format processing error, after the create has been accepted 📄 - Section 4.3.8 added the
'queued-in-device'job state reason for a job that has been forwarded to a print system or device that does not provide any job status 🛸 - Section 4.3.10 added
job-detailed-status-messages (1setOf text(MAX))for returning detailed error messages 💬 - Section 4.3.11 added
job-document-access-errors (1setOf text(MAX))🔐 - Section 4.3.14.2 clarified that the recorded time is the first time processing happened since the create operation or the Restart-Job operation ⏱️
- Sections 4.3.14.2 and 4.3.14.3 clarified that the out-of-band value
'no-value'is returned if the job has not started processing or has not completed, respectively 🫥 - Section 4.3.14 added the OPTIONAL
date-time-at-creation,date-time-at-processing, anddate-time-at-completedEvent Time Job Description attributes 🕰️ - Section 4.4.3 added the
'tls'value to "uri-security-supported" 🔒 - Section 4.4.3 clarified that "uri-security-supported" is orthogonal to Client Authentication, so
'none'does not exclude Client Authentication 🪪 - Section 4.4.11 simplified the
printer-statedescriptions while generalizing to allow high-end devices that interpret one or more jobs while marking another 🖨️ It also indicated that'spool-area-full'and'stopped-partly'printer-state-reasonsmay be used to provide further state information. - Section 4.4.12 added the
'moving-to-paused'keyword value to theprinter-state-reasonsattribute for use with the Pause-Printer operation ⏸️ - Section 4.4.12 replaced the duplicate
'marker-supply-low'keyword with the missing'toner-empty'keyword for theprinter-state-reasonsattribute. (This correction was also made before RFC 2566 was published.) 🧴 - Section 4.4.12 clarified
'spool-area-full'printer-state-reasonsto include non-spooling printers, to indicate when they can and cannot accept another job 🚫 - Section 4.4.15 added the enum values to the "operations-supported" attribute for the new operations 🔢 It also clarified that the values of this attribute are encoded as any enum, namely 32-bit values.
- Section 4.4.30 clarified that the dateTime value of "printer-current-time" is on a "best efforts basis". If a proper date-time cannot be obtained, the implementation returns the
'no-value'out-of-band value. It also clarified that the time zone NEED NOT be the time zone that the people near the device use, and that the client SHOULD display the dateTime attributes in the user's local time 🌏 - Sections 4.4.36 and 4.4.37 added the OPTIONAL
pages-per-minuteandpages-per-minute-colorPrinter Description attributes 📃 - Section 5.1 clarified that the client conformance requirements apply to clients controlled by an end user and to clients in servers 🖥️
- Section 5.1 clarified that any response MAY contain additional attribute groups, attributes, attribute syntaxes, or attribute values ➕
- Section 5.1 clarified that a client SHOULD do its best to prevent a channel from being closed by a lower layer when the channel is flow controlled off by the IPP Printer 🚰
- Section 5.2 clarified that the IPP object requirements apply to objects embedded in devices or that are parts of servers 🧩
- Section 5.2.2 clarified that IPP objects MAY return operation responses that contain attribute groups, attribute names, attribute syntaxes, attribute values, and status codes that are extensions to this standard 🎁
- Section 6 changed the terminology of "private extensions" to "vendor extensions" and indicated that they are registered with IANA along with IETF standards track extensions 📝
- Section 6.7 is a brand-new section on registering out-of-band attribute values with IANA as extensions 📚
- Section 8.3 clarified the use of URIs for each Client Authentication mechanism 🔑
- Section 8.5 added the security discussion around the new operator/administrator operations 🛡️
- Section 13.1.4.16 added
client-error-compression-not-supported (0x040F)💥 - Section 13.1.4.17 added
client-error-compression-error (0x0410)💥 - Section 13.1.4.18 added
client-error-document-format-error (0x0411)💥 - Section 13.1.4.19 added
client-error-document-access-error (0x0412)💥 - Section 13.1.5.10 added
server-error-multiple-document-jobs-not-supported (0x0509)💥 - Section 14 added
'a-white','b-white','c-white','d-white', and'e-white', and clarified that the existing'a','b','c','d', and'e'values are size values 📐 It also added American, Japanese, and European Engineering sizes, filled out -transparent and - translucent media names and drawings for the synchro cut sizes ✨ - Section 16 softened the RECOMMENDATION for IPP Printer attributes in a Directory schema so that they can have equivalents 📖
- Section 16 added the OPTIONAL
pages-per-minuteandpages-per-minute-colorPrinter attributes to the Directory schema 📖 - Section 16 added OPTIONAL
multiple-document-jobs-supportedto the Directory schema 📖 - Section 16 added RECOMMENDED
uri-authentication-supported,ipp-versions-supported, andcompression-supportedto the Directory schema 📖
The following changes in semantics and/or conformance have been incorporated into this document, and these are the big-deal ones 👑:
- Section 3.1.6.3 allowed a Printer to localize the "detailed-status-message" operation response attribute, but it indicated that such localization might obscure the technical meaning of such messages 🌐
- Sections 3.1.8, 5.2.4, and 13.1.5.4: Clients and IPP objects MUST support version 1.1 conformance requirements. It is recommended that they interoperate with 1.0. It also clarified that IPP Printers MUST accept
'1.1'requests. It is recommended that they also accept'1.x'requests. Version 1.1 is the main character now 🌈 - Sections 3.2.1.1 and section 4.4.32 changed the
compressionoperation and thecompression-supportedPrinter Description attribute from OPTIONAL to REQUIRED 🗜️ - Sections 3.2.1.2 and 4.3.8 changed
job-state-reasonsfrom RECOMMENDED to REQUIRED, so thatjob-state-reasonsMUST be returned in create operation responses 🙌 - Sections 3.2.4, 3.3.1, 4.4.16, and 16 changed Create-Job/Send-Document so that they MAY be implemented while only supporting one document job. Added the
multiple-document-jobs-supportedboolean Printer Description attribute to indicate whether Create-Job/Send-Document supports multiple document jobs or not. Added to the Directory schema 📚 - Section 4.1.9 deleted
text/plain; charset=iso-10646-ucs-2, since binary is not legal with thetexttype 🚫 - Section 4.1.9.1 added the RECOMMENDATION that a Printer indicate, by printing on the job's job-start-sheet, that auto-sensing has occurred and what document format was auto-sensed 🖨️
- Section 4.2.4 indicated that the
multiple-document-handlingJob Template attribute MUST be supported with at least one value if the Printer supports multiple documents per job 💖 - Section 4.3.7.2 🔁 bestie, it said the
job-restartablejob state reason SHOULD be supported if the Restart-Job operation is supported. - Section 4.3.8 💅
job-state-reasonsglowed up from RECOMMENDED to REQUIRED, no cap. - Section 4.3.8 ✨ this one is giving clarity. They copied the conformance rules into the
job-state-reasonsdefinition so you can tell from reading it alone which values MUST or SHOULD be supported. Thenone,unsupported-compression, andunsupported-document-formatvalues MUST be supported.job-hold-until-specifiedSHOULD be specified if thejob-hold-untilJob Template is supported. The following values SHOULD be supported:job-canceled-by-user,aborted-by-system, andjob-completed-successfully. Thejob-canceled-by-operatorSHOULD be supported if the implementation permits canceling by other than the job owner. Thejob-canceled-at-deviceSHOULD be supported if the device supports canceling jobs at the console. Thejob-completed-with-warningsSHOULD be supported, if the implementation detects warnings. Thejob-completed-with-errorsSHOULD be supported if the implementation detects errors. Thejob-restartableSHOULD be supported if the Restart-Job operation is supported. - Section 4.3.10 📝 a Printer was allowed to localize the
job-detailed-status-messageJob Description attribute, but the spec flagged that localization might obscure the technical meaning of those messages. 🙈 - Section 4.3.14 ⏰ the
time-at-creation,time-at-processing, andtime-at-completedEvent Time Job Description attributes went from OPTIONAL to REQUIRED. - Section 4.3.14.4 ⏱️ added the REQUIRED
job-printer-up-time (integer(1:MAX))Job Description attribute as an alias forprinter-up-time, so clients need fewer operations to get job times. 🧚 - Section 4.4.2 🔐 added the REQUIRED
uri-authentication-supported (1setOf type2 keyword)Printer Description attribute to describe the Client Authentication used by each Printer URI. - Section 4.4.12 🚦 the
printer-state-reasonsPrinter Description attribute went from OPTIONAL to REQUIRED. - Section 4.4.12 ⏸️ the
pausedvalue ofprinter-state-reasonsbecame MUST if the Pause-Printer operation is supported. - Section 4.4.14 🧩 added the REQUIRED
ipp-versions-supported (1setOf keyword)Printer Description attribute, since IPP/1.1 Printers do not have to support version '1.0' conformance requirements. Section 4.4.16 🎯 added themultiple-document-jobs-supported (boolean)Printer Description attribute so a client can tell whether a Printer that supports Create-Job/Send-Document handles multiple document jobs or not. This attribute is REQUIRED if the Create-Job operation is supported. - Section 4.4.24 📊 the
queued-job-countPrinter Description attribute went from RECOMMENDED to REQUIRED. - Section 4.4.32 🗜️ the
compression-supported (1setOf type3 keyword)Printer Description attribute went from OPTIONAL to REQUIRED. - Section 5.1 🛡️ the client security requirements went from RECOMMENDED non-standards track SSL3 to MUST support Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A client SHOULD support Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910].
- Section 5.2.7 🔒 the IPP object security requirements went from OPTIONAL non-standards track SSL3 to SHOULD contain support for Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the Printer so that all, some, or none of the users are authenticated. An IPP Printer implementation SHOULD contain support for Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the degree of support for Operation Privacy and Server Authentication. Security MUST NOT be compromised when the client supplies a lower version-number in a request. 🚨
- Section 14 (Appendix C) 🔤 fixed a typo, changing the keyword
iso-10-whitetoiso-a10-white.
See also the "IPP/1.1 Encoding and Transport" [RFC2910] document for differences between IPP/1.0 [RFC2565] and IPP/1.1 [RFC2910].
18. Full Copyright Statement 📜
Okay, the legal bit, bestie. Read it anyway, it's short and very important 💜
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it 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 and this paragraph 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 Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🙏
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶
📦 where this page comes from
- ietf: rfc2911 2000-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms