RFC 2566
Internet Printing Protocol/1.0: Model and Semantics
RFC 2566: Internet Printing Protocol/1.0: Model and Semantics ✨
Okay bestie, let's get into it 🎀 This is RFC 2566, called Internet Printing Protocol/1.0: Model and Semantics. It's an Experimental doc (category: Experimental), dated April 1999. The authors are R. deBry from Utah Valley State College, T. Hastings and R. Herriot from Xerox Corporation, S. Isaacson from Novell, Inc., and P. Powell from Astart Technologies 💜 It doesn't list anything it obsoletes or updates, so it's standing on its own 🦋
Status of this Memo 🌸
Real talk, this memo defines an Experimental Protocol for the Internet community 🧪 It is NOT an Internet standard of any kind, so don't treat it like one. They're asking for discussion and suggestions for improvement, and distribution of the memo is unlimited 💅
Copyright Notice 📜
Copyright (C) The Internet Society (1999). All Rights Reserved.
IESG Note 🚨
Heads up, this one's a big deal! The IESG says this doc defines an Experimental protocol for the Internet community. They expect a revised version to be published as a Proposed Standard protocol, and when that happens, it's expected to change from what's in this memo. The standards-track version is expected to add strong authentication and privacy features, plus an "ipp:" URL type that supports those security measures. Other changes are also possible.
Implementors are warned that future versions may not interoperate with the version of IPP defined here. And if they do interoperate, some protocol features might not be available 🙈
The IESG is totally encouraging experimentation with this protocol, especially together with Transport Layer Security (TLS) [RFC 2246]. The goal is to figure out how TLS can work as a security layer for IPP 🔐✨
Abstract 🎀
Okay so this doc is one of a whole set of documents that together describe every aspect of a new Internet Printing Protocol (IPP) 🖨️ IPP is an application level protocol for distributed printing using Internet tools and technologies, and it's giving "print from anywhere" energy 🌍
This document describes a simplified model made of abstract objects, their attributes, and their operations. The best part is that the model doesn't care about encoding or transport 💖 The model has two main pieces: a Printer and a Job object. A Job can optionally support multiple documents 📄
IPP 1.0 semantics let end-users and operators query printer capabilities, submit print jobs, check the status of print jobs and printers, and cancel print jobs. Main character energy 👑 This document also covers security, internationalization, and directory issues 🌈
The full set of IPP documents includes:
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.0: Model and Semantics (this document)Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
Here's the breakdown of each one, iykyk 🧚
- The "Design Goals for an Internet Printing Protocol" doc takes a broad look at distributed printing and lists real-life scenarios that help clarify which features a printing protocol for the Internet needs 🧠 It covers requirements for three types of users: end users, operators, and administrators. It calls out a subset of the end user requirements that IPP/1.0 satisfies. Operator and administrator requirements are out of scope for version 1.0 🙈
- The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" doc describes IPP from a high-level view 🦋 It defines a roadmap for the documents in the IPP suite and gives background and rationale for the IETF working group's major decisions.
- The "Internet Printing Protocol/1.0: Encoding and Transport" doc is the formal mapping of the abstract operations and attributes from the model document onto HTTP/1.1 🎀 It also defines the encoding rules for the new Internet media type called "application/ipp" 💅
- The "Internet Printing Protocol/1.0: Implementer's Guide" doc gives insight and advice to implementers of IPP clients and IPP objects ✨ It helps them understand IPP/1.0 and some of the things that can help with designing their client and/or IPP object implementations. For example, it gives a typical order for processing requests, including error checking. It also explains the motivation behind some of the specification 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 🧚
okay so this is literally the map of the whole spec, bestie 🗺️✨ every section number is a little promise to the reader, so I'm keeping them all exactly as they are 🫶
1. Introduction 8
1.1 Simplified Printing Model 9
2. IPP Objects 11
2.1 Printer Object 12
2.2 Job Object 14
2.3 Object Relationships 14
2.4 Object Identity 15
3. IPP Operations 18
3.1 Common Semantics 19
3.1.1 Required Parameters 19
3.1.2 Operation IDs and Request IDs 20
3.1.3 Attributes 20
3.1.4 Character Set and Natural Language Operation Attributes 22
3.1.4.1 Request Operation Attributes 22
3.1.4.2 Response Operation Attributes 26
3.1.5 Operation Targets 28
3.1.6 Operation Status Codes and Messages 29
3.1.7 Versions 30
3.1.8 Job Creation Operations 32
3.2 Printer Operations 34
3.2.1 Print-Job Operation 34
3.2.1.1 Print-Job Request 34
3.2.1.2 Print-Job Response 38
3.2.2 Print-URI Operation 41
3.2.3 Validate-Job Operation 42
3.2.4 Create-Job Operation 42
3.2.5 Get-Printer-Attributes Operation 43
3.2.5.1 Get-Printer-Attributes Request 44
3.2.5.2 Get-Printer-Attributes Response 46
3.2.6 Get-Jobs Operation 47
3.2.6.1 Get-Jobs Request 47
3.2.6.2 Get-Jobs Response 49
3.3 Job Operations 50
3.3.1 Send-Document Operation 50
3.3.1.1 Send-Document Request 51
3.3.1.2 Send-Document Response 53
3.3.2 Send-URI Operation 54
3.3.3 Cancel-Job Operation 54
3.3.3.1 Cancel-Job Request 54
3.3.3.2 Cancel-Job Response 55
3.3.4 Get-Job-Attributes Operation 56
3.3.4.1 Get-Job-Attributes Request 57
3.3.4.2 Get-Job-Attributes Response 57
4. Object Attributes 58
4.1 Attribute Syntaxes 59
4.1.1 'text' 60
4.1.1.1 'textWithoutLanguage' 61
4.1.1.2 'textWithLanguage' 61
4.1.2 'name' 62
4.1.2.1 'nameWithoutLanguage' 62
4.1.2.2 'nameWithLanguage' 63
4.1.2.3 Matching 'name' attribute values 63
4.1.3 'keyword' 64
4.1.4 'enum' 65
4.1.5 'uri' 65
4.1.6 'uriScheme' 65
4.1.7 'charset' 66
4.1.8 'naturalLanguage' 67
4.1.9 'mimeMediaType' 67
4.1.10 'octetString' 69
4.1.11 'boolean' 69
4.1.12 'integer' 69
4.1.13 'rangeOfInteger' 69
4.1.14 'dateTime' 69
4.1.15 'resolution' 69
4.1.16 '1setOf X' 70
4.2 Job Template Attributes 70
4.2.1 job-priority (integer(1:100)) 74
4.2.2 job-hold-until (type3 keyword | name (MAX)) 75
4.2.3 job-sheets (type3 keyword | name(MAX)) 75
4.2.4 multiple-document-handling (type2 keyword) 76
4.2.5 copies (integer(1:MAX)) 77
4.2.6 finishings (1setOf type2 enum) 78
4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 79
4.2.8 sides (type2 keyword) 80
4.2.9 number-up (integer(1:MAX)) 80
4.2.10 orientation-requested (type2 enum) 81
4.2.11 media (type3 keyword | name(MAX)) 82
4.2.12 printer-resolution (resolution) 83
4.2.13 print-quality (type2 enum) 83
4.3 Job Description Attributes 84
4.3.1 job-uri (uri) 85
4.3.2 job-id (integer(1:MAX)) 85
4.3.3 job-printer-uri (uri) 86
4.3.4 job-more-info (uri) 86
4.3.5 job-name (name(MAX)) 86
4.3.6 job-originating-user-name (name(MAX)) 86
4.3.7 job-state (type1 enum) 87
4.3.8 job-state-reasons (1setOf type2 keyword) 90
4.3.9 job-state-message (text(MAX)) 92
4.3.10 number-of-documents (integer(0:MAX)) 93
4.3.11 output-device-assigned (name(127)) 93
4.3.12 time-at-creation (integer(0:MAX)) 93
4.3.13 time-at-processing (integer(0:MAX)) 93
4.3.14 time-at-completed (integer(0:MAX)) 94
4.3.15 number-of-intervening-jobs (integer(0:MAX)) 94
4.3.16 job-message-from-operator (text(127)) 94
4.3.17 job-k-octets (integer(0:MAX)) 94
4.3.18 job-impressions (integer(0:MAX)) 95
4.3.19 job-media-sheets (integer(0:MAX)) 95
4.3.20 job-k-octets-processed (integer(0:MAX)) 96
4.3.21 job-impressions-completed (integer(0:MAX)) 96
4.3.22 job-media-sheets-completed (integer(0:MAX)) 96
4.3.23 attributes-charset (charset) 97
4.3.24 attributes-natural-language (naturalLanguage) 97
4.4 Printer Description Attributes 97
4.4.1 printer-uri-supported (1setOf uri) 99
4.4.2 uri-security-supported (1setOf type2 keyword) 100
4.4.3 printer-name (name(127)) 101
4.4.4 printer-location (text(127)) 101
4.4.5 printer-info (text(127)) 101
4.4.6 printer-more-info (uri) 101
4.4.7 printer-driver-installer (uri) 102
4.4.8 printer-make-and-model (text(127)) 102
4.4.9 printer-more-info-manufacturer (uri) 102
4.4.10 printer-state (type1 enum) 102
4.4.11 printer-state-reasons (1setOf type2 keyword) 103
4.4.12 printer-state-message (text(MAX)) 106
4.4.13 operations-supported (1setOf type2 enum) 106
4.4.14 charset-configured (charset) 107
4.4.15 charset-supported (1setOf charset) 107
4.4.16 natural-language-configured (naturalLanguage) 107
4.4.17 generated-natural-language-supported(1setOf naturalLanguage108
4.4.18 document-format-default (mimeMediaType) 108
4.4.19 document-format-supported (1setOf mimeMediaType) 108
4.4.20 printer-is-accepting-jobs (boolean) 109
4.4.21 queued-job-count (integer(0:MAX)) 109
4.4.22 printer-message-from-operator (text(127)) 109
4.4.23 color-supported (boolean) 109
4.4.24 reference-uri-schemes-supported (1setOf uriScheme) 109
4.4.25 pdl-override-supported (type2 keyword) 110
4.4.26 printer-up-time (integer(1:MAX)) 110
4.4.27 printer-current-time (dateTime) 111
4.4.28 multiple-operation-time-out (integer(1:MAX)) 111
4.4.29 compression-supported (1setOf type3 keyword) 111
4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) 112
4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) 112
4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) 112
5. Conformance 112
5.1 Client Conformance Requirements 112
5.2 IPP Object Conformance Requirements 113
5.2.1 Objects 113
5.2.2 Operations 113
5.2.3 IPP Object Attributes 114
5.2.4 Extensions 114
5.2.5 Attribute Syntaxes 115
5.3 Charset and Natural Language Requirements 115
5.4 Security Conformance Requirements 115
6. IANA Considerations (registered and private extensions) 116
6.1 Typed 'keyword' and 'enum' Extensions 116
6.2 Attribute Extensibility 119
6.3 Attribute Syntax Extensibility 119
6.4 Operation Extensibility 120
6.5 Attribute Groups 120
6.6 Status Code Extensibility 120
6.7 Registration of MIME types/sub-types for document-formats 121
6.8 Registration of charsets for use in 'charset' attribute values121
7. Internationalization Considerations 121
8. Security Considerations 125
8.1 Security Scenarios 126
8.1.1 Client and Server in the Same Security Domain 126
8.1.2 Client and Server in Different Security Domains 126
8.1.3 Print by Reference 127
8.2 URIs for SSL3 and non-SSL3 Access 127 8.3 The "requesting-user-name" (name(MAX)) Operation Attribute 127
8.4 Restricted Queries 129
8.5 Queries on jobs submitted using non-IPP protocols 129
8.6 IPP Security Application Profile for SSL3 130
9. References 131
10. Authors' Addresses 134
11. Formats for IPP Registration Proposals 136
11.1 Type2 keyword attribute values registration 136
11.2 Type3 keyword attribute values registration 137
11.3 Type2 enum attribute values registration 137
11.4 Type3 enum attribute values registration 137
11.5 Attribute registration 138
11.6 Attribute Syntax registration 138
11.7 Operation registration 139
11.8 Attribute Group registration 139
11.9 Status code registration 139
12.APPENDIX A: Terminology 141
12.1 Conformance Terminology 141
12.1.1 NEED NOT 141
12.2 Model Terminology 141
12.2.1 Keyword 141
12.2.2 Attributes 141
12.2.2.1 Attribute Name 141
12.2.2.2 Attribute Group Name 142
12.2.2.3 Attribute Value 142
12.2.2.4 Attribute Syntax 142
12.2.3 Supports 142
12.2.4 print-stream page 144
12.2.5 impression 144
13.APPENDIX B: Status Codes and Suggested Status Code Messages 145
13.1 Status Codes 146
13.1.1 Informational 146
13.1.2 Successful Status Codes 146
13.1.2.1 successful-ok (0x0000) 146
13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) 146
13.1.2.3 successful-ok-conflicting-attributes (0x0002) 147
13.1.3 Redirection Status Codes 147
13.1.4 Client Error Status Codes 147
13.1.4.1 client-error-bad-request (0x0400) 147
13.1.4.2 client-error-forbidden (0x0401) 147
13.1.4.3 client-error-not-authenticated (0x0402) 148
13.1.4.4 client-error-not-authorized (0x0403) 148
13.1.4.5 client-error-not-possible (0x0404) 148
13.1.4.6 client-error-timeout (0x0405) 148
13.1.4.7 client-error-not-found (0x0406) 149
13.1.4.8 client-error-gone (0x0407) 149
13.1.4.9 client-error-request-entity-too-large (0x0408) 149
13.1.4.10client-error-request-value-too-long (0x0409) 150
13.1.4.11client-error-document-format-not-supported (0x040A) 150
13.1.4.12client-error-attributes-or-values-not-supported (0x040B) 150
13.1.4.13client-error-uri-scheme-not-supported (0x040C) 151
13.1.4.14client-error-charset-not-supported (0x040D) 151
13.1.4.15client-error-conflicting-attributes (0x040E) 151
13.1.5 Server Error Status Codes 151
13.1.5.1 server-error-internal-error (0x0500) 151
13.1.5.2 server-error-operation-not-supported (0x0501) 152
13.1.5.3 server-error-service-unavailable (0x0502) 152
13.1.5.4 server-error-version-not-supported (0x0503) 152
13.1.5.5 server-error-device-error (0x0504) 152
13.1.5.6 server-error-temporary-error (0x0505) 153
13.1.5.7 server-error-not-accepting-jobs (0x0506) 153
13.1.5.8 server-error-busy (0x0507) 153
13.1.5.9 server-error-job-canceled (0x0508) 153
13.2 Status Codes for IPP Operations 153
14.APPENDIX C: "media" keyword values 155
15.APPENDIX D: Processing IPP Attributes 160
15.1 Fidelity 160
15.2 Page Description Language (PDL) Override 161
15.3 Using Job Template Attributes During Document Processing. 163
16.APPENDIX E: Generic Directory Schema 166
17.APPENDIX F: Change History for the Model and Semantics document 168
18.FULL COPYRIGHT STATEMENT 1731. Introduction ✨
okay so the Internet Printing Protocol (IPP) is an application level protocol that lets you do distributed printing using the Internet tools and technologies you already know 🖨️💖 IPP version 1.0 (IPP/1.0) is laser-focused on end user functionality, and this document is just one piece of a whole suite that fully defines IPP. the full set of IPP documents is:
- 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.0: Model and Semantics (this document)
- Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
- Internet Printing Protocol/1.0: 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, it's the main character reading order 🎀✨
here's how this document is laid out, bestie:
- the rest of Section 1 is an intro 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.0. IPP operations are synchronous, so every operation has both a request and a response 💅
- Section 4 defines the attributes (and their syntaxes) that get 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 Internationalization and Security considerations, plus References, Author contact info, 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 like "attributes", "keywords", and "support". These terms have special meaning, and they're defined in the model terminology section 12.2. Capitalized terms, like MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning for conformance. They're 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 a client can find the Printer not just by name, but by filtered searches too 👑
- Section 17 is an appendix with a Change History summarizing the clarifications and changes that might affect an implementation since the June 30, 1998 draft 🍓
1.1. Simplified Printing Model 🖨️✨
okay so bestie, the whole goal here is making a printing protocol that actually works on the Internet 💅. IPP uses a simplified printing model that hides the messy stuff behind real-world printing. The Internet is a distributed place where requesters of print services (clients, apps, printer drivers, and so on) team up with print service providers 🌸. This document gives IPP one simple, abstract model, even though the setup underneath might be a complicated "n-tier" client/server system 🧚.
The big trick is that IPP only shows you the key objects and interfaces you need for printing. Anything beyond the scope of the first version (IPP/1.0) is not in this model 🙈. IPP/1.0 borrows a lot 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.0 only focuses on end user functionality 💜.
IPP/1.0 wraps up the important parts of distributed printing into two object types:
- Printer (Section 2.1)
- Job (Section 2.2)
Each object type comes with its own set of operations (see section 3) and attributes (see section 4) 🦋.
Now, real systems have extra pieces underneath the simplified IPP/1.0 model that aren't spelled out in it 🌈. The figure below shows where IPP/1.0 fits among those other components.
+--------------+
| 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)|
+-----------------+An IPP Printer object packs in the stuff a physical output device normally does, plus the spooling, scheduling, and multi-device management that you'd usually find on a print server 🖨️💖. Printer objects can optionally be listed as entries in a directory, where end users hunt for them using filtered, context-based searching (see section 16) 🔍. The directory only holds relatively static info about the Printer, like name, context, and capabilities, so people can match what they need ✨. The more dynamic stuff, like state, loaded and ready media, number of jobs, errors, and warnings, lives right on the Printer object itself, not on the directory entry that just points to it 🙌.
IPP clients implement the 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 protocol part of a Printer object. Everything else in the Printer object handles (or gateways into) the actual print service semantics 🧁. Printer objects can be embedded right inside an output device, or they can run on a networked host that talks to an output device 🌟.
Here's the flow: when a job goes to a Printer object and the Printer validates the attributes in the request, the Printer creates a brand-new Job object 🎉. The end user then talks to that Job object to check its status and watch its progress. If they change their mind, they can cancel the job with the Job object's Cancel-Job operation 🙅♀️. The notification service is out of scope for IPP/1.0, but with one, end users could register for and get Printer-specific and Job-specific events 🔔. Without it, end users can check on Printer objects and follow Job progress by polling with the Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes operations 🔁.
2. IPP Objects 🎀
The IPP/1.0 model brings in two object types: Printer and Job 💜. Each type models the important bits of a real-world thing, like an actual printer or an actual print job 🖨️. Every object type is defined as a set of attributes that instances of that type might support. For each individual object, the attributes and values it actually supports describe one specific implementation 🌸. Those attributes and values cover its state, capabilities, features it can actually do, job processing functions, and default behaviors and characteristics 🧚. So the Printer object type is a menu of attributes that any Printer object could support, and the Job object type is the same kind of menu for Job objects 💅.
Every attribute in the set that defines an object type gets one of these labels:
- "REQUIRED": each object MUST support the attribute.
- "OPTIONAL": each object MAY support the attribute.
Attribute values don't get labels like that 🙈. Still, if an implementation supports an attribute, it MUST support at least one of that attribute's possible values ✨.
2.1. Printer Object 🖨️💖
The Printer object is the main character of the IPP/1.0 model 👑. It implements the server side of the IPP/1.0 protocol. Through the protocol, end users can query a Printer object's attributes and submit print jobs to it 💅. Behind a Printer, the real implementation pieces can look really different and be set up in lots of ways. The model keeps those configuration details hidden from the end user, though 🦋. Section 3 goes through each Printer operation in detail 📖.
A Printer's capabilities and state are described by its attributes, and those split into two groups:
- "job-template" attributes: These attributes describe supported job processing capabilities and defaults for the Printer object. (See section 4.2)
- "printer-description" attributes: These attributes describe the Printer object's identification, state, location, references to other sources of information about the Printer object, etc. (see section 4.4)
A Printer object is an abstraction of a generic document output device and print service provider, so it can stand in for any real or virtual device that acts like a Printer, like a fax device, an imager, or even a CD writer 🌈.
Here are some configurations that can support a Printer object:
1) An output device with no spooling capabilities
2) An output device with a built-in spooler
3) 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 IPPThe figures below show how Printer objects can be built on top of different distributed printing setups 🧁. The embedded figure covers configurations 1 and 2. The hosted and fan-out figures cover configurations 3a and 3b 💜.
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 IPP
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 ✨
okay so a Job object is how we model a print job 🖨️💖 A Job object contains documents. The info needed to create one gets sent 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 it, the Printer object makes the new Job object. Section 3 goes through each Job operation in detail, so go peek there 🧚
The characteristics and state of a Job object are described by its attributes, and job attributes come in two groups 💅
"job-template"attributes: these can be supplied by the client or end user, and they include job processing instructions that are 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 others. (See section 4.3)
Here's the big rule 👑 An implementation MUST support at least one document per Job object. It MAY support multiple documents per Job object too, so that's extra credit 🌈 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.0, a document is not modeled as an IPP object, therefore it has no object identifier or associated attributes 🙈 All job processing instructions are modeled as Job object attributes instead. These attributes 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 maintained persistently, right alongside the persistent storage of the object attributes. Iconic behaviour, honestly 🫶
A Printer object can represent either 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 this case, a second Job object would be created, which would be almost identical to the first Job object. It would have new (different) Job object identifiers (see section 2.4). Twins, but make it a new identity 💜
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. However, there can 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 object(s)) may contain the same reference. 💅🌸
2.4 Object Identity 🆔✨
Okay bestie, so every Printer and Job object gets a Uniform Resource Identifier (URI) [RFC2396] 🦋 so it can be referenced persistently and unambiguously. No mix-ups, no cap. The URI idea is giving main character energy, but the notion of URI isn't fully stable yet (it's defined more completely and deployed more widely over time), so the URIs used for IPP objects are expected to actually be URLs [RFC2396]. Every URL is a specialized form of a URI, so even though this doc says URI everywhere, that also covers URL. 💅
An administrator configures Printer objects to either support or not support authentication and/or message privacy using SSL3 [SSL] (the mechanism for security configuration is outside the scope of IPP/1.0) 🔐. In some situations, both authenticated and unauthenticated connections can be set up over a single communication channel that has some sort of negotiation mechanism. In other situations, there are multiple communication channels, one for each type of security configuration. Section 8 provides a full description of all security considerations and configurations, so go check it out, it's serious stuff 😭.
If a Printer object supports more than one communication channel, some or all of those channels might support and/or require different security mechanisms. In that case, an administrator could expose the simultaneous support for these multiple channels as multiple URIs for a single Printer object, where each URI represents one of the channels to the Printer object 🌈. To make this flexible, the IPP Printer object type defines a multi-valued identification attribute called the "printer-uri-supported" attribute. It MUST contain at least one URI. It MAY contain more than one URI. So every Printer object has at least one URI that identifies at least one communication channel to it, but it can have more, with each one pointing at a different channel 🧚. The "printer-uri-supported" attribute has a companion attribute, the "uri-security-supported" attribute, which has the same cardinality as "printer-uri-supported". Its whole job is to indicate the security mechanisms (if any) used for each URI listed in "printer-uri-supported" 🎀. These two attributes are fully described in sections 4.4.1 and 4.4.2.
When a job is submitted to the Printer object via a create request, the client supplies only a single Printer object URI. That client-supplied Printer object URI MUST be one of the values in the "printer-uri-supported" Printer attribute. No freelancing allowed 🙅♀️.
Note: IPP/1.0 doesn't specify how the client obtains the client-supplied URI, but it is RECOMMENDED that a Printer object be registered as an entry in a directory service. That way, end-users and programs can search the directory for Printers 🔍. Section 16 defines a generic schema for Printer object entries in the directory service and describes how the entry acts as a bridge to the actual IPP Printer object. The directory entry representing the IPP Printer object includes the possibly many URIs for that Printer object as values in one of its attributes 🍓.
When a client submits a create request to the Printer object, the Printer object validates the request and creates a new Job object 💖. The Printer object assigns the new Job object a URI, which gets stored in the "job-uri" Job attribute. Clients then use this URI as the target for all subsequent Job operations. The Printer object generates a Job URI based on its configured security policy and the URI the client used in the create request 🫶.
Here's an example. Say a Printer object supports both a channel secured with SSL3 (HTTP over SSL3 with an "https" schemed URI) and another open channel that isn't secured with SSL3 (using a plain "http" schemed 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. Matching energy, always 👑.
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. If a client only has access to a Job object's "job-uri" identifier, it can query the "job-printer-uri" attribute to figure out which Printer object created the Job object 🕵️♀️. If the Printer object supports more than one URI, it picks the one URI the client supplied when creating the job to build and populate the Job's "job-printer-uri" value 🦋.
Giving Job objects URIs allows for flexibility and scalability 🌸. For example, in some implementations the Printer object might create Jobs that get processed in the same local environment as the Printer object itself. There, the Job URI might just be a composition of the Printer's URI and some unique component for the Job object, like the unique 32-bit positive integer mentioned later in this paragraph. In other implementations, the Printer object might be a central clearing-house for validating all Job creation requests, while the Job object itself gets created in an environment that's remote from the Printer object. In that case, the Job object's URI may have no physical-location relationship at all to the Printer object's URI 🌍. Again, the fact that Job objects have URIs gives us flexibility and scalability. However, lots of existing printing systems have local models or interface constraints that force print jobs to be identified using only a 32-bit positive integer, not an independent URI 🙈. This numeric Job ID is only unique within the context of the Printer object to which the create request was originally submitted. So, to allow both types of client access to IPP Job objects (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 to which the create request was originally submitted. This requirement to support both Job URIs and Job IDs means all types of clients can access Printer objects and Job objects, no matter what local constraints the client implementation has 🥹.
Beyond identifiers, Printer objects and Job objects also have names ("printer-name" and "job-name") 🏷️. An object name NEED NOT be unique across all instances of all objects. A Printer object's name is chosen and set by an administrator through some mechanism outside the scope of IPP/1.0. 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 object name, the Printer object generates one for the new Job object. In all cases, the name only has local meaning 🌈.
To summarize:
- 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.,'ssl3'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 IPP/1.0 itself. 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 consists of a request and a response 💌. When a client communicates with an IPP object, the client issues an operation request to the URI for that object. Operation requests and responses have parameters that identify the operation. Operations also have attributes that affect the run-time characteristics of the operation (the intended target, localization information, etc.). These operation-specific attributes are called operation attributes, as opposed to object attributes such as Printer object attributes or Job object attributes 🧠. Each request carries along any operation attributes, object attributes, and/or document data required to perform the operation. Each request requires a response from the object. Each response indicates success or failure of the operation with a status code as a response parameter. The response contains any operation attributes, object attributes, and/or status messages generated during execution of the operation request 🫶.
This section describes the semantics of the IPP operations, both requests and responses, in terms of the parameters, attributes, and other data associated with each operation 📝.
The IPP/1.0 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)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)The Send-Document and Send-URI Job operations are used to add a new document to an existing multi-document Job object created using the Create-Job operation 📄.
3.1 Common Semantics 🌷
All IPP operations require some common parameters and operation attributes. These common elements and their semantic characteristics are defined and described in more detail in the following sections 💅.
3.1.1 Required Parameters 💖
okay so every operation request comes with these REQUIRED parameters 💅:
version-number,operation-id,request-id, and- the attributes that are REQUIRED for that type of request.
every operation response has its own set of REQUIRED parameters 🎀:
version-number,status-code,- the
request-idthat was supplied in the corresponding request, and - the attributes that are REQUIRED for that type of response.
the encoding and transport doc [RFC2565] has special rules just for encoding these parameters 🧚. everything else in an operation gets handled by the more generic encoding 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 defined in the operations-supported Printer attribute section (see section 4.4.13). the client tells the printer which operation it wants by sending the correct operation-id value, simple as that 💜.
every single invocation of an operation also gets its own request-id value. for each request, the client picks a request-id that MUST be an integer (possibly unique, depending on what the client needs) in the range from 1 to 2**31 - 1 (inclusive) 🌈. this is what lets clients juggle multiple outstanding requests at once, which is so important 🙌. the receiving IPP object copies all 32 bits of the client-supplied request-id attribute 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 complete request-id arrives, the IPP object rejects the request and returns a response with a request-id of 0 💀.
Note: ngl this one is a bit of a plot twist 🙈. sometimes the transport underneath IPP is connection oriented, which means the client can only get responses back in the same order it sent the requests. in that situation therequest-idisn't essential for the protocol to work. but in other mappings the responses can come back in any order, and then therequest-idis 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. they can also affect other attributes or groups of attributes 💖. some of them describe the document data for a print job and get attached to new Job objects, but most operation attributes don't stick around past the life of the operation 🫶. each operation attribute's description includes conformance statements that say which ones are REQUIRED and which are OPTIONAL for an IPP object to support, plus which ones a client MUST supply in a request and which ones an IPP object MUST supply in a response 🎀.
- Job Template Attributes: these affect how a job gets processed 🧚. a client OPTIONALLY supplies 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 find out 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 be queried about its Job Template attributes too, to see what job processing capabilities it supports and/or what the default behaviors are. those come back in the response as Printer Object Attributes 🦋. the
ipp-attribute-fidelityoperation attribute affects how all client-supplied Job Template attributes get processed (see section 15 for a full description ofipp-attribute-fidelityand 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 are unsupported by the Printer object, the Printer object sends back the set of unsupported attributes in the response 😭. section 15 explains in full how the Printer object processes the Job Template attributes from a create request 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 🫶.
later in this section, each operation gets formally defined by listing 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 it says otherwise 🌸.
each attribute spec includes the attribute's name, followed by the name of its attribute syntax(es) in parentheses. on top of that, each integer attribute is 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 out the attribute syntax descriptions in section 4.1 💅.
Note: document data sent with an operation isn't strictly an attribute, but it gets treated as a special attribute group for ordering purposes 🧚. the only operations that let you supply document data inside an operation request are Print-Job and Send-Document. no operation responses include document data 🙈.
Note: some operations are REQUIRED for IPP objects to support, and the rest 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. that tells it 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 doesn't 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 that are 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 🎀.
most attribute groups don't care what order their attributes are in 🌸. but for these two inside 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 the specified order 👑. for job creation operations, the IPP Printer implementation saves these two attributes with the new Job object as Job Description attributes ✨. for the sake of brevity, these operation attribute descriptions aren't repeated with every operation request and response. instead, they point back to this section 🧚.
3.1.4.1 Request Operation Attributes 🎀
Okay bestie, the client MUST supply, and the Printer object MUST support, these REQUIRED operation attributes in every IPP/1.0 operation request 💅:
"attributes-charset" (charset): This operation attribute tells everyone which charset (the coded character set plus its encoding method) is used by any text and name attributes the client is sending in this request 📝. It also says which charset the Printer object MUST use (if supported) for all text and name attributes and status messages it sends back in the response to this request. Peek at Sections 4.1.1 and 4.1.2 for the specs on 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 does not support the client-supplied charset value, 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, with any text or name attributes using the utf-8 charset 💀. The Printer object MUST indicate the charset(s) it supports as the values of the "charset-supported" Printer attribute (see Section 4.4.15), so the client can query and figure out what's supported 🔍.
Note to client implementers: Since IPP objects are only required to support the utf-8 charset, in order to maximize interoperability with multiple IPP object implementations, a client may want to supply utf-8 in the "attributes-charset" operation attribute, even though the client is only passing and able to present a simpler charset, such as US-ASCII or ISO-8859-1. Then the client will have to filter out (or charset convert) those characters that are returned in the response that it cannot present to its user. On the other hand, if both the client and the IPP objects also support a charset in common besides utf-8, the client may want to use that charset in order to avoid charset conversion or data loss 🫶.
See the charset attribute syntax description in Section 4.1.7 for the syntax and semantic interpretation of the values of this attribute and for 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 the Printer object SHOULD use for all text and name attributes and status messages it returns in the response to this request.
There are no REQUIRED natural languages required for the Printer object to support. 🙌 However, the Printer object's generated-natural-language-supported attribute identifies the natural languages supported by the Printer object and any contained Job objects for all text strings generated by the IPP object. A client MAY query this attribute to determine which natural language(s) are supported for generated messages.
For any of the attributes for which the Printer object generates text, i.e., for the "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 is not 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.16) 🍓.
For other text and name attributes supplied by the client, authentication system, operator, system administrator, or manufacturer (i.e., for "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 the Printer object's "natural-language-configured" attribute, though support of additional natural languages for these attributes is permitted 🌈.
For any text or name attribute in the request that is in a different natural language than the value supplied in the "attributes-natural-language" operation attribute, 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, i.e., use it even when the value is in the same natural language as the value supplied in the "attributes-natural-language" operation attribute of the request 🦋.
The IPP object MUST accept any natural language and any Natural Language Override, whether the IPP object supports that natural language or not (and independent of the value of the "ipp-attribute-fidelity" Operation attribute). That is, the IPP object accepts all client-supplied values no matter what the values are in the Printer object's "generated-natural-language-supported" attribute. That attribute, "generated-natural-language-supported", only applies to generated messages, not client-supplied messages. 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 does not specify how this 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.1textWithoutLanguageand 4.1.2.1nameWithoutLanguage). - 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
textWithLanguageand 4.1.2.2nameWithLanguage).
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, as identified by the Natural Language Override mechanism. If supplied, the IPP object will use the value of the "job-name" attribute to populate the Job object's "job-name" attribute. Whenever any client queries the Job object's "job-name" attribute, the IPP object returns the attribute as stored and uses the Natural Language Override mechanism to specify the natural language, if it is different from that reported in the "attributes-natural-language" operation attribute of the response. The IPP object MAY use the Natural Language Override mechanism redundantly, i.e., use it even when the value is in the same natural language as the value supplied in the "attributes-natural-language" operation attribute 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. 🙅♀️
See the naturalLanguage attribute syntax description in Section 4.1.8 for the syntax and semantic interpretation of the values of this attribute and for example values 🌸.
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 does not 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 which it occurs:
- In a create request: If the client supplies a
textornameattribute (for example, the"job-name"operation attribute) that uses an apparently incompatible combination, it is a client choice that does not 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. In addition, 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 💖.
3.1.4.2. Response Operation Attributes ✨
okay bestie, the Printer object MUST supply and the client MUST support these REQUIRED operation attributes in every IPP/1.0 operation response 💖 no exceptions, periodt 💅
"attributes-charset" (charset): this one tells you which charset the 'text' and 'name' attributes in the response are using 🎀 The value MUST be the same one the client sent in its request's "attributes-charset" operation attribute. If that's not possible (like, the requested charset isn't supported), the request would have been rejected in the first place, so it never gets this far 🙈 Check out Section 3.1.4.1 above for the full scoop on "attributes-charset".
If the Printer object supports more than just the 'utf-8' charset, it MUST be able to code convert between each supported charset at the highest fidelity possible, so it can return 'text' and 'name' attributes in whatever charset the client asked for 🌸 Some information loss MAY happen during conversion though, depending on which charsets are involved 😭 For example, the Printer object can turn a UTF-8 a into a US-ASCII a with zero loss ✨ It can turn an ISO Latin 1 CAPITAL LETTER A WITH ACUTE ACCENT into US-ASCII A, which means the accent gets lost 💀 Or it can turn a UTF-8 Japanese Kanji character into some ISO Latin 1 error character indication, like ?, a decimal code equivalent, or just no character at all, depending on the implementation 🧚
Note: whether an implementation that supports more than one charset stores data in the charset the client sent, or code converts to one of the other supported charsets, is up to the implementation 🦋 The strategy should try to minimize loss of information during code conversion. Either way, that kind of implementation converts from its internal charset to the requested one on every response 👑
"attributes-natural-language" (naturalLanguage): this operation attribute tells you which natural language the 'text' and 'name' attributes in the response are in 🌈 Unlike "attributes-charset", the IPP object NEED NOT return the same value the client sent, so it's a little more flexible 🫶 The IPP object MAY return the natural language of the Job object, or the Printer's configured natural language from its "natural-language-configured" attribute, instead of whatever the client asked for 💜 Now here's the big rule: if any 'text' or 'name' attribute or status message in the response is in a different natural language than the one returned in "attributes-natural-language", the IPP object MUST use the Natural Language Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on each attribute value it returns 🔥 And the IPP object MAY use the Natural Language Override mechanism redundantly, meaning it can use it even when the value is already in the same natural language as the "attributes-natural-language" operation attribute in the response 🍓
3.1.5. Operation Targets 🎯
okay so 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 (basically 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 of the operation 🎀 The client tells the Printer object which one it means by putting the correct URI in the "printer-uri (uri)" operation attribute ✨
For Job operations, the operation is directed at one of two things 👑
- The Job object itself, using the Job object's URI. In this case, the client identifies the target object 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 is the one that generated the Job ID, it MUST be able to correctly match the client-supplied Job ID to the right Job object 🧚 The client puts the Printer object's URI in the
"printer-uri (uri)"operation attribute, and the Job object's Job ID in the"job-id (integer(1:MAX))"operation attribute 💖
If the operation is aimed at the Job object directly through its URI, the client MUST NOT include the redundant "job-id" operation attribute 🙅♀️ (no duplicate info, bestie, it's giving clean)
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), the operation target attributes are specially ordered operation attributes 🌈 In every case they immediately follow "attributes-charset" and "attributes-natural-language" inside the operation attribute group, but the exact ordering rules are:
- If there's only one operation target attribute (so either only
"printer-uri"or only"job-uri"), that attribute MUST be the third attribute in the operation attributes group 🍓 - If Job operations use two operation target attributes (that's
"printer-uri"and"job-id"), then"printer-uri"MUST be the third attribute and"job-id"MUST be the fourth attribute 🔥
In all cases, the target URIs inside the body of IPP operation requests and responses must be in absolute format rather than relative format 💀 (a relative URL identifies a resource within the scope of the HTTP server, but doesn't include scheme, host, or port, so it's not enough on its own, iykyk 🙈)
The following rules cover 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 within 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 within 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 to be specified within 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 [RFC2565] shows how IPP maps onto HTTP/1.1, and it defines a new default port number for using IPP over HTTP/1.1 🦋
3.1.6. Operation Status Codes and Messages 🌈
every operation response includes a REQUIRED "status-code" parameter and an OPTIONAL "status-message" operation attribute 💖 The "status-code" tells you how the request was processed 🎀 A "status-message" attribute gives a short textual description of the operation's status ✨ The status code is meant for automata (aka machines), and the status message is meant for the human end user 🫶 If a response does include a "status-message" attribute, an IPP client NEED NOT examine or display it, but it SHOULD do so in some implementation-specific way 🍓
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 that values can only range from 0x0000 to 0x7FFF 🧚 Section 13 describes the status codes, assigns their numeric values, and suggests a corresponding status message for each one 👑 The "status-message" attribute's syntax is text(255) 🌸 A client implementation of IPP SHOULD convert status code values into any localized message that has semantic meaning to the end user 💅
If the Printer object supports the "status-message" operation attribute, the Printer object MUST be able to generate that message in any of the natural languages listed in its "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute in section 3.1.4.1) 💜 As section 3.1.4.1 describes 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 its 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.7 Versions 🎀
Okay so every operation request and response carries a version-number parameter 💅 Each value looks like X.Y, where X is the major version number and Y is the minor version number. By putting a version number in the request, the client tells the object which version of IPP it wants to use. If the IPP object doesn't support that version, it responds with the status code server-error-version-not-supported plus the closest version number it does support (see section 13.1.5.4) 🦋
There's no version negotiation per se 🙈 But if a client gets server-error-version-not-supported from an IPP object, nothing stops it from trying again with a different version number ✨ To conform to IPP/1.0, an implementation MUST support at least version 1.0. No skipping that one, bestie 💖
There's only one notion of "version number," and it 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 [RFC2566] or a new version of the Encoding and Transport document [RFC2565]. Iconic teamwork 👑
Changes to the major version number signal structural or syntactic changes that make it impossible for older versions of 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 ipp-attribute-fidelity (if it hadn't already been part of version 1.0) would have required a change to the major version number 🍓 Things that might affect changing the major version number include any changes to the Model and Semantics document [RFC2566] or the Encoding and Transport document [RFC2565] itself, such as:
- reordering of ordered attributes or attribute sets
- changes to the syntax of existing attributes
- changing Operation or Job Template attributes from OPTIONAL to REQUIRED and vice versa
- adding REQUIRED (for an IPP object to support) operation attributes
- adding REQUIRED (for an IPP object to support) operation attribute groups
- adding values to existing operation attributes
- adding REQUIRED operations
Changes to the minor version number are for adding new features, attributes and attribute values that may not be understood by all IPP objects, but that can be ignored if they aren't understood 🦋 Things that might affect changing the minor version number include any changes to the model objects and attributes but not the encoding and transport rules [RFC2565] (except adding attribute syntaxes). Examples of these changes 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
The encoding of the operation-id, the version-number, the status-code, and the request-id MUST NOT change over any version number, major or minor 🔥 This rule is what guarantees that all future versions stay backwards compatible with all previous versions (at least when it comes to checking the operation-id, the version-number, and the request-id) 💜 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. Never again, periodt 💅
Implementations that support a certain major version NEED NOT support all previous versions ✨ As each new major version is defined (through the release of a new specification), that major version will specify which previous major versions MUST be supported in compliant implementations. Clear rules, no drama 🫶
3.1.8 Job Creation Operations 🚀
Okay so, to "submit a print job" and create a brand new Job object, a client issues a create request 🎀 A create request is any one of these three operation requests:
- The Print-Job Request: A client that wants to submit a print job with only a single document uses the Print-Job operation 🌸 The operation lets the client "push" the document data to the Printer object by including the document data in the request itself.
- The Print-URI Request: A client that wants to submit a print job with only a single document uses the Print-URI operation 🦋 This time the Printer object "pulls" the document data instead of the client pushing it. The client only includes a URI reference to the document data (not the document data itself) in the request.
- The Create-Job Request: A client that wants to submit a print job with multiple documents uses the Create-Job operation 👑 This operation is followed by an arbitrary number of Send-Document and/or Send-URI operations, each one creating another document for the newly created Job object. The Send-Document operation includes the document data in the request (the client "pushes" the data to the printer), and the Send-URI operation includes only a URI reference to the document data (the Printer "pulls" the data from the referenced location). The last Send-Document or Send-URI request for a given Job object includes a
last-documentoperation attribute set totrue, which tells the printer "this is the last one" 💀
Throughout this model specification, the term "create request" refers to 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 🙈 However, 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 at all.
Job submission time is the moment a client issues a create request ⏰ The initial state of every Job object is pending or pending-held. Later, the Printer object begins processing the print job, and the Job object's state moves to processing. This is known as job processing time. Validation checks happen at both points, but they aren't the same checks 🧚 Some must be done at job submission time, and others must be done at job processing time.
At job submission time, and at the time 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 or not the supplied attributes, attribute syntaxes, and values are supported, by matching them against the Printer object's corresponding xxx-supported attributes. See section 3.2.1.2 for details. [ipp-iig] presents suggested steps for an IPP object to either accept or reject any request, plus additional steps for processing create requests ✨
At job submission time the Printer object NEED NOT perform the validation checks 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, these 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. Also, with a URI, checking that it's available at submission time doesn't guarantee it'll still be available at job processing time 🙈 On top of that, at job processing time the Printer object might discover any of these conditions that weren't detectable at job 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
Here's the tricky part 🥺 At job processing time, the Printer object has already responded with a successful status code to the create request. So if it detects an error, it can't tell the end user about it with an operation status code. Instead, depending on the error, the Printer can set the job-state, job-state-reasons, or job-state-message attributes to the appropriate value(s), so that later queries can report the correct job status 🌈
Note: Asynchronous notification of events is outside the scope of IPP/1.0. 🫶
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. No exceptions, bestie.
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 the data) 💖 For the suggested steps for processing create operations and their Operation and Job Template attributes, see Section 15.
3.2.1.1 Print-Job Request
okay bestie, the Print-Job Request is made of a few groups of attributes, and I'm obsessed with how they're organized 🎀 here's the lineup:
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 matching Job Description attributes described in sections 4.3.23 and 4.3.24. 🌸
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 one. The Printer object MUST support it. It holds the client-supplied Job name. If the client sends it, that value gets used for the job-name attribute of the brand-new Job object ✨ The client MAY automatically add anything that helps the end-user tell their jobs apart, like the application name along with info from the document (the document name, document subject, or source file name). If the client doesn't send it, 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, and the Printer object MUST support it. The value 'true' means total fidelity to the client-supplied Job Template attributes and values is required. If the Printer can't do that, it 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, how it links to other attributes, and especially the Printer object's pdl-override-supported attribute 🧚
document-name (name(MAX)): the client optionally supplies this, and 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 for the end user, using a file name or an application-generated name 🍓 If it's supplied, its value can be used in a manner defined by each implementation. For example, it can be printed along with the Job (job start sheet, page adornments, etc.), used by accounting or resource tracking management tools, or even stored along with the document as a document-level attribute. IPP/1.0 does not support the concept of document-level attributes 🙈
document-format (mimeMediaType): the client optionally supplies this, and the Printer object MUST support it. The value identifies the format of the supplied document data. If the client doesn't supply it, the Printer object assumes the document data is in the format defined by the Printer object's document-format-default attribute. If the client supplies it but the value isn't supported, meaning it isn't one of the values of the Printer object's document-format-supported attribute, the Printer object MUST reject the request and return the client-error-document-format-not-supported status code 💀
document-natural-language (naturalLanguage): the client optionally supplies this, and the Printer object optionally supports it. It specifies the natural language of the document for those 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 🌈
compression (type3 keyword): the client optionally supplies this. The Printer object optionally supports it, along with the compression-supported attribute (see section 4.4.29). It identifies the compression algorithm used on the document data. If the client leaves it out, the Printer object MUST assume the data is not compressed. If the client supplies it and the Printer object supports it, the Printer object uses the matching decompression algorithm on the document data ⭐ If the client supplies it but the value isn't supported (not one of the values of the Printer object's compression-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 😭
job-k-octets (integer(0:MAX)): the client optionally supplies this. The Printer object optionally supports it, along with the job-k-octets-supported attribute (see section 4.4.30). It identifies the total size of the document(s) in K octets being submitted (see section 4.3.17 for the complete semantics). If the client supplies it and the Printer object supports it, the value populates the Job object's job-k-octets Job Description attribute 👑
Note: this applies tojob-k-octetsand the next two attributes (job-impressionsandjob-media-sheets). If the client supplies one of these but the Printer object doesn't support it, the Printer object ignores the client-supplied value. If the client supplies it and the Printer supports it, and the value is within the range of the Printer object'sxxx-supportedattribute, the Printer object MUST use the value to populate the Job object'sxxxattribute. If the client supplies it and the Printer supports it, but the value is outside the range of the Printer object'sxxx-supportedattribute, the Printer object MUST copy the attribute and its value to the Unsupported Attributes response group, reject the request, and return theclient-error-attributes-or-values-not-supportedstatus code. If the client doesn't supply the attribute, the Printer object MAY choose to populate the matching Job object attribute, depending on whether the Printer object supports the attribute and can calculate or discern the correct value 🙈
job-impressions (integer(0:MAX)): the client optionally supplies this. The Printer object optionally supports it, along with the job-impressions-supported attribute (see section 4.4.31). It identifies the total size, in number of impressions, of the document(s) being submitted (see section 4.3.18 for the complete semantics). See the note under job-k-octets 🦋
job-media-sheets (integer(0:MAX)): the client optionally supplies this. The Printer object optionally supports it, along with the job-media-sheets-supported attribute (see section 4.4.32). It identifies the total number of media sheets to be produced for this job (see section 4.3.19 for the complete semantics). See the note under job-k-octets 🌸
Group 2: Job Template Attributes 🧚
The client optionally supplies a set of Job Template attributes, as defined in section 4.2. If the client isn't sending any Job Template attributes in the request, the client SHOULD omit Group 2 rather than send an empty group. Even so, a Printer object MUST be able to accept an empty group 💜
Group 3: Document Content 📄
The client MUST supply the document data to be processed. 💖
Note: in addition to the mandatory parameters required for every operation request, the simplest Print-Job Request is made up of just the "attributes-charset" and "attributes-natural-language" operation attributes, the printer-uri target operation attribute, and the Document Content, and nothing else. In this 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 requested (see Section 3.1.4.1) (if those are supported, otherwise using the Printer object's default natural language and charset), and - at job processing time, uses its corresponding default value attributes for the supported Job Template attributes that were not supplied by the client as IPP attributes or embedded instructions in the document data ✨
3.2.1.2 Print-Job Response ✨
okay so the Printer object MUST send the client these sets of attributes in the Print-Job Response, no skipping bestie 💅
Group 1: Operation Attributes 🎀
Status Message: okay so every response has a REQUIRED status code 🫶 and on top of that the response OPTIONALLY includes a status-message (text) operation attribute, like we covered in sections 14 and 3.1.6 💌 if the client sends unsupported or conflicting Job Template attributes or values, the Printer object MUST reject or accept the Print-Job request based on whether the client set ipp-attribute-fidelity to 'true' or 'false' 😭 the Implementer's Guide [ipp-iig] has the full suggested steps for processing a create request, so go check that 📖
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 🙈
this group holds the Operation and Job Template attributes the client sent that the Printer object either doesn't support or that conflict with each other (see the Implementer's Guide [ipp-iig]) 💀 if there's nothing unsupported to report, the Printer object SHOULD leave Group 2 out instead of sending an empty one 🍓 that said, a client MUST be able to handle an empty group, no cap 💜
unsupported stuff falls into three buckets:
- the Printer object doesn't support the supplied attribute at all, no matter the syntax or value 🙅♀️
- the Printer object supports the attribute, but not some or all of the syntaxes or values the client sent (aka they aren't in its corresponding
xxx-supportedattribute) 🥺 - the Printer object supports the attribute and the values, but the values clash because they break a constraint, like not being able to staple transparencies 📄✂️
for an unsupported attribute name, the Printer object sends back the client's attribute with a substituted out-of-band value of unsupported, which means no support for the attribute itself (see the beginning of section 4.1) 🦋
for a supported attribute with some unsupported syntaxes or values, the Printer object just sends back the client's attribute with those unsupported syntaxes or values as the client gave them 💅 this shows the attribute is supported, just not that specific syntax or value. if the client sends a multi-valued attribute and the Printer object only supports a subset of those syntaxes or values, the Printer object MUST return only the unsupported ones 🫧
for two or more supported attribute values that clash (each one is fine alone, but they conflict when requested together in the same job) 😵💫 the Printer object MUST return all the values it ignores or substitutes to fix the conflict, but none of the ones it's still using ✨ how it resolves the conflict is implementation dependent, and the Implementer's Guide [ipp-iig] has an example 📚
in all three cases, the client's ipp-attribute-fidelity value does NOT change what the Printer object returns 🙅♀️ it only decides whether the Print-Job operation gets accepted or rejected 🎭 if the job is accepted, the client can query it with the Get-Job-Attributes operation, asking for the unsupported attributes that came back in the create response, to see which ones were ignored (not stored on the Job object) and which ones got stored with other substituted values 🔍
Group 3: Job Object Attributes 🧚
job-uri (uri): the Printer object MUST return the Job object's URI by sending back the contents of the REQUIRED job-uri Job object attribute 🌸 the client uses that URI when pointing operations at the Job object. the Printer object always uses its configured security policy when making the new URI 🔐 but if it 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 came over a secure channel, the Printer object MUST generate a Job URI that uses that secure channel too 🔒
job-id (integer(1:MAX)): the Printer object MUST return the Job object's Job ID by returning the REQUIRED job-id Job object attribute 🎫 the client pairs this job-id with the printer-uri attribute from the Print-Job Request when it sends Job operations to the Printer object 💌
job-state: the Printer object MUST return the Job object's REQUIRED job-state attribute 🫶 its value (plus the next attribute, job-state-reasons) comes from a "snapshot" of the new Job object taken at some meaningful moment (implementation defined) between when the Printer object gets the Print-Job Request and when it sends the response ⏱️
job-state-reasons: the Printer object OPTIONALLY returns the Job object's OPTIONAL job-state-reasons attribute 🌈 if the Printer object supports it, it MUST be in the response. if it's missing from the response, the client can assume it isn't supported and won't show up in a later Job object query 🫠
job-state-message: the Printer object OPTIONALLY returns the Job object's OPTIONAL job-state-message attribute 💬 if the Printer object supports it, it MUST be in the response. if it's missing, the client can assume it isn't supported and won't come back in a later Job object query 🙈
number-of-intervening-jobs: the Printer object OPTIONALLY returns the Job object's OPTIONAL number-of-intervening-jobs attribute 🧮 if the Printer object supports it, it MUST be in the response. if it's missing, the client can assume it isn't supported and it won't be returned in a later Job object query 💅
Note: any printer state info that affects a job's state already shows up in thejob-stateandjob-state-reasonsattributes, so returning just those is enough, and there's no need for specific printer status attributes 🫧
Note: in addition to the mandatory parameters every operation response needs, 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 is successful-ok and there's no status-message operation attribute 🌸
3.2.2 Print-URI Operation 🔗
this OPTIONAL operation works just like the Print-Job operation (section 3.2.1), except the client gives a URI reference to the document data using the document-uri (uri) operation attribute (in Group 1), instead of sending the document data itself 📎 before responding, the Printer MUST check that it supports the retrieval method implied by the URI (like http, ftp, etc.) and MUST check that the URI syntax is valid 🧐 if the client's URI scheme isn't supported (meaning it's not 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 🙅♀️ see The Implementer's Guide [ipp-iig] for suggested extra checks 📚 the Printer NEED NOT follow the reference or validate what's inside it 🫶
if the Printer object supports this operation, it MUST support the reference-uri-schemes-supported Printer attribute (see section 4.4.24) 💜
it's up to the IPP object to interpret the URI and then "pull" the document from the source the URI points to 🧲
3.2.3 Validate-Job Operation ✅
this REQUIRED operation is kind of like the Print-Job operation (section 3.2.1), except the client sends no document data and the Printer allocates no resources (so no new Job object gets made) 🙅♀️ it's only used to check a printer's capabilities against whatever attributes the client put in the Validate-Job request 🔍 with it, a client can confirm an identical Print-Job operation (with the document data) would be accepted 🥰 it also does the same security negotiation as Print-Job (see section 8), so the client can make sure its security needs and the Printer object's can be met before doing a Print-Job operation 🔐
Note: the Validate-Job operation doesn't accept a document-uri attribute, so a client can check whether the same Print-URI operation would 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 🎀 but 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 sends no document data and no reference to document data 🙅♀️ the client also doesn't supply the document-name, document-format, compression, or document-natural-language operation attributes 🫧 this operation is 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 too 🌈
if the Printer object supports this operation, it MUST support the multiple-operation-time-out Printer attribute (see section 4.4.28) ⏳💖
3.2.5 Get-Printer-Attributes Operation ✨
okay bestie, this operation is REQUIRED 💅 and 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 a matching attribute set with the values filled in 🦋.
For Printer objects, the attribute group names are:
'job-template': all of the Job Template attributes that apply to a Printer object (the last two columns of the table in Section 4.2).'printer-description': the attributes specified in Section 4.4.'all': the special group'all'that includes all supported attributes.
Since a client MAY request specific attributes or named groups, overlap can totally happen 👀. Like, if a client asks for 'printer-name' and 'all', it's literally 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 multiple times. Still, the client SHOULD NOT request the same attribute in multiple ways 🙈.
It is NOT REQUIRED that a Printer object support every attribute in a group, since some attributes are OPTIONAL 🌸. BUT it is REQUIRED that each Printer object support all group names 🫶.
3.2.5.1 Get-Printer-Attributes Request 📮
Here's what's in the Get-Printer-Attributes Request:
Group 1: Operation Attributes 🎀
- Natural Language and Character Set:
attributes-charsetandattributes-natural-languageattributes 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 in whose values the requester is interested. The Printer object MUST support this attribute. If the client omits this attribute, the Printer MUST respond as if this attribute had been supplied with a value of'all'.document-format(mimeMediaType): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. This attribute is useful for a Printer object to figure out the set of supported attribute values that relate to the requested document format. The Printer object MUST return the attributes and values that it uses to validate a job on a create or Validate-Job operation in which 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 the specified document format. By specifying the document format, the client can get the Printer object to eliminate the attributes and values that are not supported for a specific document format. For example, a Printer object might have multiple interpreters to support both'application/postscript'(for PostScript) and'text/plain'(for text) documents. However, for only one of those interpreters might the Printer object be able to support"number-up"with values of'1','2', and'4'. For the other interpreter it might only be able to support"number-up"with a value of'1'. So a client can use the Get-Printer-Attributes operation to get 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 different document format when validating jobs in the create and Validate-Job operations, it MUST NOT distinguish between different document formats in the Get-Printer-Attributes operation. If the Printer object does distinguish between different sets of supported values for each different document format specified by the client, this specialization applies ONLY to the following Printer object attributes:
- Printer attributes that are Job Template attributes (
xxx-default,xxx-supported, andxxx-readyin 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, andreference-uri-schemes-supported
The values of all other Printer object attributes (including document-format-supported) remain invariant with respect to the client-supplied document format (except for new Printer description attributes as registered according to section 6.2).
If the client omits this document-format operation attribute, the Printer object MUST respond as if the attribute 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, since the Printer object's document-format-default may be 'application/octet-stream', in which case the returned attributes and values are for the union of the document formats that 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 thedocument-formatoperation attribute that is not supported by the Printer, i.e., is not among the values of the Printer object'sdocument-format-supportedattribute, 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 returned in every response, the response OPTIONALLY includes a
status-message(text) operation attribute as described in section 3.1.6. - Natural Language and Character Set: The
attributes-charsetandattributes-natural-languageattributes as described in section 3.1.4.2.
Group 2: Unsupported Attributes 🙅♀️
This is a set of Operation attributes supplied by the client (in the request) that are not supported by the Printer object or that conflict with one another (see sections 3.2.1.2 and 16). 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 is not returning any Unsupported Attributes in the response, the Printer object SHOULD omit Group 2 rather than sending an empty group. However, a client MUST be able to accept an empty group.
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 which is not supported. 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) for which the Printer object does not know the value. Also, the Printer object MUST respond with the 'no-value' for any supported attribute (including all REQUIRED attributes) for which the system administrator has not configured a value. 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 belonging 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 is returned.
This operation is similar to the Get-Job-Attributes operation, except that this Get-Jobs operation returns attributes from possibly more than one object (see the description of Job attribute group names in section 3.3.4) 💜.
3.2.6.1 Get-Jobs Request ✨
okay so the client sends the Get-Jobs request to a Printer object 🖨️💖 these are the attribute groups that make up the Get-Jobs Request:
Group 1: Operation Attributes 🎀
- Natural Language and Character Set: the
attributes-charsetandattributes-natural-languageattributes, as described in section 3.1.4.1 🌸 - Target: the
printer-uri(uri) operation attribute 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 supply this one, and the Printer object MUST support it. It's an integer that caps how many Job objects come back. It's a "stateless limit", so if the client sends 'N', only the first 'N' jobs are returned in the Get-Jobs Response. There's no way to ask for the next 'M' jobs after those first 'N' 🙃 If the client doesn't supply it, the Printer object responds with all applicable jobs 🌈requested-attributes(1setOf keyword): the client can optionally supply this, and the Printer object MUST support it ✨ It's a set of Job attribute names and/or attribute group names the requester is interested in, and that set comes back for each Job object that's 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 doesn't supply it, the Printer MUST respond as if the client had supplied two values:job-uriandjob-id💅which-jobs(type2 keyword): the client can optionally supply this, and the Printer object MUST support it. It says which Job objects MUST be returned by the Printer object. The values are:completed: includes any Job object whose state iscompleted,canceled, oraborted🍓not-completed: includes any Job object whose state ispending,processing,processing-stopped, orpending-held🧚
The Printer object MUST support both values. However, if the implementation doesn't keep jobs in the completed, canceled, or aborted states, 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. Rude 💀 but valid.
If the client doesn't supply this attribute, the Printer object MUST respond as if the client had supplied it with a value of not-completed 💜
my-jobs(boolean): the client can optionally supply this, and the Printer object MUST support it. It indicates whether ALL jobs or just the jobs submitted by the requesting user MUST be returned by the Printer object. If the client doesn't supply it, the Printer object MUST respond as if the client had suppliedfalse, i.e., all jobs 👑 How the requesting user gets authenticated and matched to their jobs is described in section 8 🔐
3.2.6.2 Get-Jobs Response 🦋
okay this is the good part 🥹 the Printer object returns ALL of the Job objects that match the criteria the client set in the request. It's totally possible that no Job objects come back, either because there are literally no Job objects at the Printer or because none of them match what the client asked for 🫠 If the client requests any Job attributes at all, there's a set of Job Object Attributes returned for each Job object.
Group 1: Operation Attributes 🎀
- Status Message: in addition to the REQUIRED status code that's returned in every response, the response OPTIONALLY includes a
status-message(text) operation attribute, as described in sections 14 and 3.1.6 💬 - Natural Language and Character Set: the
attributes-charsetandattributes-natural-languageattributes, as described in section 3.1.4.2 🌍
Group 2: Unsupported Attributes 🙅♀️
This is a set of Operation attributes that the client supplied in the request but that are either not supported by the Printer object or that conflict with one another. (See sections 3.2.1.2 and the Implementer's Guide [ipp-iig].) The response NEED NOT contain the requested-attributes operation attribute with any supplied values (attribute keywords) that the client requested but that aren't supported by the IPP object. If the Printer object isn't returning any Unsupported Attributes, it SHOULD omit Group 2 rather than sending an empty group. Still, a client MUST be able to accept an empty group 🥰
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's not 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. Check the description of the 'out-of-band' values at the beginning of Section 4.1 too 🔍
Jobs come back in a specific order:
- If the client requests all 'completed' Jobs (Jobs in the 'completed', 'aborted', or 'canceled' states), the Jobs are returned newest to oldest, based on actual completion time 🕰️
- If the client requests all 'not-completed' Jobs (Jobs in the 'pending', 'processing', 'pending-held', and 'processing-stopped' states), the Jobs are returned in relative chronological order of expected time to complete. That's based on whatever scheduling algorithm is configured for the Printer object 📅
3.3 Job Operations 💜
All Job operations are directed at Job objects. A client MUST always supply some way of identifying the Job object so the operation has the correct target 🎯 That job identification MAY be either a single Job URI or a combination 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 OPTIONAL operation lets a client create a multi-document Job object that starts out "empty" (no documents yet) ✨ In the Create-Job response, the Printer object returns the Job object's URI (the 'job-uri' attribute) and the Job object's 32-bit identifier (the 'job-id' attribute). For each new document the client wants to add, the client uses a Send-Document operation. Each Send-Document Request contains the entire stream of document data for one document 📄
Okay, this part's giving drama 😭 The Create-Job and the send operations that follow (Send-Document or Send-URI operations) could be spread out over an arbitrarily long period of time for a particular job. So a client MUST send another send operation within a minimum time interval defined by the IPP Printer after it receives the previous request for the job ⏰ If a Printer object supports multiple document jobs, the Printer object MUST support the 'multiple-operation-time-out' attribute (see section 4.4.28). That attribute gives 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, at some point after the minimum time interval set 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's 'job-state-reasons' attribute (see section 4.3.8) if supported, and clean up all resources associated with 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 is still around when that send operation arrives.
- Assume the last send operation received was actually the last document (as if the 'last-document' flag had been set to 'true'). Close the Job object and proceed to process it, which means 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's 'job-state-reasons' attribute (see section 4.3.8), if supported. This lets the user or an operator decide whether to keep processing the Job by moving it back to 'pending', or to cancel it 🙌
Each implementation gets to decide the "best" action to take, based on local policy, whether any documents have been 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 to the point where some media sheets have been printed. Oops 🙈
3.3.1.1 Send-Document Request ✨
okay so here's what a Send-Document Request is made of 🎀 it's organized into attribute groups, and it's giving very put-together 💅
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: you either send (1) printer-uri (uri) plus job-id (integer(1:MAX)), or (2) the job-uri (uri) operation attribute(s). Either way, that's how you point at the target, 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 🫶
document-name (name(MAX)): the client can optionally supply this one, and the Printer object MUST support it. It holds the client-supplied document name. The document name MAY be different from the Job name. It might be helpful, but it need not be unique across multiple documents in the same Job. Usually the client software fills this in for the end user, using a file name or an application-generated name. For more about this attribute, check the description of the document-name operation attribute in the Print-Job Request (section 3.2.1.1) 📄
document-format (mimeMediaType): the client can optionally supply this attribute, and the Printer object MUST support it. The value tells the Printer object what format the document data is in. If the client doesn't send it, the Printer object assumes the document data is in the format defined by the Printer object's document-format-default attribute. If the client does send it, but the value isn't supported (meaning it isn't one of the values of the Printer object's document-format-supported attribute), the Printer object MUST reject the request and return the client-error-document-format-not-supported status code. no thanks to unsupported formats 🙅♀️
document-natural-language (naturalLanguage): the client can optionally supply this attribute, and the Printer object can optionally support it too. It specifies the natural language of the document, 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 🌈
compression (type3 keyword): the client can optionally supply this attribute. The Printer object can optionally support it, along with the compression-supported attribute (see section 4.4.29). The client-supplied compression operation attribute identifies the compression algorithm used on the document data. If the client leaves this attribute out, the Printer object MUST assume the data is not compressed. If the client supplies it and the Printer object supports it, the Printer object MUST use the matching decompression algorithm on the document data. If the client supplies it but the value isn't supported (meaning it isn't one of the values of the Printer object's compression-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. 🗜️
last-document (boolean): the client MUST supply this attribute, and the Printer object MUST support it. It's a boolean flag that's set to true if this is the last document for the Job, and false otherwise. this one is the big deal for knowing when a Job is done 🏁
Group 2: Document Content 📦
The client MUST supply the document data if the last-document flag is set to false. BUT, since a client might not know that the previous document sent with a Send-Document (or Send-URI) operation was the last one (meaning the last-document attribute was set to false), it's legal to send a Send-Document request with no document data where the last-document flag is set to true. Such a request MUST NOT increment the value of the Job object's number-of-documents attribute, since no real document was added to the job. so no fake documents getting counted, periodt 💅
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: on top of the REQUIRED status code that every response gets, the response can optionally include a status-message (text) operation attribute, as described in sections 14 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 🙈
This is a set of Operation attributes that the client sent in the request which the Printer object doesn't support, or which conflict with one another (see sections 3.2.1.2 and the Implementer's Guide [ipp-iig]). If the Printer object isn't returning any Unsupported Attributes in the response, it SHOULD omit Group 2 rather than sending an empty group. However, a client MUST be able to accept an empty group. no drama, just be ready for it 🫶
Group 3: Job Object Attributes 🎀
This is the same set of attributes described in the Print-Job response (see section 3.2.1.2). it's giving consistency ✨
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 (document-uri operation attribute) instead of the document data itself. If a Printer object supports this operation, clients can use both the Send-URI and Send-Document operations 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 (rather than using a Send-URI operation with no document-uri operation attribute). so for "that was the last one" energy, it's Send-Document, not Send-URI 🏁
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 it does in the Print-URI operation 🔍
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 the time it's completed, canceled, or aborted. Since a Job might already be printing by the time a Cancel-Job is received, some media sheet pages might get printed before the job is actually terminated. so it's not an instant undo, bestie 🥲
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: you either send (1) printer-uri (uri) plus job-id (integer(1:MAX)), or (2) the job-uri (uri) operation attribute(s). Either way, that's how the target gets defined 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 can optionally supply this attribute, and the Printer object can optionally support it. It's a message to the operator. This message attribute is NOT the same as the job-message-from-operator attribute. That one is used to report 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 whether) to display this message to the operator 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: on top of the REQUIRED status code that every response gets, the response can optionally include a status-message (text) operation attribute, as described in sections 14 and 3.1.6.
If the job is already in the completed, aborted, or canceled state, or the process-to-stop-point value is set in the Job's job-state-reasons attribute, the Printer object MUST reject the request and return the client-error-not-possible error status code. 🙅♀️ too late bestie, it's already done
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 🙈
This is a set of Operation attributes that the client sent in the request which the Printer object doesn't support, or which conflict with one another (see section 3.2.1.2 and the Implementer's Guide [ipp-iig]). If the Printer object isn't returning any Unsupported Attributes in the response, it SHOULD omit Group 2 rather than sending an empty group. However, a client MUST be able to accept an empty group.
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 in the canceled state, not the completed state. this is the "it's handled, just wait" signal 🧚♀️✨
3.3.4 Get-Job-Attributes Operation 🎀
bestie, this one is REQUIRED 💅 and it's basically the sibling of Get-Printer-Attributes (section 3.2.5) with a glow-up. Same vibe, but you aim it at a Job object instead of a Printer object 🦋 There's also no "document-format" operation attribute when you query a Job, and what comes back is a set of Job object attributes instead of Printer ones ✨
For Jobs, the attribute group names are:
job-template: all of the Job Template attributes that apply to a Job object (the first column of the table in Section 4.2) 🌸job-description: all of the Job Description attributes specified in Section 4.3 💜all: the special groupallthat includes every supported attribute 👑
Okay, overlap alert 🚨 A client MAY ask for specific attributes or named groups, so things can double up. Say you request job-name and job-description. You're actually asking for job-name twice: once by naming it, and once because it's inside the job-description group. In that case the Printer object NEED NOT return the attribute only once in the response, even if it was requested multiple times. Still, the client SHOULD NOT ask for the same attribute in multiple ways 🙈
It is NOT REQUIRED that a Job object support every attribute in a group, since some attributes are OPTIONAL 🍓 But each Job object REQUIRED to support all of the group names, so it is REQUIRED that each Job object support all group names 🫶
3.3.4.1 Get-Job-Attributes Request 💖
When the request is aimed at a Job object, the Get-Job-Attributes Request is made up of these attribute groups:
Group 1: Operation Attributes
- Natural Language and Character Set: the
attributes-charsetandattributes-natural-languageattributes, as described in section 3.1.4.1. - Target: either (1) the
printer-uri(uri) plusjob-id(integer(1:MAX)), or (2) thejob-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's a set of attribute names and/or attribute group names whose values the requester is interested in. If the client leaves this attribute out, the IPP object MUST respond as if this attribute had been supplied with a value ofall. 👑
3.3.4.2 Get-Job-Attributes Response 🌈
The Printer object sends back these sets of attributes as part of the Get-Job-Attributes Response:
Group 1: Operation Attributes
- Status Message: on top of the status code that's REQUIRED in every response, the response OPTIONALLY includes a
status-message(text) operation attribute, as described in sections 14 and 3.1.6. 💬 - Natural Language and Character Set: the
attributes-charsetandattributes-natural-languageattributes, as described in section 3.1.4.2. Theattributes-natural-languageMAY be the natural language of the Job object, rather than the one that was requested. 🌸
Group 2: Unsupported Attributes
This group holds the Operation attributes the client sent in the request that the Printer object doesn't support, or that conflict with one another (see sections 3.2.1.2 and the Implementer's Guide [ipp-iig]). The response NEED NOT contain the requested-attributes operation attribute with any supplied values (attribute keywords) that the client asked for but that the IPP object doesn't support. If the Printer object isn't returning any Unsupported Attributes, it SHOULD omit Group 2 rather than send an empty group. Still, a client MUST be able to accept an empty group. 🫶
Group 3: Job Object Attributes
This is the set of requested attributes and their current values. The IPP object ignores (doesn't respond with) any requested attribute or value that isn't supported, or that is 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 IPP object MUST respond with the 'unknown' value for any supported attribute (including all REQUIRED attributes) whose value it doesn't know, because revealing it would violate the security policy. See the description of "out-of-band" values at the beginning of Section 4.1. 🧚
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. Lots of these attributes come from other relevant specifications:
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 the attribute. ✨
Note: keywords aren't the only thing used to identify attributes. One of the attribute syntaxes below is "keyword", 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 💜
This section defines the basic attribute syntax types that all clients and IPP objects MUST be able to accept in responses, and accept in requests, respectively. Each attribute description in sections 3 and 4 includes the name of its attribute syntax(es) in the heading (in parentheses). A conforming implementation of an attribute MUST include the semantics of the attribute syntax(es) identified there. Section 6.3 explains how the protocol can be extended with new attribute syntaxes. 🌈
The attribute syntaxes are specified in the sub-sections below, where each sub-section heading is the keyword name of the attribute syntax, inside single quotes. In operation requests and responses, each attribute value MUST be represented as one of the attribute syntaxes specified in the sub-section heading for that attribute. On top of that, the value of an attribute in a response (but not in a request) MAY be one of the "out-of-band" values. 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 system administrator hasn't configured a value yet. 🍓
The Encoding and Transport specification [RFC2565] defines the mechanisms for passing "out-of-band" values. All attributes in a request MUST have one or more values, as defined in Sections 4.2 to 4.4. So clients MUST NOT supply attributes with "out-of-band" values. Every attribute 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. 🫶
Most attributes are defined with a single attribute syntax. A few, though (e.g., job-sheet, media, job-hold-until), are defined with several attribute syntaxes, depending on the value. These multiple attribute syntaxes are separated by the "|" character in the sub-section heading to show the choice. Since each value MUST be tagged with 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. 💖
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 much shorter than MAX, the definition of that attribute will include a qualifier that sets the maximum length for its values. 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 it's supplied with a longer text string through some external interface (other than the protocol), implementations are free to truncate it to this shorter length limit. ✂️
In this specification, all text attributes are defined using the 'text' syntax. But 'text' is only used for brevity. Its formal interpretation is: 'textWithoutLanguage' | 'textWithLanguage'. That means that for any attribute defined in this specification with 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 syntax 'text' never appears "on-the-wire". 👀
Both 'textWithoutLanguage' and 'textWithLanguage' are needed for real-world interoperability between sites and systems that use different natural languages to communicate. 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 by the attributes-natural-language job attribute defined in section 4.3.24, and there's no need to identify the natural language for each text string value by value. 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. In those cases, 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 a sequence of zero or more characters. 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 those charsets are registered with IANA [IANA-CS]. See Section 4.1.7 for the specification of the 'charset' attribute syntax, including its restricted semantics and examples of charsets. 🌈
4.1.1.2 'textWithLanguage' 💖
okay so 'textWithLanguage' is a compound syntax, bestie 🎀 it's made of two parts: a 'textWithoutLanguage' part, plus an extra 'naturalLanguage' part (see section 4.1.8) that overrides whatever natural language is in force. The 'naturalLanguage' part names the language for that one text value and only that value 🫶 For any text attribute, the 'textWithoutLanguage' part is capped at that attribute's max length, but the 'naturalLanguage' part is always capped at 63 octets. Using 'textWithLanguage' instead of the usual 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism, and all IPP objects and clients MUST support it 💅
If the attribute is multi-valued (1setOf text), then every value whose language needs overriding MUST be written with the 'textWithLanguage' syntax ✨ Any other values in a multi-valued 'text' 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, even if the Printer object doesn't support that language 😭 Furthermore, the Printer object MUST accept and store any 'textWithLanguage' attribute value, whether or not it supports that language. These requirements don't depend on the "ipp-attribute-fidelity" operation attribute that the client MAY supply 🦋
Example: If the client supplies the "attributes-natural-language" operation attribute with the value: 'en' indicating 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 [RFC2565] for a detailed example of the 'textWithLanguage' attribute syntax. 🧚
4.1.2 'name' 🌷
This syntax type is for user-friendly strings, like a Printer name, that matter more to humans than identifiers do. Names are never translated from one natural language to another 💭 The 'name' syntax is basically the same as 'text', including the REQUIRED support of UTF-8, except the characters are limited so that the encoded form MUST NOT exceed 255 (MAX) octets.
Also like 'text', 'name' is really shorthand for either 'nameWithoutLanguage' or 'nameWithLanguage'. That means all IPP objects and clients MUST support both the 'nameWithoutLanguage' and 'nameWithLanguage' attribute syntaxes. In real life, though, objects and clients only accept and return one of the two per attribute. The syntax 'name' never shows up "on-the-wire" 👀
Note: Only the 'text' and 'name' attribute syntaxes permit the Natural Language Override mechanism. 🫧
Some attributes are defined as type3 keyword | name. These attributes take values that are either type3 keywords or names, which lets a site administrator extend them with locally defined values 🏡 Those names aren't registered with IANA, so they're totally a site-specific thing 🎀
4.1.2.1 'nameWithoutLanguage' 🍓
The 'nameWithoutLanguage' syntax is a value made of zero or more characters, as long as its encoded form doesn't go past MAX octets. Simple and clean ✨
4.1.2.2 'nameWithLanguage' 🦋
The 'nameWithLanguage' attribute syntax is a compound syntax with two parts: a 'nameWithoutLanguage' part, plus an extra 'naturalLanguage' part (see section 4.1.8) that overrides the natural language in force. That 'naturalLanguage' part tells you the language for that name value and that name value alone 💜
'nameWithLanguage' works exactly like 'textWithLanguage'. 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 🌈
Example: If the client supplies the "attributes-natural-language" operation attribute with the value: 'en' indicating English, but the "printer-name" attribute is in German, the client MUST use the 'nameWithLanguage' attribute syntax as follows:
'de': Natural Language Override indicating German
'Farbdrucker': the Printer name in German4.1.2.3 Matching 'name' attribute values 🔍
When you're checking two 'name' values for equality, like 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 matching 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. 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' 🔑
The 'keyword' attribute syntax is a sequence of characters, length 1 to 255, using only US-ASCII [ASCII] encoded lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot ("."), and underscore ("_"). The first character MUST be a lowercase letter. Keywords MUST also be in U.S. English 🇺🇸
This syntax type is for enumerating semantic identifiers of entities in the abstract protocol, meaning the entities identified in this document. Keywords are used as attribute names or as values of attributes. Unlike 'text' and 'name' values, 'keyword' values MUST NOT use the Natural Language Override mechanism, because 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 displayable, user-friendly words and phrases that are localized to 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 💅
In the definition for each attribute of this syntax type, the full set of defined keyword values for that attribute is listed.
When a keyword is used to represent an attribute (its name), it MUST be unique across the full scope of all IPP objects and attributes. When a keyword is used to represent a value of an attribute, it MUST be unique just within the scope of that attribute. That is, 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 describes 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 indicate different levels of review for extensions (see section 6.1). 🌸
4.1.4 'enum' 🎲
The 'enum' attribute syntax is an enumerated integer value in the range from 1 to 2**31 - 1 (MAX) 🔢 Each value has an associated 'keyword' name. In the definition for each attribute of this syntax type, the full set of possible values for that attribute is listed. This syntax type is for attributes whose enum values are assigned by other standards, like SNMP MIBs. A bunch of attribute enum values in this specification are also used for corresponding attributes in other standards [RFC1759]. This syntax type is NOT used for attributes that the system administrator can assign values to. Section 6.1 describes how the protocol can be extended with new enum values 🌟
Enum values are for use in the protocol. A user interface will provide a mapping between protocol enum values and displayable, user-friendly words and phrases that are localized to 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 indicate different levels of review for extensions (see section 6.1). ✨
4.1.5 'uri' 🦋
The 'uri' attribute 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 from [RFC2396] instead 🫶
4.1.6 'uriScheme' 🧚
The 'uriScheme' attribute syntax is a sequence of characters representing a URI scheme according to RFC 2396 [RFC2396]. RFC 2396 says scheme 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 type are these keywords:
'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' 🎀
okay bestie, charsets are giving main character energy 💅 A charset is a coded character set AND an encoding scheme, both at once. They get used to label certain document contents and 'text' and 'name' attribute values ✨ The syntax and semantics come from [RFC2046] and live in the IANA character-set Registry [IANA-CS], following the IANA procedures [RFC2278]. RFC 2046 says the values are case-insensitive US-ASCII, but IPP goes full lowercase for all charset values in IPP attributes so IPP clients and Printer objects can compare them easily 🫶
If a charset has more than one name (alias) in the IANA registry, the one labeled "(preferred MIME name)" MUST be used, as long as it's there 🙏
Charset values used for IPP attribute values top out at 63 octets 📏
Some examples, iykyk 🍓
'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set
(UCS) represented as 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] eliminates 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
that is used by Latin languages in the Western Hemisphere and
Western Europe. US-ASCII is a subset charset.
'iso-10646-ucs-2': ISO 10646 Universal Multiple-Octet Coded
Character Set (UCS) represented as two octets (UCS-2), with the
high order octet of each pair coming first (so-called Big Endian
integer).Some attribute descriptions MAY place extra requirements on which charset values can be used 🧐 For example, they can make certain charsets REQUIRED values that MUST be supported, or add restrictions like needing the charset to have US-ASCII as a subset charset. Not me having to read all of that 💀
4.1.8 'naturalLanguage' 🌍
The 'naturalLanguage' attribute syntax is a standard identifier for a natural language and, optionally, a country. The values are defined by [RFC1766]. RFC 1766 says they're case-insensitive US-ASCII, but IPP goes all lowercase so clients and Printer objects can compare them without any drama 💖 Examples:
'en': for English
'en-us': for US English
'fr': for French
'de': for GermanMax length for 'naturalLanguage' values in IPP attributes is 63 octets 🎀
4.1.9 'mimeMediaType' 🦋
The 'mimeMediaType' attribute syntax is the Internet Media Type (sometimes called MIME type), defined by [RFC2046] and registered under the procedures of [RFC2048], for identifying a document format 📄 The value MAY include a charset parameter, depending on how the Media Type is specified in the IANA Registry [IANA-MT]. Most other IPP syntax types are lowercase-only, but this one lets you mix cases, and it's still case-insensitive 🌈
Examples, slay 💅
'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]
'text/plain, charset=iso-10646-ucs-2': A plain text document in
ISO 10646 represented in two octets (UCS-2) [ISO10646-1]
'application/postscript': A PostScript document [RFC2046]
'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape
sequence embedded in the document data)
'application/octet-stream': Auto-sense - see belowOne special type is 'application/octet-stream' 👀 If the Printer object supports it, the Printer object MUST be capable of auto-sensing the format of the document data. If the Printer object's default value attribute "document-format-default" is set to 'application/octet-stream', then the Printer object not only supports auto-sensing, it also depends on the result of auto-sensing whenever the client doesn't supply the "document-format" attribute 🔍 If the client does supply a document format value, the Printer MUST rely on that supplied attribute and NOT trust its auto-sensing algorithm. Here's the tea ☕
- 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 any automatic format detection mechanism. For example, the client may be requesting the printing of a PostScript file as a 'text/plain' document. 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: The auto-sensing algorithm is probabilistic. If the client requests both auto-sensing ("document-format" set to 'application/octet-stream') and true fidelity ("ipp-attribute-fidelity" set to 'true'), 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), but it is able to guarantee that its auto-sensing mechanism gets used. 🙈
Max length for a 'mimeMediaType' value in IPP attributes is 255 octets 📏
4.1.10 'octetString' 🔥
The 'octetString' attribute syntax is a sequence of octets, encoded in a maximum of 1023 octets. Sub-section headers show this with 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' 💜
4.1.12 'integer' 🔢
The 'integer' attribute syntax is an integer from -2**31 (MIN) to 2**31 - 1 (MAX). Each attribute can set its own range in sub-section headers if it's different from the full range. For example, job-priority (integer(1:100)) for the "job-priority" attribute 🎯 Enforcing that extra constraint is up to the IPP objects, not the protocol, so that's on them, 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 description has a range constraint (written as X:Y, meaning X is the minimum and Y is the maximum), then that 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 [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 displayable, user-friendly words or presentation values, localized to the user's natural language and date format 🌸
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 semantics come from the suggested values in the Printer MIB [RFC1759]. The cross feed direction resolution matches the prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed direction resolution matches prtMarkerAddressabilityFeedDir, and the units match 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'That's a 300 dpi cross-feed direction resolution and a 600 dpi feed direction resolution, since the '3' means dots per inch (dpi) 🎀
4.1.16 '1setOf X' 👑
The '1setOf X' attribute syntax is 1 or more values of attribute syntax type X. It's used for multi-valued attributes 🍓 It's called '1setOf' rather than just 'setOf' as a reminder that the set of values MUST NOT be empty (a set of size 0 is a no-go). 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 so Job Template attributes are the bits that describe how a job gets processed 🖨️✨ Support for them by a Printer object is OPTIONAL (see section 13.2.3 for a description of support for OPTIONAL attributes). Clients can also OPTIONALLY supply them in create requests 🫶
Every Job Template attribute has to follow these rules. For each Job Template attribute called xxx:
- If the Printer object supports
xxxthen it MUST support both axxx-defaultattribute (unless there is a "No" in the table below) and axxx-supportedattribute. If the Printer object doesn't supportxxx, then it MUST support neither anxxx-defaultattribute nor anxxx-supportedattribute, and it MUST treat an attributexxxsupplied by a client as unsupported. An attributexxxmay be supported for some document formats and not supported for other document formats. For example, it is expected that a Printer object would only supportorientation-requestedfor some document formats (such astext/plainortext/html) but not others (such asapplication/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 indicating that the Printer object apply its default job processing behavior at job processing time if the document content does not contain an embedded instruction indicating an xxx-related behavior.
Note: Since an administrator MAY change the default value attribute after a Job object has been submitted but before it has been processed, the default value used by the Printer object at job processing time may be different that the default value in effect at job submission time. 👀
- The
xxx-supportedattribute is a Printer object attribute that describes which job processing behaviors are supported by that Printer object. A client can query the Printer object to find out what xxx-related behaviors are supported by inspecting the returned values of thexxx-supportedattribute. 🔍
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. 🌈
- The
xxx-defaultdefault value attribute describes what will be done at job processing time when no other job processing information is supplied by the client (either explicitly as an IPP attribute in the create request or implicitly as an embedded instruction within the document data). 🎀
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. The application SHOULD also query the default value attributes. If the application then limits selectable values to only those values that are supported, the application can guarantee that the values supplied by the client in the create request all fall within the set of supported values at the Printer. 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 an example of a Job Template attribute. It can take on a set of values such as 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 contains a set of supported values. The default value attribute contains the finishing value(s) that will be used for a new Job if the client does not supply a finishings attribute in the create request and the document data does not contain any corresponding 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 that they are a subset of the supported values identified in the Printer object's finishings-supported attribute. See section 3.2.1.2. 📎💜
The table below sums up the names and relationships for all Job Template attributes. The first column of the table (labeled "Job Attribute") shows the name and syntax for each Job Template attribute in the Job object. These are the attributes that the client can optionally supply in a create request. The last two columns (labeled "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 (that is, the attribute is simply not applicable). For brevity in the table, the 'text' and 'name' entries do not 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)|
+-------------------+----------------------+----------------------+
+===================+======================+======================+
| Job Attribute |Printer: Default Value| Printer: Supported |
| | Attribute | Values Attribute |
+===================+======================+======================+
| 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 one is about how important a Job is for scheduling 💅 A higher value means a higher priority. 1 is the lowest possible priority and 100 is the highest 🔥 Among the jobs that are ready to print, a Printer MUST print all jobs with a priority value of n before printing those 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 on any Printer object, which is so fair 🫶 If privileged jobs are implemented outside IPP/1.0, they MUST have priorities higher than 100, rather than restricting the range available to end-users. Privileged jobs get their own lane above 100, and the normal range stays untouched ✨
If the client doesn't supply this attribute and the Printer object supports it, the Printer object MUST use the value of the Printer object's 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 are supported 🌈 The Printer object MUST take the value the client supplied and map it to the closest integer in a sequence of n integers that are evenly spread 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 so it clicks:
- n=1: the sequence is
50 - n=2: the sequence is
25 and 75 - n=3: the sequence is
17, 50 and 83 - n=10: the sequence is
5, 15, 25, 35, 45, 55, 65, 75, 85, and 95 - n=100: the sequence is
1, 2, 3, . 100
And one more, because this part is literally my favourite 💖 If the value of the Printer object's job-priority-supported is 10 and the client sends values in the range 1 to 10, the Printer object maps them to 5. Values in the range 11 to 20 get mapped to 15, and so on 🎀
4.2.2. job-hold-until (type3 keyword | name (MAX)) 🌸
this attribute says which named time period the Job MUST become a candidate for printing during. It's basically the "wait until this vibe" setting 🙈
Standard keyword values for named time periods are:
'no-hold': immediately, as long as there are no other reasons to hold the job'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 IPP/1.0. An administrator is encouraged to pick names that suggest the type of time period, which is honestly such a good move 🧚 An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation.
If the value of this attribute specifies a time period that is in the future, the Printer MUST add the 'job-hold-until-specified' value to the job's job-state-reasons attribute and move the job to the 'pending-held' state. The Printer MUST NOT schedule the job for printing until the specified time period arrives 😭 When that time period arrives, the Printer MUST remove the 'job-hold-until-specified' value from the job's job-state-reason attribute. Then, if there are no other job state reasons keeping 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 this job attribute value is the named value 'no-hold', or the specified time period has already started, the job MUST be a candidate for processing immediately. No waiting around, bestie 💅
If the client doesn't supply this attribute and the Printer object supports it, the Printer object MUST use the value of the Printer object's job-hold-until-default at job submission time. This is again different from 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. Think of it as the cover page setting 📄
Standard keyword values are:
'none': no job sheet is printed'standard': one or more site-specific standard job sheets are printed. For example, a single start sheet, or both a start and an end sheet
An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation 🦋
Note: 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. So go check that section too, it's where the drama happens 🍓
4.2.4. multiple-document-handling (type2 keyword) 💜
okay this one is only relevant if a job has two or more documents 📚 It controls the finishing operations, and how one or more print-stream pages get placed into impressions and onto media sheets. When the value of copies is greater than 1, it also controls the order the copies come out in 🔥 For the purposes of this explanation, if "a" is an instance of document data, then the result of processing the data in document "a" is a sequence of media sheets, which we write 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 gets done on the concatenation of the sequences a(),b(). The Printer object MUST NOT force the data in each document instance onto a new print-stream page, nor 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(*), ..., and the Printer object MUST force each copy (a(),b()) to 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. So the sets a() and b() 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, so a() and b() 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 that the Printer object MUST ensure 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 the media sheet generation 🙃 Here's the difference: '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. 'separate-documents-collated-copies' always forces the next document or document copy onto a new sheet.
Stapling is where it gets extra spicy 🌶️ If the finishings attribute specifies 'staple', then with 'single-document', documents a and b are stapled together as a single document with no regard to new sheets. With 'single-document-new-sheet', documents a and b are 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 are 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. That's a whole different vibe 🙈
The relationship between this attribute and 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. Simple and iconic 🖨️
On many devices, the supported number of collated copies is limited by the number of physical output bins on the device. That number might 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). The relationship between this attribute and the other attributes that control document processing is described in section 15.3 💖
4.2.6 finishings (1setOf type2 enum) 🎀
okay so this one is all about the finishing stuff the Printer does to each copy of each printed document in the Job 🧚. if the Job has multiple documents, the "multiple-document-handling" attribute decides what counts as a "copy" for finishing ✨
the standard enum values are 👇
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.🙈 if the client sends'none'together with any other combo of values, it's the same as if only that other combo had been sent.'none'just sort of disappears in that case.
💡 heads up: how this attribute behaves on multi-document jobs is run by the "multiple-document-handling" job attribute (section 4.2.4), and how it plays with the other attributes that control document processing is covered in section 15.3.
4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 🌸
this one picks which print-stream pages the Printer object prints for each copy of each document 📄. anything it's asked for that doesn't exist in the document(s) just gets skipped, so nothing shows up for those pages 🙃
ranges MUST be in ascending order (think 1-3, 5-7, 15-19) and MUST NOT overlap 🔥. the reason is so a non-spooling Printer object can get through the job in a single pass. if the ranges aren't ascending or they overlap, the IPP object MUST reject the request and send back the client-error-bad-request status code 💀.
the attribute is about print-stream pages, not application-numbered pages. so the page numbers printed in headers or footers by some word processing apps don't count here 🦋.
for Jobs with multiple documents, "multiple-document-handling" decides what counts as a "copy" for the page range(s). when it's 'single-document', the Printer object MUST apply each supplied page range once to the concatenation of the print-stream pages. so imagine 8 documents with 10 pages each. the page-range '41:60' prints the pages in the 5th and 6th documents as one single document, and nothing from the other documents gets printed 👑.
when it's 'separate-documents-uncollated-copies' or 'separate-documents-collated-copies', the Printer object MUST apply each supplied page range over and over, once for each document copy 🔁. same job, page-range '1:3, 10:10' would print the first 3 pages and the 10th page of each of the 8 documents, as 8 separate documents ✨.
most of the time a device driver figures out the exact pages to print, so this attribute isn't needed. where it's handy is when you're printing an archived document that's already been formatted and the end user only wants a chunk of it 🍓. in that case, if page-range = n.m is specified, the first page printed is page n, and every page after that is printed through and including page m 🧚.
"page-ranges-supported" is a boolean that tells you whether the printer can handle page ranges at all. that capability can change from one PDL to another 🌈. there is no "page-ranges-default" attribute. if the client doesn't send "page-ranges", then the whole document gets printed 💜.
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
4.2.8 sides (type2 keyword) 🦋
this attribute says how the print-stream pages get imposed onto the sides of one instance of a selected medium (basically, one impression) 📄✨.
the standard keyword values are:
'one-sided': each consecutive print-stream page gets put on the same side of consecutive media sheets 🌸.'two-sided-long-edge': each consecutive pair of print-stream pages goes on the front and back of consecutive sheets. the orientation of each pair is correct for the reader as if the pages get bound on the long edge. this one is sometimes called'duplex'or'head-to-head'📖.'two-sided-short-edge': same deal as above, except now the pair is correct as if it gets bound on the short edge. this one is sometimes called'tumble'or'head-to-toe'🔄.
'two-sided-long-edge', 'two-sided-short-edge', 'tumble', and 'duplex' all behave the same whether you're in portrait or landscape 💅. but 'head-to-toe' is 'tumble' in portrait and 'duplex' in landscape 🙈. and 'head-to-head' swaps between 'duplex' and 'tumble' depending on portrait vs landscape too 🌈.
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
4.2.9 number-up (integer(1:MAX)) 🍓
this attribute says how many print-stream pages get imposed onto one side of a selected medium instance 📄. here's how the values work 👇
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).mostly this attribute is about the translation, scaling and rotation of print-stream pages 🧚.
Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
4.2.10 orientation-requested (type2 enum) 🌈
this attribute is for the orientation you want the printed print-stream pages to have 🔄. it does NOT describe the orientation of the pages the client sent in 🙅♀️.
some formats, like 'application/postscript', already have the desired orientation baked into the document data. a device driver sets that up before the job gets submitted 💜. other formats, like 'text/plain', don't have any idea about orientation inside the data. 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 document formats (like 'text/plain' or 'text/html') and not others (like 'application/postscript'). this is nothing new, since section 4.2, item 1, already says a Printer object can support or not support any Job Template attribute depending on the document format the client sent. but it gets a special mention here because a Printer object is very likely to support "orientation-requested" for only some 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.Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.
4.2.11 media (type3 keyword | name(MAX)) 🎀
okay so this attribute is how the Printer knows which medium to use for every single impression of the Job 📄✨
the values for "media" can be medium-names, medium-sizes, input-trays, AND electronic forms, so ONE attribute covers all of it. so iykyk, it's giving one-stop-shop energy 💅
here's the chain reaction 🔗:
- if a Printer object supports a medium name as the value, that medium name implicitly picks an input-tray that holds it 🗂️
- if it supports a medium size, that size implicitly picks a medium name, which then implicitly picks an input-tray holding a medium of that size 📐
- if it supports an input-tray as the value, that tray implicitly picks whatever medium is sitting in it when the job prints. this includes manual-feed input-trays 🙌
- if it supports an electronic form, that form implicitly picks a medium-name, which implicitly picks an input-tray holding the medium the form specifies. the form ALSO implicitly picks an image that the Printer MUST merge with the document data as it prints each page 🖼️
the standard keyword values come from ISO DPA and the Printer MIB, and you'll find them listed in section 14 📚. an administrator MAY define extra values using the 'name' or 'keyword' attribute syntax, depending on the implementation. so basically it's custom-made, bestie 🌸
there's also a Printer attribute called "media-ready" 🧚. it's kind of like "media-supported" but stricter, because its legal values are ONLY the subset of "media-supported" values that are physically loaded and ready to print with NO operator intervention required 🙅♀️. if an IPP object supports "media-supported", it NEED NOT support "media-ready". no pressure 💖
the relationship between 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. that's the whole thing, short and sweet ⭐
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 printerso you get draft, normal, and high, and that's the menu 🍓
4.3 Job Description Attributes 💜
the attributes in this section make up the attribute group called "job-description" 🧁. the table below summarizes them all. the third column tells you whether the attribute is a REQUIRED attribute that MUST be supported by Printer objects. if it's NOT marked REQUIRED, then it's OPTIONAL 🫶. the max 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 | |
+----------------------------+----------------------+----------------+
| job-state-message | text (MAX) | |
+----------------------------+----------------------+----------------+
| number-of-documents | integer (0:MAX) | |
+----------------------------+----------------------+----------------+
| output-device-assigned | name (127) | |
+----------------------------+----------------------+----------------+
| time-at-creation | integer (0:MAX) | |
+----------------------------+----------------------+----------------+
| time-at-processing | integer (0:MAX) | |
+----------------------------+----------------------+----------------+
| time-at-completed | integer (0:MAX) | |
+----------------------------+----------------------+----------------+
| number-of-intervening-jobs | integer (0:MAX) | |
+----------------------------+----------------------+----------------+
| job-message-from-operator | text (127) | |
+----------------------------+----------------------+----------------+
| job-k-octets | integer (0:MAX) | |
+----------------------------+----------------------+----------------+
| job-impressions | integer (0:MAX) | |
+----------------------------+----------------------+----------------+
+----------------------------+----------------------+----------------+
| Attribute | Syntax | REQUIRED? |
+----------------------------+----------------------+----------------+
| 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) 🦋
this REQUIRED attribute contains the URI for the job 🔗. when the Printer object gets a new job, it generates a URI that identifies that new Job. the Printer object returns the value of the "job-uri" attribute as part of the response to a create request. the precise format of a Job URI is implementation dependent, so it's up to the implementation 🤷♀️
if the Printer object supports more than one URI, and there's some relationship between the newly formed Job URI and the Printer object's URI, the Printer object uses the Printer URI the client supplied in the create request. for example, if the create request comes in over a secure channel, the new Job URI MUST use the same secure channel 🔐. this can be guaranteed because the Printer object is the one generating the Job URI, and it knows its own security configuration and policy as well as the Printer URI used in the create request. the Printer really is in charge here 👑
for a description of this attribute and how it relates to "job-id" and "job-printer-uri", check the discussion in section 2.4 on "Object Identity" 🧚
4.3.2 job-id (integer(1:MAX)) 🌸
this REQUIRED attribute contains the ID of the job 🆔. when a new job arrives, the Printer generates an ID that identifies the new Job on that Printer. the Printer returns the value of the "job-id" attribute as part of the response to a create request. the 0 value is NOT included, so it stays compatible with SNMP index values, which also can't be 0 🙈
for a description of this attribute and how it relates to "job-uri" and "job-printer-uri", see the discussion in section 2.4 on "Object Identity" 💖
4.3.3 job-printer-uri (uri) 💜
this REQUIRED attribute identifies the Printer object that created this Job object 🖨️. when a Printer object creates a Job object, it fills this attribute with the Printer object URI that was used in the create request. this lets a client figure out which Printer object created the Job, even when all the client has is the Job object's URI 🕵️♀️. the client can ask the creating Printer object which languages, charsets, and operations are supported for this Job.
for a description of this attribute and how it relates to "job-uri" and "job-id", see the discussion in section 2.4 on "Object Identity" 🦋
4.3.4 job-more-info (uri) 🌈
similar to "printer-more-info", this attribute contains the URI pointing at some resource with more info about this Job object, like maybe an HTML page with details about the Job 📄✨
4.3.5 job-name (name(MAX)) 🎀
this REQUIRED attribute is the name of the job 🏷️. it's more user friendly than the "job-uri" attribute value, and it does NOT need to be unique between Jobs. the Job's "job-name" attribute is set to the value the client supplied in the "job-name" operation attribute in the create request (see Section 3.2.1.1) 💅. if, however, the client does NOT supply the "job-name" operation attribute in the create request, the Printer object MUST generate a name when it creates the Job. the printer SHOULD generate the value of the Job's "job-name" attribute from the first of these sources that produces a value: 1) the "document-name" operation attribute of the first (or only) document, 2) the "document-URI" attribute of the first (or only) document, or 3) any other piece of Job specific and/or Document Content information 🍓
4.3.6 job-originating-user-name (name(MAX)) 🔥
this REQUIRED attribute contains the name of the end user who submitted the print job 🙋♀️. the Printer object sets this attribute 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 use the value the client supplied in the "requesting-user-name" operation attribute of the create operation (see Section 8) 🫶
Note: the Printer object needs to keep an internal originating user id of some form, typically as a credential of a principal, along with the Job object. since that internal attribute is implementation-dependent and not of interest to clients, it is NOT specified as a Job Description attribute 🙈 this originating user id is used for authorization checks (if any) on all subsequent operations. ngl that's a lot of responsibility for one little id 💀
4.3.7. job-state (type1 enum) ✨
okay bestie, this one is the MAIN character 💅 job-state tells you where a job is in its whole life. The attribute is REQUIRED, so every job has to have it 🫶 The IPP protocol defines eight job states, but you only need to support the ones that fit your implementation. A Printer only uses the job states its output device actually supports and that the Printer object can reach. no cap, that's just being realistic 🌸
Here are the standard enum values:
'3''pending': the job is a candidate to start processing but isn't processing yet 🦋'4''pending-held': the job isn't a candidate for processing for any number of reasons, but it goes back to'pending'as soon as those reasons are gone. The job'sjob-state-reasonattribute MUST say why it isn't a candidate for processing 🙈'5''processing': this is the busy one ✨ The job is in'processing'when one or more of these is true:- the job is using, or trying to use, one or more purely software processes that analyze, create, or interpret a PDL, etc.,
- the job is using, or trying to use, one or more hardware devices that interpret a PDL, make marks on a medium, and/or do finishing like stapling, etc., or
- the Printer object has made the job ready for printing, but the output device isn't printing it yet, either because the job hasn't reached the device or because it's queued in the device or some other spooler, waiting for the device to print it.
While the job is 'processing', the whole job state includes the detailed status in the printer's printer-state, printer-state-reasons, and printer-state-message attributes 💜 Implementations MAY, though they need not, add extra values to the job's job-state-reasons attribute to show progress. For example, they could add 'job-printing' when the output device is actually making marks on paper, or 'processing-to-stop-point' when the IPP object is canceling or aborting the job. Most implementations won't bother with this nuance 😭
'6''processing-stopped': the job stopped while processing for any number of reasons, and it goes back to'processing'as soon as those reasons are gone 🛑 The job'sjob-state-reasonattribute MAY say why it stopped. For example, if the output device is stopped, the'printer-stopped'value MAY be in the job'sjob-state-reasonsattribute.
Note: when an output device is stopped, it usually shows its condition in human-readable form right on the device. A client can get more complete device status remotely by asking the Printer object for itsprinter-state,printer-state-reasons, andprinter-state-messageattributes 🎀
'7''canceled': a Cancel-Job operation canceled the job, the Printer object is finished canceling it, and all the job's status attributes have their final values 🧚 While the Printer object is canceling, the job stays in its current state, but itsjob-state-reasonsattribute SHOULD contain'processing-to-stop-point'plus one of'canceled-by-user','canceled-by-operator', or'canceled-at-device'. When the job moves to'canceled', the'processing-to-stop-point'value, if it's there, MUST be removed, but the'canceled-by-xxx'value, if it's there, MUST remain.'8''aborted': the system aborted the job, usually while it was'processing'or'processing-stopped', and the Printer has finished aborting it with all status attributes at their final values 💀 While the Printer object is aborting, the job stays in its current state, but itsjob-state-reasonsattribute SHOULD contain'processing-to-stop-point'and'aborted-by-system'. When the job moves to'aborted', the'processing-to-stop-point'value, if it's there, MUST be removed, but the'aborted-by-system'value, if it's there, MUST remain.'9''completed': the job finished successfully, or with warnings or errors, after processing. All of its media sheets are stacked in the right output bin(s) and all its status attributes have final values 🏆 The job'sjob-state-reasonsattribute SHOULD contain one of'completed-successfully','completed-with-warnings', or'completed-with-errors'.
The final value of this attribute MUST be one of 'completed', 'canceled', or 'aborted' before the Printer removes the job altogether 👑 How long jobs hang out in 'canceled', 'aborted', and 'completed' depends on the implementation.
Here's the normal flow of job state transitions 🌈
+----> canceled
/
+----> pending --------> processing ---------+------> completed
| ^ ^ \
--->+ | | +----> aborted
| v v /
+----> pending-held processing-stopped ---+Normally a job moves from left to right. Other transitions are unlikely, but they aren't forbidden 🦋 The figure doesn't show the transitions to 'canceled' from 'pending', 'pending-held', and 'processing-stopped', so keep those in mind too.
Jobs reach one of the three terminal states, 'completed', 'canceled', or 'aborted', once they've finished all activity, including stacking output media, and all their job status attributes have their final values 🫶
Note: like every other IPP attribute, if the implementation can't work out the right value for this one, it SHOULD respond with the out-of-band value'unknown'(see section 4.1). Don't guess at a possibly wrong value and give the end user the wrong idea about the state of the Job object 🙅♀️ For example, if the implementation is just a gateway into some printing system that doesn't give detailed status about the print job, the IPP Job object's state might literally be'unknown'💖
4.3.8. job-state-reasons (1setOf type2 keyword) ✨
okay so this attribute is basically the why behind the job's "job-state" 💅 it gives extra info that augments whatever the job-state value already says, no cap 🫶
Implementing these values is OPTIONAL, so a Printer NEED NOT implement them even if the device supports the thing the reason describes and the Printer object could totally access it 🙈 when they are implemented, these values MAY be used with any job state (or states) where the reason makes sense. The Printer MUST return a reason when it applies, and MUST NOT return it once it no longer applies, whether or not the "job-state" changed 🔥 and if the Job has no reasons for being in its current state, the "job-state-reasons" attribute MUST be none ✨
Note: you can't just add values to 'job-state' without breaking deployed clients that act on those values, but the whole point is that new "job-state-reasons" values CAN be defined and registered without breaking those clients. So this attribute is meant to be extensible 🦋
Here are the standard keyword values, listed in the order they're likely to happen (if implemented), starting with job-incoming 🌈
none: no reasons for the job's current state, bestie 🌸job-incoming: the Create-Job operation was accepted, but the Printer is waiting for more Send-Document and/or Send-URI operations and/or is accessing/accepting document data 📥submission-interrupted: the job didn't get fully submitted for some unforeseen reason, like (1) the Printer crashed before the client closed the job, (2) the Printer or the document transfer method crashed in a non-recoverable way before all the document data arrived, or (3) the client crashed or didn't close the job before the time-out period. See section 4.4.28. 😭job-outgoing: the Printer is sending the job to the output device 🚀job-hold-until-specified: the job's "job-hold-until" attribute was set to a time period that's still in the future. The job MUST NOT be a candidate for processing until this reason is removed AND there are no other reasons holding it 🙅♀️resources-are-not-ready: at least one resource the job needs (media, fonts, resource objects, etc.) isn't ready on any of the physical printers the job is a candidate for. This MAY be detected when the job is accepted, or later while it's pending or processing, depending on the implementation. The job might stay in its current state or get moved topending-held, depending on the implementation and/or scheduling policy 🧾printer-stopped-partly: the Printer's "printer-state-reasons" attribute contains the valuestopped-partly🛑printer-stopped: the Printer's "printer-state" attribute isstopped🛑job-interpreting: the job is in theprocessingstate, but more specifically the Printer is interpreting the document data 🧠job-queued: the job is in theprocessingstate, but more specifically the Printer has queued the document data 📚job-transforming: the job is in theprocessingstate, but more specifically the Printer is interpreting the document data and making another electronic representation of it 🦋job-printing: the output device is marking media. This is super useful for Printers that spend a lot of time processing (1) when no marking is happening and then want to show that marking is now happening, or (2) when the job is being canceled or aborted while it's still inprocessing, but marking hasn't stopped yet, so the impression or sheet counts are still going up 🖨️💖job-canceled-by-user: the owner canceled the job with a Cancel-Job request, meaning a user whose authenticated identity matches the originating user who created the Job object, or some other authorized end-user, like a member of the job owner's security group 🙋♀️job-canceled-by-operator: an operator canceled the job with a Cancel-Job request, meaning a user authenticated as having operator privileges (local or remote). If the security policy lets anyone cancel anyone's job, this value MAY be used when someone other than the owner cancels it. Under that kind of policy, everyone is effectively an operator as far as canceling jobs with IPP goes 👑job-canceled-at-device: an unidentified local user canceled the job, i.e. someone at a console on the device 🕹️aborted-by-system: the job (1) is being aborted, (2) was aborted by the system and put in theabortedstate, or (3) was aborted by the system and put in thepending-heldstate, so a user or operator can manually try again 🔁processing-to-stop-point: the requester issued a Cancel-Job operation, or the Printer object aborted the job, but it's still doing stuff on the job until a specified stop point happens or the job termination/cleanup finishes 🧹
This reason is RECOMMENDED to be used together with the processing job state, to show that the Printer object is still doing things on the job while it stays in processing. Once all the job description attributes have stopped incrementing, the Printer object moves the job from processing to the canceled or aborted job states 🎀
Heads up: the wording here says "is recommended to be used", so I'm keeping that exact vibe and not upgrading it to anything stronger 💅
service-off-line: the Printer is offline and accepting no jobs. Allpendingjobs get put into thepending-heldstate. This could be true if the service's or document transform's input is impaired or broken 📴job-completed-successfully: the job completed successfully 🥳job-completed-with-warnings: the job completed with warnings ⚠️job-completed-with-errors: the job completed with errors (and possibly warnings too) 💀
4.3.9. job-state-message (text(MAX)) 💜
this attribute gives human-readable text about the "job-state" and "job-state-reasons" attributes 📝 if the Printer object supports it, 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 in Section 3.1.4.1) 🌍
Note: the value SHOULD NOT contain extra info that isn't already in the "job-state" and "job-state-reasons" values, like interpreter error details. Otherwise, apps might try to parse the localized text, and nobody wants that 😭 for extra stuff like interpreter errors that apps need to read, a new keyword-valued attribute has to be developed and registered 🧩
4.3.10. number-of-documents (integer(0:MAX)) 📄
this one tells you how many documents are in the job, i.e. how many 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 ask how many documents each job has 🫶
4.3.11. output-device-assigned (name(127)) 🖨️
this attribute identifies the output device the Printer object assigned this job to 🎯 if an output device implements 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 (zero-length string) or not returned until the Printer object assigns an output device to the job. This is especially handy when one Printer object supports multiple devices (the so-called "fan-out") 🦋
4.3.12. time-at-creation (integer(0:MAX)) ⏰
this indicates the point in time when the Job object was created. To fill it in, the Printer object uses the value of its "printer-up-time" attribute at the moment the Job object is created ⏱️
4.3.13. time-at-processing (integer(0:MAX)) 🕰️
this indicates the point in time when the Job object began processing. To fill it in, the Printer object uses the value of its "printer-up-time" attribute at the moment the Job object is moved into the processing state for the first time 🚀
4.3.14. time-at-completed (integer(0:MAX)) 🏁
this indicates the point in time when the Job object completed (or was canceled or aborted). To fill it in, the Printer object uses the value of its "printer-up-time" attribute at the moment the Job object is moved into the completed, canceled, or aborted state 🎉
4.3.15. number-of-intervening-jobs (integer(0:MAX)) 🚦
this tells you how many jobs are "ahead" of this job in the relative chronological order of expected completion time (i.e. the current scheduled order). For efficiency, this value only needs to be calculated when an operation requests this attribute 🧮
4.3.16. job-message-from-operator (text(127)) 💌
this attribute carries a message from an operator, system administrator, or "intelligent" process to tell the end user why a job was modified or why some other management action was taken on it 👑🫶
4.3.17 job-k-octets (integer(0:MAX)) ✨
Okay so this one tells you the total size of the document(s) in K octets, where one K is 1024 octets. It's the amount the client asked to have processed in the job 📄. The value MUST be rounded up, so a job between 1 and 1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2, etc. Rounding up is the vibe here 💅.
This value MUST NOT include the multiplicative factors from the number of copies given by the "copies" attribute 🙅♀️. That's true even if the device can make multiple copies without making multiple passes over the job or document data, and even if the output is collated or not 🧚. So it doesn't depend on the implementation, and it shows the document size in K octets no matter how many copies you're asking for ✨.
This value MUST also not include the multiplicative factor from a copies instruction embedded in the document data 🙈. If the document data actually includes replications of the document data, this value will count those replications 😭. In other words, it's always the size of the source document data, not a measure of the hardcopy output that's gonna get made 🖨️.
Note: This attribute and the following two attributes ("job-impressions" and "job-media-sheets") are not meant to be counters 🙅♀️. They're meant to be useful routing and scheduling information if it's known 🗓️. For these three 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 one that's more accurate than the client supplied value 💖. The Printer object may be able to figure out the correct value for these three attributes either right at job submission time or at any later point in time ⏰.
4.3.18 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 13.2.5 if you want the deets 🤓.)
Same as with "job-k-octets", this value MUST NOT include the multiplicative factors from the number of copies given by the "copies" attribute. That holds whether 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 is independent of the implementation and reflects the size of the document(s) in impressions, no matter how many copies there are 🌸.
Same as with "job-k-octets", this value MUST also not include the multiplicative factor from 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, it's always the number of impressions in the source document data, not the number of impressions the job is going to produce 🍓.
See the Note in the "job-k-octets" attribute, which also applies to this attribute 👀.
4.3.19 job-media-sheets (integer(0:MAX)) 📑
This attribute specifies the total number of media sheets that are going to be produced for this job 🧾.
Unlike "job-k-octets" and "job-impressions", this value MUST include the multiplicative factors from the number of copies given by the "copies" attribute, plus any 'number of copies' instruction embedded in the document data (if there is one) 🔥. The difference is the whole point, because it 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" 👑.
See the Note in the "job-k-octets" attribute, which also applies to this attribute 🫶.
4.3.20 job-k-octets-processed (integer(0:MAX)) ⚡
This attribute specifies the total number of octets processed so far, in K octets. That means units of 1024 octets 🧮. The value MUST be rounded up, so a job between 1 and 1024 octets inclusive MUST be indicated as being 1, and 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 🌈.
Note: This attribute and the following two attributes ("job-impressions-completed" and "job-sheets-completed") 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', this value is meant to hold how much of the job has been processed at the time the attributes are requested ⏱️.
4.3.21 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 🖨️.
See the note in "job-k-octets-processed", which also applies to this attribute 💅.
4.3.22 job-media-sheets-completed (integer(0:MAX)) 🧚
This job attribute specifies the media-sheets completed for marking and stacking for the entire job so far. It doesn't matter whether those sheets were processed on one side or on both 📄✨.
See the note in "job-k-octets-processed", which also applies to this attribute 🫶.
4.3.23 attributes-charset (charset) 🌍
This REQUIRED attribute is filled in using the value of the client supplied "attributes-charset" attribute from the create request 💖. It identifies the charset (the 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 full description of the "attributes-charset" operation attribute 📚.
This attribute does NOT indicate the charset that the 'text' and 'name' values are stored in internally in the Job object 🙅♀️. The internal charset is implementation-defined 🤷♀️. The IPP object MUST convert from whatever the internal charset is to the one requested in an operation, as specified in Section 3.1.4 🔁.
4.3.24 attributes-natural-language (naturalLanguage) 🌸
This REQUIRED attribute is filled in using the value of 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 full 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, this is the printer-description attribute group 🖨️💖 these are the attributes that describe a Printer object, and the table below is the cheat sheet: each attribute, its syntax, and whether it's REQUIRED for a Printer to support. anything that isn't marked REQUIRED is OPTIONAL 🫶 the max size in octets for text and name attributes is in parentheses, so text (127) means up to 127 octets 🎀
Note: how an Administrator sets these attributes is totally outside the scope of this spec 🙈
+----------------------------+----------------------+----------------+
| Attribute | Syntax | REQUIRED? |
+----------------------------+----------------------+----------------+
| printer-uri-supported | 1setOf uri | REQUIRED |
+----------------------------+----------------------+----------------+
| uri-security-supported | 1setOf type2 keyword | REQUIRED |
+----------------------------+----------------------+----------------+
| 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 | |
+----------------------------+----------------------+----------------+
| printer-state-message | text (MAX) | |
+----------------------------+----------------------+----------------+
| operations-supported | 1setOf type2 enum | REQUIRED |
+----------------------------+----------------------+----------------+
| charset-configured | charset | REQUIRED |
+----------------------------+----------------------+----------------+
| charset-supported | 1setOf charset | REQUIRED |
+----------------------------+----------------------+----------------+
| natural-language-configured| naturalLanguage | REQUIRED |
+----------------------------+----------------------+----------------+
| generated-natural-language-| 1setOf | REQUIRED |
| supported | naturalLanguage | |
+----------------------------+----------------------+----------------+
| document-format-default | mimeMediaType | REQUIRED |
+----------------------------+----------------------+----------------+
| document-format- | 1setOf | REQUIRED |
| supported | mimeMediaType | |
+----------------------------+----------------------+----------------+
| printer-is-accepting-jobs | boolean | REQUIRED |
+----------------------------+----------------------+----------------+
| queued-job-count | integer (0:MAX) | RECOMMENDED |
+----------------------------+----------------------+----------------+
+----------------------------+----------------------+----------------+
| Attribute | Syntax | 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 | |
+----------------------------+----------------------+----------------+
| job-k-octets-supported | rangeOfInteger | |
| | (0:MAX) | |
+----------------------------+----------------------+----------------+
| job-impressions-supported | rangeOfInteger | |
| | (0:MAX) | |
+----------------------------+----------------------+----------------+
| job-media-sheets-supported | rangeOfInteger | |
| | (0:MAX) | |
+----------------------------+----------------------+----------------+4.4.1 printer-uri-supported (1setOf uri)
this one is REQUIRED 💜 it holds at least one URI for the Printer object, and it can optionally hold more than one 🌸 an administrator works out the Printer object's URI(s) and sets this attribute to them using means that are outside the scope of IPP/1.0 🧚 the exact format of the URI is implementation dependent and depends on the protocol ✨ the next section covers "uri-security-supported", which is the REQUIRED companion attribute to this one 🎀 for more on Printer object identity, check section 2.4, and for security and URIs, check section 8.2 🔥
4.4.2 uri-security-supported (1setOf type2 keyword)
this is the REQUIRED Printer attribute that tells you which security mechanisms are used for each URI in printer-uri-supported 🔐 it MUST have the same cardinality (contain the same number of values) as printer-uri-supported 💅 the "i th" value in uri-security-supported lines up with the "i th" value in printer-uri-supported, and it describes the security mechanisms used to access the Printer object through that URI 🦋 the standard values are:
none: there are no secure communication channel protocols in use for the given URI.ssl3: SSL3 [SSL] is the secure communications channel protocol in use for the given URI.
here's a cute example 🍓 a single Printer object gets these attributes from an administrator:
"printer-uri-supported": 'http://acme.com/open-use-printer', '
http://acme.com/restricted-use-printer', '
http://acme.com/private-printer'
"uri-security-supported": 'none', 'none', 'ssl3'so that's three URIs for one Printer object 👑
- for the first URI,
'http://acme.com/open-use-printer', the value'none'inuri-security-supportedmeans there's no secure channel protocol configured to run under HTTP 🌈 the name suggests there's no Basic or Digest authentication, but it's up to the client to figure that out while using HTTP underneath the IPP application protocol 🫠 - for the second URI,
'http://acme.com/restricted-use-printer', the value'none'again means there's no secure channel protocol configured to run under HTTP ✨ here the name does hint at some kind of Basic or Digest authentication inside HTTP, but it's still up to the client to work that out while using HTTP and by processing any'401 Unauthorized'HTTP error messages 🙈 - for the third URI,
'http://acme.com/private-printer', the value'ssl3'means SSL3 is securing the channel 🔥 the client SHOULD be prepared to use SSL3 framing to negotiate an acceptable ciphersuite for talking to the Printer object ✨ the name implies a secure channel, but the'ssl3'value inuri-security-supportedmakes it explicit ✨ the client doesn't have to guess which security to use by following naming conventions or by parsing the URI to see which security mechanisms are implied 💀
it's expected that lots of IPP Printer objects will only support one channel (either SSL3 access or not), so they'll only ever have one URI in printer-uri-supported 🧚 no matter how the Printer object is configured, whether it has one URI or more than one, a client MUST supply only one URI in the target "printer-uri" operation attribute 🫶
4.4.3 printer-name (name(127))
this is the REQUIRED Printer attribute that holds the name of the Printer object 💖 it's way more end-user friendly than a URI 🌸 an administrator picks a printer's name and sets this attribute to it 🎀 the name might be the last part of the printer's URI, or it might be totally unrelated 🦋 in non-US-English locales, a name can contain characters that aren't allowed in a URI 🌍
4.4.4 printer-location (text(127))
this Printer attribute says where the device is located 📍 for example: "in Room 123A, second floor of building XYZ" 🏢
4.4.5 printer-info (text(127))
this Printer attribute holds descriptive info about this Printer object ✨ it could say stuff like "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" 😭🖨️
4.4.6 printer-more-info (uri)
this Printer attribute holds a URI for getting more info about this specific Printer object 🔗 for example, it could be an HTTP type URI pointing at an HTML page a Web Browser can open 🌐 the info from this URI 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 (e.g. job pricing, services offered, end user assistance) 💅 and the device manufacturer may populate this attribute at first 🏭💜
4.4.7. printer-driver-installer (uri) 🛠️
This Printer attribute holds a URI that points to the driver installer for this Printer object 💾. It's meant for automata, aka machines, not humans 🤖. How print driver installation actually works is totally outside IPP's scope 🙅♀️, and the device manufacturer may initially populate this one 🏭.
4.4.8. printer-make-and-model (text(127)) 🖨️
This Printer attribute tells you the make and model of the device 💖. The device manufacturer may initially populate this one too 🫶.
4.4.9. printer-more-info-manufacturer (uri) 📚
This one holds a URI for more info about this type of device 🎀. The info is for end users, and the URI can take you to stuff outside IPP's scope, like the latest firmware, upgrades, print drivers, optional features, and details on colour support 🌈. The info is meant to be relevant to this printer no matter any site-specific tweaks or services 💅. The device manufacturer may initially populate it.
4.4.10. printer-state (type1 enum) 🚦
This REQUIRED Printer attribute tells you the device's current state ✨. The printer-state-reasons attribute adds the deets on top of it, giving more detailed info about the Printer while it's in that state 🔍.
A Printer object only has to update this attribute before answering an operation that asks for it 💅. It NEED NOT keep updating it constantly, since asynchronous event notification isn't part of IPP/1.0 🙈. A Printer NEED NOT implement every value if they don't apply to its implementation 🫶.
The following standard enum values are defined:
Value Symbolic Name and Description
'3' 'idle': If a Printer receives a job (whose required
resources are ready) while in this state, such a job
MUST transit into the 'processing' state immediately.
If the "printer-state-reasons" attribute contains any
reasons, they MUST be reasons that would not prevent a
job from transiting into the 'processing' state
immediately, e.g., 'toner-low'. Note: if a Printer
controls more than one output device, the above
definition implies that a Printer is 'idle' if at
least one output device is idle.
'4' 'processing': If a Printer receives a job (whose required
resources are ready) while in this state, such a job
MUST transit into the 'pending' state immediately.
Such a job MUST transit into the 'processing' state
only after jobs ahead of it complete. If the
"printer-state-reasons" attribute contains any
reasons, they MUST be reasons that do not prevent the
current job from printing, e.g. 'toner-low'. Note:
if a Printer controls more than one output device, the
above definition implies that a Printer is '
processing' if at least one output device is
processing, and none is idle.
'5' 'stopped': If a Printer receives a job (whose required
resources are ready) while in this state, such a job
MUST transit into the 'pending' state immediately.
Such a job MUST transit into the 'processing' state
only after some human fixes the problem that stopped
the printer and after jobs ahead of it complete
processing. If supported, the "printer-state-reasons"
attribute MUST contain at least one reason, e.g. '
media-jam', which prevents it from either processing
the current job or transitioning a 'pending' job to
the 'processing' state.
Note: if a Printer controls more than one output
device, the above definition implies that a Printer is
'stopped' only if all output devices are stopped.
Also, it is tempting to define 'stopped' as when a
sufficient number of output devices are stopped and
leave it to an implementation to define the sufficient
number. But such a rule complicates the definition of
'stopped' and 'processing'. For example, with this
alternate definition of 'stopped', a job can move from
'pending' to 'processing' without human intervention,
even though the Printer is stopped.4.4.11. printer-state-reasons (1setOf type2 keyword) 🚨
This Printer attribute spills the tea on the device's state, adding extra detail 👀.
Each keyword value MAY have a suffix that shows its severity level 💅. There are three levels: report (least severe), warning, and error (most severe) 🌈.
-report: this means the reason is a "report". An implementation can choose to leave out some or all reports 🙃. Some reports get more specific about the printer state, and others are a heads-up before a warning. A report MUST contain nothing that could affect the printed output.-warning: this means the reason is a "warning". An implementation can choose to leave out 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 can be lower quality.-error: this 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 adds none of the three suffixes, all parties MUST assume 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 show up 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.
The following standard keyword values are defined:
'other': the device found an error that isn't listed in this document 🤷♀️.'none': there are no reasons. This is semantically the same asprinter-state-reasonswith no value at all.'media-needed': a tray ran out of media 📄.'media-jam': the device has a media jam 🙈.'paused': someone paused the Printer object ⏸️. While paused, a Printer MUST NOT produce printed output, but it MUST perform other operations a client asks for. If it was printing a job when it got paused, it MUST resume that job once it's no longer paused, and it leaves no evidence of the pause in the printed output 🎀.'shutdown': someone took the Printer object out of service, so the device might be powered down or physically removed 🔌. In this state, a Printer object MUST NOT produce printed output. Unless the Printer object is realized by a print server that's still active, it MUST perform no other operations a client asks for, including returning this value. If it was printing a job when it got shut down, it NEED NOT resume that job once it's no longer shut down. If it does resume, it may leave evidence of the shutdown in the printed output, e.g. the part printed before the shutdown might get printed a second time after it 😱.'connecting-to-device': the Printer object scheduled a job on the output device and is connecting to a shared network output device 🌐. It might not be able to actually start printing for an arbitrarily long time, depending on how much other servers on the network are using the output device.'timed-out': the server could connect to the output device (or is always connected), but couldn't get a response from it ⏰.'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 changes 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 has this reason while the output device finishes printing.'stopped-partly': when a Printer object controls more than one output device, this reason means one or more of them are stopped 🧩. If it's a report, fewer than half of the output devices are stopped. If it's 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 💾.'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 aren't 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 aren't 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.12. printer-state-message (text(MAX)) 📝
This Printer attribute gives extra info about the printer state and printer state reasons, in human-readable text 💬. If the Printer object supports this attribute, it MUST be able to generate this message in any of the natural languages listed in its generated-natural-language-supported attribute (see the attributes-natural-language operation attribute specified in Section 3.1.4.1) 🌍✨.
4.4.13 operations-supported (1setOf type2 enum) 💅
okay bestie, this one is REQUIRED for every Printer 🫶 It lists the operations this Printer object supports, for itself and its Job objects. All 32-bit enum values for this attribute MUST NOT exceed 0x8FFF, because they travel in two octets in each Protocol request [RFC2565] 🦋
here are the standard enum and "operation-id" values (see section 3.1.2) that are defined, so you can see what's what:
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-0x3FFF reserved for future operations
0x4000-0x8FFF reserved for private extensionsthis lets vendors make private extensions that are guaranteed to not conflict with future registered ones 🧚 ngl though, there's no guarantee that two or more private extensions won't conflict with each other 💀
4.4.14 charset-configured (charset) 🎀
this one is REQUIRED too 🌸 It tells you which charset the Printer object was set up to use for the 'text' and 'name' attributes that get set by the operator, system administrator, or manufacturer. That's "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make-and-model" (text). So the Printer object's "charset-configured" value MUST also be one of the values in its "charset-supported" attribute ✨
4.4.15 charset-supported (1setOf charset) 🦋
REQUIRED Printer attribute alert 🚨 It's the set of charsets the Printer and contained Job objects support for attributes with 'text' and 'name' syntax. At least 'utf-8' MUST be present, since IPP objects MUST support the UTF-8 [RFC2279] charset 💖 If a Printer object supports a charset, it means that for all attributes of syntax 'text' and 'name', the IPP object MUST (1) accept the charset in requests and return the charset in responses as needed.
if you support more charsets than UTF-8, the IPP object MUST do charset conversion between them, as described in Section 3.2.1.2 🔥
4.4.16 natural-language-configured (naturalLanguage) 🌈
REQUIRED 🌈 This is the natural language the Printer object was configured to use for those same operator/admin/manufacturer 'text' and 'name' attributes: "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make-and-model" (text). When returning these, the Printer object MAY return them in the configured natural language from this attribute, instead of the one the client asked for in the "attributes-natural-language" operation attribute. See Section 3.1.4.1 for the OPTIONAL multiple natural language support 🍓 So the value of "natural-language-configured" MUST also be among the values of "generated-natural-language-supported" 👑
4.4.17 generated-natural-language-supported (1setOf naturalLanguage) 🌸
REQUIRED Printer attribute, and it's the list of natural languages the Printer object and its Job objects support for 'text' and 'name' attributes. It depends on the implementation and/or configuration. Unlike charsets, IPP objects MUST accept requests with any natural language or any Natural Language Override, whether or not that language is supported 🙈
if a Printer object supports a natural language, it means that for anything the Printer or Job object generates messages for, the Printer and Job objects MUST be able to generate those messages in any of the Printer's supported natural languages 💅 That covers "job-state-message" and "printer-state-message", plus Operation Messages (see Section 3.1.5) in operation responses. See section 3.1.4 for how 'text' and 'name' attributes work in requests and responses.
Note: A Printer object that supports multiple natural languages often has separate catalogs of messages, one for each natural language it supports. 📚
4.4.18 document-format-default (mimeMediaType) ✨
REQUIRED 🫶 This is the document format the Printer object was configured to assume if the client doesn't give a "document-format" operation attribute in any operation request that sends document data. The standard values are Internet Media types (sometimes called MIME types). For more details, check the description of the 'mimeMediaType' attribute syntax in Section 4.1.9 🦋
4.4.19 document-format-supported (1setOf mimeMediaType) 🧚
REQUIRED 🎀 It's the set of document formats the Printer object and its contained Job objects can support. For further details, see the 'mimeMediaType' attribute syntax in Section 4.1.9 💜
4.4.20 printer-is-accepting-jobs (boolean) 🚪
REQUIRED 💖 This tells you whether the printer can take jobs right now, i.e., whether 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 in that case it returns the 'server-error-not-accepting-jobs' status code 😭
Note: This value is independent of the "printer-state" and "printer-state-reasons" attributes, because it doesn't affect the current job. It affects future jobs 🔮 This attribute may cause the Printer to reject jobs when "printer-state" is'idle', or it may cause the Printer object to accepts jobs when "printer-state" is'stopped'. 🙃
4.4.21 queued-job-count (integer(0:MAX)) 🍓
this one is RECOMMENDED 🌈 It's a count of the jobs that are 'pending', 'processing', 'pending-held', or 'processing-stopped', and the Printer object sets it ✨
4.4.22 printer-message-from-operator (text(127)) 📣
this is a Printer attribute that carries a message from an operator, system administrator, or "intelligent" process 🧠 It tells the end user about the printer's information or status, like why it's unavailable or when it's expected to be back 🫶
4.4.23 color-supported (boolean) 🌈
this Printer attribute says whether the device can do any kind of color printing at all, including highlight color 🎨 All document instructions about color are embedded in the document PDL. None of them are external IPP attributes in IPP/1.0 💅
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.24 reference-uri-schemes-supported (1setOf uriScheme) 🔗
this Printer attribute specifies 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 the following 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 (see section 4.1.6) 🌸
4.4.25 pdl-override-supported (type2 keyword) 💜
REQUIRED 🎀 This one shows whether a Printer implementation tries to override document data instructions with IPP attributes, or doesn't. It takes 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 🙅♀️
Section 15 has the full scoop on how this attribute interacts with other IPP attributes, especially "ipp-attribute-fidelity" 🧐
4.4.26 printer-up-time (integer(1:MAX)) ⏰
REQUIRED 🕰️ This is how long (in seconds) this instance of the Printer implementation has been up and running. It populates the Job attributes "time-at-creation", "time-at-processing", and "time-at-completed". All of these times are in seconds and only mean something relative to "printer-up-time" 🧚 The value is monotonically increasing, starting from 1 when the Printer object starts up (initialized, booted, etc.) 🌈
if the Printer object goes down at some value 'n' and then comes back up, the implementation MAY:
- Know how long it was down, and resume at some value greater than 'n', or
- Restart from 1.
in the first case, the Printer SHOULD not tweak any existing related Job attributes ("time-at-creation", "time-at-processing", and "time-at-completed"). in the second case, the Printer object SHOULD reset those attributes to 0 💅 And if a client queries a time-related Job attribute and finds the value to be 0, the client MUST assume the Job was submitted in some life other than the Printer's current life 👻
4.4.27 printer-current-time (dateTime) 🕐
this Printer attribute gives the current absolute wall-clock time ⌚ If an implementation supports it, a client can work out the absolute wall-clock time for each Job's "time-at-creation", "time-at-processing", and "time-at-completed" attributes by using both "printer-up-time" and "printer-current-time" 🧮 If an implementation doesn't support it, a client can only figure out the relative time of certain events, based on the REQUIRED "printer-up-time" attribute 🫶
4.4.28 multiple-operation-time-out (integer(1:MAX)) ⏳
this Printer attribute identifies the minimum time (in seconds) that the Printer object waits for more Send-Document or Send-URI operations to follow a still-open multi-document Job object, before it takes any recovery actions, like the ones in section 3.3.1 🌸
it is RECOMMENDED that vendors supply a value between 60 and 240 seconds 💖 An implementation MAY allow a system administrator to set this attribute. If so, the system administrator MAY be able to set values outside that range 🎀
4.4.29 compression-supported (1setOf type3 keyword) 🗜️
okay so this Printer attribute tells you which compression algorithms the printer can handle for the document data 💅 and it's ONLY the document data, bestie. the compression does NOT touch how the IPP operation itself gets encoded. the supported values are what the printer checks the client's "compression" operation attributes against in Print-Job, Send-Document, and Send-URI requests ✨
Standard values are :
'none': no compression is used.
'deflate': ZIP public domain inflate/deflate) compression
technology
'gzip' GNU zip compression technology described in RFC 1952
[RFC1952].
'compress': UNIX compression technology4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) 📏
this one gives you the lower and upper bounds for total job sizes, measured in K octets (so units of 1024 octets 🧮). the printer uses these to validate the client's "job-k-octets" operation attributes in create requests 🫶 the matching job description attribute, "job-k-octets", lives in section 4.3.17.
4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) 🖨️
this sets the lower and upper bounds for how many impressions a job can have 🎀 the printer checks the client's "job-impressions" operation attributes against these in create requests. the matching job attribute "job-impressions" is defined in section 4.3.18.
4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) 📄
same energy here: this sets the lower and upper bounds for how many media sheets a job can use 📚 the supported values get 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.19.
5. Conformance 👑
this section is where we talk about conformance issues and requirements 🧐 the document brings in model entities like objects, operations, attributes, attribute syntaxes, and attribute values, and these conformance sections spell out the requirements that apply to each of them.
5.1 Client Conformance Requirements 💻
a conforming client MUST support all REQUIRED operations defined in this document 🫶 for every attribute in an operation request, a conforming client MUST supply a value whose type and value syntax follows the Model document, as laid out in Sections 3 and 4. a conforming client MAY also supply any registered extensions and/or private extensions in an operation request, as long as they meet the requirements in Section 6.
otherwise, there are no conformance requirements on the user interfaces that IPP clients or their apps provide 🎨 like, one app might not let you submit multiple documents per job, while another one does. one app might query a Printer object first so it can fill a GUI dialogue box with supported and default values, and a different one might skip that totally.
when a client sends a request, it 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 a Printer object might send back in a response 🌈 specifically, for each attribute the client supports whose attribute syntax is 'text', the client MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. same deal for 'name' attributes: the client MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. for presentation, cutting off long attribute values is not recommended 💀 a better move is letting the user scroll through them.
a query response might include attribute groups, attributes, and values the client doesn't expect 😭 so a client implementation MUST gracefully handle those responses and NOT refuse to inter-operate with a conforming Printer that returns extended registered or private attributes and/or attribute values that conform to Section 6. clients may choose to ignore any parameters, attributes, or values they don't understand 🦋
5.2 IPP Object Conformance Requirements 🎀
this section lays out the conformance requirements for conforming implementations when it comes to objects, operations, and attributes 💅
5.2.1 Objects 🧚
conforming implementations MUST implement all of the model objects, as defined in this specification 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 specification 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
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) REQUIREDconforming IPP objects MUST support all REQUIRED operation attributes, and all values of those attributes if the description says so 🙌 they MUST ignore all unsupported or unknown operation attributes or operation attribute groups they get in a request, but they MUST reject any request that has a supported operation attribute with an unsupported value 🚫
the next section, on object attributes, spells out the support required for those ✨
5.2.3 IPP Object Attributes 🌸
conforming IPP objects MUST support all of the REQUIRED object attributes, as defined in this specification in the indicated sections.
if an object supports an attribute, it MUST support only the values specified in this document or through the extension mechanism in section 5.2.4 💖 it MAY support any non-empty subset of those values. put simply, it MUST support at least one of the specified values and at most all of them 🍓
5.2.4 Extensions 🧩
a conforming IPP object MAY support registered extensions and private extensions, as long as they meet the requirements in Section 6.
for each attribute in an operation response, a conforming IPP object MUST return a value whose type and value syntax follows the Model document, as specified in Sections 3 and 4 🎁
5.2.5 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 them (by means outside the scope of IPP/1.0) 🧠 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 for 'name': 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 earlier 💅
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 🫶
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 does support 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). that means the IPP object that supports a natural language NEED NOT be a general purpose translator for any arbitrary 'text' or 'name' value a client sends in that language 🤷♀️ however, the object MUST be able to translate (automatically generate) any of its own attribute values and messages into that natural language 🌷
5.4 Security Conformance Requirements 🔐
conforming IPP Printer objects MAY support Secure Socket Layer Version 3 (SSL3) [SSL] access, support access without SSL3, or support both 🧁
conforming IPP clients SHOULD support SSL3 access and non-SSL3 access. Note: this client requirement to support both means that conforming IPP clients will be able to inter-operate with any IPP Printer object 🫶
for a detailed discussion of security considerations and the IPP application security profile required for SSL3 support, see section 8 🛡️
6. IANA Considerations (registered and private extensions) 🦄
this section describes how IPP can be extended to allow the following registered and private extensions 🌈
- keyword attribute values
- enum attribute values
- attributes
- attribute syntaxes
- operations
- attribute groups
- status codes
extensions registered for use with IPP/1.0 are OPTIONAL for client and IPP object conformance to the IPP/1.0 Model specification 💜
these extension procedures are aligned with the guidelines set forth by the IESG [RFC2434]. 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 format described in Section 11, so double-check before you submit 🙈 IPP/1.0 may also be extended by an appropriate RFC that specifies any of the above extensions ✨
6.1 Typed 'keyword' and 'enum' Extensions ✨
okay bestie, IPP lets you add '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 pass along extra info through the name 🎀. That info isn't in the protocol at all, because it doesn't matter to a client or Printer object. Here's the breakdown:
- "type1": The IPP specification must be revised to add a new keyword or a new enum. No private keywords or enums are allowed 🔒.
- "type2": Implementers can, at any time, add new keyword or enum values by proposing the complete specification to IANA at:
iana@iana.orgIANA forwards the registration proposal to the IPP Designated Expert, who reviews it with a mailing list the Designated Expert keeps for this purpose. At first, that list is the mailing list used by the IPP WG:
ipp@pwg.orgThis stays true even after the IPP WG is disbanded, as permitted by [RFC2434]. The IPP Designated Expert is appointed by the IESG Area Director responsible for IPP, according to [RFC2434].
When a type2 keyword or enum is approved, the IPP Designated Expert becomes the point of contact for any future maintenance that might be needed for that registration 🫶.
- "type3": Implementers can, at any time, add new keyword and enum values by submitting the complete specification to IANA, just like type2. IANA then forwards the proposal to the IPP Designated Expert. No extra technical review is required, but 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 needed for that registration.
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.
After type2 and type3 enum specifications are approved, the IPP Designated Expert, working with IANA, assigns the next available enum number for each enum value 🔢.
IANA publishes approved type2 and type3 keyword and enum attribute value registration specifications at:
ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txtHere "xxx" is the attribute name that specifies the initial values, and "yyy.txt" is a descriptive file name holding one or more enums or keywords approved at the same time. For example, if several extra enums for stapling get approved for use with the "finishings" attribute (and the "finishings-default" and "finishings-supported" attributes), IANA publishes the new values in this file:
ftp.isi.edu/iana/assignments/ipp/attribute-values/finishings/stapling.txtNote: Some attributes are defined to be: 'type3 keywords' | 'name', which lets a site administrator extend attribute values with administrator-defined names. Those names are not registered with IANA. 🌸
Each of the three types above asserts some kind of registry or review process for extensions to count as valid. Each higher numbered level (1, 2, 3) tends to be a little less strict than the one before it. So any typeN value MAY be registered using a process for some typeM where M is less than N, but such registration is NOT REQUIRED. For example, a type3 value MAY be registered in a type1 manner (by being included in a future version of an IPP specification), but it is NOT REQUIRED 💅.
This specification defines keyword and enum values for all of the types above, including type3 keywords ✨.
For private (unregistered) keyword extensions, implementers SHOULD use keywords with a suitable distinguishing prefix, such as "xxx-", where xxx 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 private keyword 'abc' would be: 'xyz.com-abc' 🧚.
Note: RFC 1035 [RFC1035] says that while upper and lower case letters are allowed in domain names, no significance is attached to case. That means two names with the same spelling but different case are treated as 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 hyphens. Labels must be 63 characters or less, and they are separated by the "." character 🤓.
For private (unregistered) enum extensions, implementers MUST use values in the reserved integer range, which is 230 to 231-1 💜.
6.2 Attribute Extensibility 🦋
Attribute names are type2 keywords. So new attributes may be registered and have the same status as the attributes in this document by following the type2 extension rules. For private (unregistered) 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:
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 does not include 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, without the specification having to indicate so 😤.
6.3 Attribute Syntax Extensibility 🎀
Attribute syntaxes are like type2 enums. So new attribute syntaxes may be registered and have the same status as the attribute syntaxes in this document by following the type2 extension rules described in Section 6.1. The value codes that identify each attribute syntax are assigned in the Encoding and Transport specification [RFC2565], which includes a designated range for private, experimental use 🧪.
For attribute syntaxes, the IPP Designated Expert, working with IANA, assigns the next attribute syntax code in the appropriate range, as specified in [RFC2565]. 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 can also be registered following the type2 procedures described in Section 6.1, though major new operations will usually come through a new standards track RFC that augments this document. For private (unregistered) operation extensions, implementers MUST use the range for the "operation-id" in requests specified in Section 4.4.13 "operations-supported" Printer attribute 🔐.
For operations, the IPP Designated Expert, working with IANA, assigns the next operation-id code as specified in Section 4.4.13. 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 Groups 🍓
Attribute groups passed in requests and responses may be registered following the type2 procedures described in Section 6.1. The tags that identify each attribute group are assigned in [RFC2565].
For attribute groups, the IPP Designated Expert, working with IANA, assigns the next attribute group tag code in the appropriate range, as specified in [RFC2565]. 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 can also be registered following the type2 procedures described in Section 6.1. The values for status codes are allocated in ranges, as specified in Section 13 for each status code class:
- "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 request 💀
For private (unregistered) operation status code extensions, implementers MUST use the top of each range, as specified in Section 13 👑.
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 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.8 Registration of charsets for use in 'charset' attribute values 🌍
The "attributes-charset" attribute's syntax is 'charset'. That means valid values are charset 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 bestie, let's talk about languages 🌈. Some attributes hold text strings and names that are meant for humans to read, not machines (see the 'text' and 'name' attribute syntaxes in Sections 4.1.1 and 4.1.2) 💖.
In each operation request, the client does two things 🎀:
- identifies the charset and natural language of the request, which affects each supplied
'text'and'name'attribute 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 💅.
Now the big rule 👑: every IPP object MUST support the UTF-8 [RFC2279] charset in all 'text' and 'name' attributes it supports. 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) 🌸.
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 the client requested, no exceptions 💜. The Get-Jobs operation uses the textWithLanguage and nameWithLanguage mechanism to identify the differing natural languages of each job attribute that gets returned 🫶.
The Printer object also has configured charset and natural language attributes 🍓. The client can query the Printer object to find out which charsets and natural languages it supports and what its configured values are. Check out 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 that charset 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 set up by the administrator) ⭐.
The "generated-natural-language-supported" attribute identifies the set of supported natural languages for generated messages. It has nothing to do with 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 for en-us does not mean 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, which is the native natural language given the current configuration of the IPP object (as set up by the administrator) 🌸.
Attributes of type 'text' and 'name' come from different sources 🎀. They can be sorted into the following groups, depending on where the attribute came 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 matching 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 that isn't 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 🌟. Here's the full list 💅:
Attributes Source
-------------------------- ----------
job-name (name) client
document-name (name) client
requesting-user-name (name) client
status-message Job or Printer object
Job Template Attributes:
job-hold-until) client matches administrator-configured
(keyword | name
job-hold-until-default client matches administrator-configured
(keyword | name)
job-hold-until-supported client matches administrator-configured
(keyword | name)
job-sheets client matches administrator-configured
(keyword | name)
job-sheets-default client matches administrator-configured
(keyword | name)
job-sheets-supported client matches administrator-configured
(keyword | name)
media client matches administrator-configured
(keyword | name)
media-default client matches administrator-configured
(keyword | name)
media-supported client matches administrator-configured
(keyword | name)
media-ready client matches administrator-configured
(keyword | name)
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
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 (text(127)) operator8. Security Considerations ✨
Okay bestie, security time 🔐💅 Some IPP objects MAY be deployed over protocol stacks that support Secure Socket Layer Version 3 (SSL3) [SSL]. Quick tea ☕: SSL3 is not an IETF standards track specification, so don't assume it's standards-track stuff 🙈. Other IPP objects MAY be deployed over protocol stacks that do not support SSL3, and some IPP objects MAY be deployed over both types of stacks 🦋. The ones that do support SSL3 can do mutual authentication AND privacy of messages through multiple encryption schemes 🔥. The main thing to know is that for SSL3 access to an IPP object, the security-related parameters (authentication, encryption keys, etc.) are "out-of-band" to the actual IPP protocol 👑.
An IPP object that does not support SSL3 MAY elect to support a transport layer that provides other security mechanisms. For example, when IPP is mapped over HTTP/1.1 [RFC2565] and the IPP object doesn't support SSL3, HTTP still allows client authentication using Digest Access Authentication (DAA) [RFC2069] 🌸.
It's really hard to predict every security risk in a given IPP environment 🙃. If IPP is used inside a corporation over a private network, the risks of exposing document data may be low enough that the corporation chooses not to encrypt that data. But if the connection between the client and the IPP object goes over a public network, the client may want to protect the content during transmission with encryption 🔒.
The value of what's being printed can also change from one IPP environment to the next. Printing payroll checks is a whole different vibe than printing public information from a file 💸. There's also the possibility of denial-of-service attacks, but those against printing resources aren't well understood, 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.0, and must be established through some other administrative or access control framework. That said, there are operation status codes that let an IPP server tell 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. That info can be used to verify a client's identity for later operations on that Job object, so the access control policy can be enforced. See section 8.3 below for more details 📖.
Since nobody can predict the security levels or specific threats that any given IPP system administrator might worry about, IPP MUST be capable of operating with different security mechanisms and security policies as required by the individual installation. Policies might range from very strong, to very weak, to none at all, and matching security mechanisms will be required. SSL3 supports the negotiated levels of security that most, if not all, potential IPP environments need 🫶. IPP environments that require no security can elect to deploy IPP objects that don't use the optional SSL3 security mechanisms ✨.
8.1 Security Scenarios
The following sections describe specific security attacks for IPP environments 🕵️♀️. Where examples are given, they should be seen as illustrative of the environment and not an exhaustive set. Not all of these environments will necessarily be addressed in initial implementations of IPP 🌈.
8.1.1 Client and Server in the Same Security Domain
This environment is typical of internal networks, where regular office workers print the output of personal productivity applications on shared work-group printers, or where batch applications print their output on large production printers 🖨️. Even though the user's identity may be trusted here, a user might still want to protect a document's content from attacks like eavesdropping, replaying, or tampering 👀.
8.1.2 Client and Server in Different Security Domains
Examples of this environment include printing a document created by the client on a publicly available printer, like one at a commercial print shop, or printing a document remotely on a business associate's printer 🏪. That second one is basically the same as sending the document to the business associate as a fax 📠. Printing sensitive information on a Printer in a different security domain requires strong security measures 😬. In this environment, authentication of the printer is required, along with protection against unauthorized use of print resources. Since the document crosses security domains, protection against eavesdropping and document tampering is also required. It's also important here to protect Printers against "spamming" and malicious document content 🚫.
8.1.3 Print by Reference
When the document isn't stored on the client, printing can be done by reference 🔗. That means the print request can contain a reference, or pointer, to the document instead of the document itself. Standard methods don't currently exist for remote entities to "assume" a client's credentials when forwarding requests to a 3rd party 🙅♀️. Print-By-Reference is expected to be used to access "public" documents, and sophisticated methods for authenticating "proxies" will not be specified for version 1 of IPP 🧚.
8.2 URIs for SSL3 and non-SSL3 Access
As described earlier, an IPP object can support SSL3 access, non-SSL3 access, or both 🦋. The printer-uri-supported attribute holds the Printer object's URI(s). Its companion 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 though the Printer supports more than one URI, the client only talks to 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 The "requesting-user-name" (name(MAX)) Operation Attribute
This is a big one, so pay attention 👑. Each operation MUST specify the user who is performing it in both of the following two ways:
- via the REQUIRED
requesting-user-nameoperation attribute, which a client SHOULD supply in all operations. The client MUST get the value for this attribute from an environmental or network login name for the user, rather than letting the user type in any value 🙅♀️. If the client doesn't supply a value forrequesting-user-name, the printer MUST assume the client is using some anonymous name, like "anonymous" 🫥. - via an authentication mechanism of the underlying transport, which may be configured to give no authentication information 🔐.
There are six cases to consider 📋:
- a) the authentication mechanism gives no information, and the client doesn't specify
requesting-user-name. - b) the authentication mechanism gives no information, but the client specifies
requesting-user-name. - c) the authentication mechanism specifies a user who has no human readable representation, and the client doesn't specify
requesting-user-name. - d) the authentication mechanism specifies a user who has no human readable representation, but the client specifies
requesting-user-name. - e) the authentication mechanism specifies a user who has a human readable representation. The Printer object ignores the
requesting-user-name. - f) the authentication mechanism specifies a user who is trusted, and whose name means that the value of the
requesting-user-name, which MUST be present, is treated as the authenticated name 🤝.
Note: Case "f" is meant for a tightly coupled gateway and server working together, so the "user" name can be that of the gateway client and not that of the gateway 🌸. Since most, if not all, system vendors will first implement IPP via a gateway into their existing print system, this mechanism is necessary unless the authentication mechanism lets a gateway (client) act on behalf of some other client 💅.
The user-name has two forms, and they're each used for different things 💖:
- one that's human readable: it's held in the REQUIRED
job-originating-user-nameJob Description attribute, which is set during the job creation operations. It's only for presentation, like showing up in queries or getting printed on start sheets 📄. - one for authorization: it's held in a Job object attribute that IPP doesn't define, which the job creation operation sets. It's used to authorize other operations, like Send-Document, Send-URI, and Cancel-Job 🔑. It also decides who the user is when the
my-jobsattribute is used with Get-Jobs, and it limits which attributes and values get returned by Get-Job-Attributes and Get-Jobs 👀.
The human readable user name:
- is the value of the
requesting-user-namefor cases b, d and f. - comes from the authentication mechanism for case e.
- is some anonymous name, like "anonymous", for cases a and c 🫥.
The user name used for authorization:
- is the value of the
requesting-user-namefor cases b and f. - comes from the authentication mechanism for cases c, d and e.
- is some anonymous name, like "anonymous", for case a 🎭.
The big idea behind resolving conflicting user-name sources is that a printer implementation can pick either source, as long as it gets consistent results 🧩. That means if a user takes the same path for a series of requests, the requests MUST appear to come from the same user, from the standpoint of both the human-readable user name and the user name for authorization 💯. This rule MUST continue to apply even if a request could be authenticated by two or more mechanisms ✨. It doesn't matter which of several authentication mechanisms a Printer uses, as long as the results stay consistent 🌈. If a client uses more than one authentication mechanism, it is recommended that an administrator make all credentials resolve to the same user and user-name as much as possible 🫶.
8.4 Restricted Queries
In lots of IPP operations, a client gives a list of attributes to be returned in the response 📝. For security reasons, an IPP object may be configured not to return all attributes (or all values) that a client asks for 🔒. The job attributes returned MAY depend on whether the requesting user is the same as the user who submitted the job 👯. The IPP object MAY even return none of the requested attributes 🙈. In those cases, the status returned is the same as if the object had returned all requested attributes. So the client can't tell from that response whether the requested attribute was present or absent on the object 🫣💅.
8.5 Queries on jobs submitted using non-IPP protocols 🦋
okay so bestie, picture this: the device behind an IPP Printer can take jobs from other protocols too, not just IPP. ✨ For those, it is RECOMMENDED that the implementation at least let people query these "foreign" jobs with Get-Jobs, returning "job-id" and "job-uri" as 'unknown'. 💅 It NEED NOT support every single IPP job attribute for them, though. The IPP object gives back the 'unknown' out-of-band value for any requested attribute that's supported for IPP jobs but not for foreign jobs. Not me being shady, that's just how it works 🙈
It is further RECOMMENDED that the IPP Printer generate "job-id" and "job-uri" values for these "foreign jobs" if it's possible, so they can be targets of other IPP operations, like Get-Job-Attributes and Cancel-Job. 🎀 The implementation also has to deal with authenticating foreign jobs, and that part is lowkey tricky. One approach is to treat every foreign job as belonging to users other than the user of the IPP client. Another is to make the foreign job belong to 'anonymous'. Only if the IPP client has been authenticated as an operator or administrator of the IPP Printer object can the foreign jobs be queried by an IPP request. 👑
Alternatively, if the security policy lets users 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. It's giving open-door policy 🌸
8.6 IPP Security Application Profile for SSL3 🔐
The IPP application profile for SSL3 follows the "Secure Socket Layer" requirement as documented in the SSL3 specification [SSL]. For interoperability, the SSL3 cipher suites are:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_WITH_NULL_MD5Client implementations MUST NOT assume any other cipher suites are supported by an IPP Printer object. Not everything is a given, bestie 💀
If a conforming IPP object supports SSL3, it MUST implement and support the cipher suites listed above and MAY support additional cipher suites. ✨
A conforming IPP client SHOULD support SSL3 including the cipher suites listed above. A conforming IPP client MAY support additional cipher suites. 🧚
⚠️ Export-grade warning, this part is serious: It is possible that due to certain government export restrictions some non-compliant versions of this extension could be deployed. Implementations wishing to inter-operate with such non-compliant versions MAY offer the SSL_RSA_EXPORT_WITH_RC4_40_MD5 and SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 mechanisms. However, since 40 bit ciphers are known to be vulnerable to attack by current technology, any client which actives a 40 bit cipher MUST NOT indicate to the user that the connection is completely secure from eavesdropping. 😭 Do NOT let a user think a 40 bit connection is totally private, it's not.
9. References 📚
- [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.
- [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-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. and C. Manros, "Internet Printing Protocol/1.0: Implementer's Guide", Work in Progress.
- [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.
- [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.
- [RFC1179] McLaughlin, L. (Editor), "Line Printer Daemon Protocol", RFC 1179, August 1990.
- [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 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.
- [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. AND T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, January 1997.
- [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
- [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.
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages" 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.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, 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.
- [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.pdf
10. Authors' Addresses 💌
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.
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
Robert Herriot
Xerox Corporation
3400 Hillview Ave., Bldg #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 Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
Implementers of this specification are encouraged to join IPP Mailing
List in order to participate in any discussions of clarification
issues and review of registration proposals for additional attributes
and values.
Other Participants:
Chuck Adams - Tektronix
Jeff Barnett - IBM
Ron Bergman - Dataproducts Corp.
Sylvan Butler - HP
Keith Carter - IBM Corporation
Jeff Copeland - QMS
Andy Davidson - Tektronix
Mabry Dozier - QMS
Lee Farrell - Canon Information Systems
Steve Gebert - IBM
Babek Jahromi - Microsoft
David Kellerman - Northlake Software
Rick Landau - Digital
Greg LeClair - Epson
Harry Lewis - IBM
Pete Loya - HP
Ray Lutz - Cognisys
Mike MacKay - Novell, Inc.
Daniel Manchala - Xerox
Carl-Uno Manros - Xerox
Jay Martin - Underscore
Larry Masinter - Xerox
Stan McConnell - Xerox
Ira McDonald - High North Inc.
Paul Moore - Microsoft
Tetsuya Morita - Ricoh
Yuichi Niwa - Ricoh
Pat Nogay - IBM
Ron Norton - Printronics
Bob Pentecost - HP
Rob Rhoads - Intel
Xavier Riley - Xerox
David Roach - Unisys
Stuart Rowley - Kyocera
Hiroyuki Sato - Canon
Bob Setterbo - Adobe
Devon Taylor - Novell, Inc.
Mike Timperman - Lexmark
Randy Turner - Sharp
Atsushi Yuki - Kyocera
Rick Yardumian - Xerox
Lloyd Young - Lexmark
Bill Wagner - DPI
Jim Walker - DAZEL
Chris Wellens - Interworking Labs
Rob Whittle - Novell, Inc.
Don Wright - Lexmark
Peter Zehler - Xerox
Steve Zilles - Adobe11. Formats for IPP Registration Proposals 📝
In order to propose an IPP extension for registration, the proposer must submit an application to IANA by email to "iana@iana.org" or by filling out the appropriate form on the IANA web pages (http://www.iana.org). This section specifies the required information and the formats for proposing registrations of extensions to IPP as provided in Section 6 for:
- type2
'keyword'attribute values - type3
'keyword'attribute values - type2
'enum'attribute values - type3
'enum'attribute values - attributes
- attribute syntaxes
- operations
- status codes
11.1 Type2 keyword attribute values registration ✨
Okay bestie, here's the form for proposing a type2 keyword attribute value 💌
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 your point of contact for the approved registration specification, if any maintenance of that spec is needed 🧚
11.2 Type3 keyword attribute values registration 🎀
Same energy, but for type3 keyword values 💅
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 specification, if any maintenance of it is needed 🫶
11.3 Type2 enum attribute values registration 🦋
Enums get their own form, and this one's for type2 enum attribute values 🌸
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 specification, if any maintenance of it is needed 👑
11.4 Type3 enum attribute values registration 💜
Last of the enum forms, this one for type3 enum attribute values ✨
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 specification, if any maintenance of it is needed 🍓
11.5 Attribute registration 🌈
This is the big one for registering a whole new attribute, so pay attention 👀
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 specification, if any maintenance of it is needed 💅
11.6 Attribute Syntax registration 🎀
Here's where you register a brand new attribute syntax 🧁
Type of registration: attribute syntax
Proposed name of this attribute syntax:
Type of attribute syntax (integer, octetString, character-string,
see [RFC2565]):
Numeric value (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 specification, if any maintenance of it is needed 🔥
11.7 Operation registration ⭐
For registering a new operation, use this one 🧚
Type of registration: operation
Proposed name of this operation:
Numeric operation-id value (to be assigned by the IPP Designated
Expert in consultation with IANA):
Object Target (Job, Printer, etc. that operation is upon):
Specification of this attribute (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 specification, if any maintenance of it is needed 🦋
11.8 Attribute Group registration 🌸
And this one's for attribute groups 💖
Type of registration: attribute group
Proposed name of this attribute group:
Numeric tag according to [RFC2565] (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 specification, if any maintenance of it is needed 🫶
11.9 Status code registration 💀
Last form, for 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 14 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 specification, if any maintenance of it is needed 🌈
12. APPENDIX A: Terminology 📖
Okay, now the vocab. This section defines the terms the spec uses, so you'll want to know them 🧠
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]. 💅
12.1.1 NEED NOT 🙈
This term isn't in RFC 2119, fr fr. "NEED NOT" means an action the subject of the sentence doesn't have to implement to claim conformance to the standard. They used "NEED NOT" instead of "MAY NOT" because "MAY NOT" sounds like a prohibition, and nobody wants that vibe 🫶
12.2 Model Terminology 🦋
12.2.1 Keyword 🔑
Keywords are used in this document as identifiers for semantic entities within the abstract model (see section 4.1.2.3). Attribute names, some attribute values, attribute syntaxes, and attribute group names are all represented as keywords ✨
12.2.2 Attributes 🧚
An attribute is an item of information associated with an instance of an IPP object. It's made up of an attribute name and one or more attribute values, and 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, which is an operation request that creates Job objects. The Printer object has associated attributes that define its supported and default values 🖨️
12.2.2.1 Attribute Name 🏷️
Every attribute is uniquely identified in this document by its attribute name, and an attribute name is a keyword. The keyword attribute name is given in the section header describing that attribute. In running text, attribute names are shown inside double quotation marks ("), but the quotation marks aren't part of the keyword itself 🎀
12.2.2.2 Attribute Group Name 🍓
Related attributes get grouped into named groups. The name of the group is a keyword, and you can use the group name in place of naming every attribute in the group one by one. Attribute groups are defined in section 3 🌸
12.2.2.3 Attribute Value 💖
Each attribute has one or more values, and those values are represented in the syntax type specified for that attribute. In running text, attribute values are shown inside single quotation marks ('), whatever their attribute syntax is (keyword, integer, text, etc.). The quotation marks aren't part of the value itself 🌈
12.2.2.4 Attribute Syntax 🧩
Every attribute is defined using an explicit syntax type, and in this document each syntax type is defined as a keyword with a specific meaning. The Encoding and Transport document [RFC2565] lays out 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 matching attribute filled in with some value(s) when someone asks for it. 💅 A Printer object supports an attribute value if that value is one of the Printer object's "supported values" attributes. 🦋 The device behind a Printer object might act in a way that matches some IPP attribute, but if the Printer object doesn't reply with that attribute when queried, then as far as IPP is concerned, that implementation does not support the feature. 🙈 And if the Printer object's xxx-supported attribute isn't populated with a particular value (even when that value is totally legal for the attribute), then that Printer object does not support that value. Not me being picky, it's just how it works. 😭
A conforming implementation MUST support all REQUIRED attributes. 🔥 Even so, for REQUIRED attributes, conformance to IPP doesn't force every implementation to support every possible value covering every possible job processing behaviour and feature. 🌈 For example, if a given Printer only supports certain document formats, then that Printer replies with the "document-format-supported" attribute filled with a set of values, maybe just one, taken from the full set of possible values defined for that attribute. That limited set is the Printer's list of supported document formats. 🎀 Supporting an attribute, and some set of values for it, lets IPP end users know those features exist and actually use them. ✨ If an implementation chooses not to support an attribute or a specific value, then IPP end users have zero ability to use that feature within IPP itself. 💀 BUT, because of existing practice and legacy systems that aren't IPP aware, there might be some other mechanism outside the scope of IPP that controls or requests the "unsupported" feature (like embedded instructions inside the document data itself). Iconic, honestly. 👑
Let's look at the "finishings-supported" attribute as an example. 🧚
- If a Printer object is not physically capable of stapling, the
"finishings-supported"attribute MUST NOT be populated with the value'staple'. 🙅♀️ - A Printer object is physically capable of stapling, but 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'staple', an IPP end user has no way within the protocol itself to request that a Job be stapled. 😩 However, an existing document data formatter might be able to request stapling directly with an embedded instruction inside the document data. In this case, the IPP implementation does not "support" stapling, but the end user still gets some control over stapling the completed job. Lowkey clever. 🧠 - 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 lets end users know about the stapling feature and use it through 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 can realize any feature or function that matches an IPP attribute and some associated value, then that implementation SHOULD support that IPP attribute and value. 💖
The set of values in any of the supported value attributes gets filled in (populated) by some administrative process or automatic sensing mechanism that is outside the scope of IPP. 🌸 For administrative policy and control reasons, an administrator may choose to show only a subset of the possible values to the end user. In that case, the real output device behind the IPP Printer abstraction might be capable of a certain feature, but the 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 one), 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 make the semantic action tied to that value happen, but no end user action is required. Very behind-the-scenes energy. 🌈
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 stapling might be a manual action by an operator at an operator attended Printer object. 🙋♀️
Here's another example of how supported attributes work. 🎀 Say a system administrator wants to control all print jobs so no job sheets get printed, to save paper. 🌿 To force no job sheets, the 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 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"). The power move is really in the admin's hands. 👑
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 💅
This section defines status code enum keywords and values that give semantic info on the results of an operation request. 🔥 Each operation response MUST include a status code. The response MAY also contain a status message that gives a short textual description of the status. The status code is meant for automata, and the status message is meant for the human end user. 💖 Since the status message is an OPTIONAL part of the operation response, an IPP application (i.e., a browser, GUI, print driver or gateway) is NOT REQUIRED to examine or display the status message, since it MAY not be returned to the application. Tea. ☕
The prefix of the status keyword tells you the class of response, like this: 🧚
"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 requestAs with type2 enums, IPP status codes are extensible. ✨ IPP clients are NOT REQUIRED to understand the meaning of all registered status codes, though understanding them is obviously desirable. 🤓 However, IPP clients MUST understand the class of any status code, as indicated by the prefix, and MUST treat any unrecognized response as equivalent to the first status code of that class, with one exception: an unrecognized response MUST NOT be cached. 🚫 For example, if an unrecognized status code of "client-error-xxx-yyy" arrives at the client, it can safely assume something was wrong with its request and treat the response as if it had received a "client-error-bad-request" status code. 🙈 In these cases, IPP applications SHOULD present the OPTIONAL message (if present) to the end user, since the message is likely to hold human readable info that helps explain the unusual status. The name of the enum is the suggested status message for US English. 🇺🇸
The status code values range from 0x0000 to 0x7FFF. The value ranges for each status code class are as follows: 🌈
"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 private use within each status code class. 🔒 Values 0x0600 to 0x7FFF are reserved for future assignment and MUST NOT be used. Do not touch those. 🚧
13.1 Status Codes 🎀
Each status code is described below. Section 13.1.5.9 contains a table that shows 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 of status code indicates a provisional response and is only to be used for informational purposes. ✨
There are no status codes defined in IPP/1.0 for this class of status code. Empty shelf, for now. 🫙
13.1.2 Successful Status Codes 🎉
This class of status code indicates that the client's request was successfully received, understood, and accepted. 🥳
13.1.2.1 successful-ok (0x0000) 💖
The request has succeeded and no request attributes were substituted or ignored. In the case of a response to a create request, the successful-ok status code means the request was successfully received and validated, and that the Job object has been created. It does NOT mean the job has been processed. 🙅♀️ The transition of the Job object into the 'completed' state is the only indicator that the job has been printed. Main character energy for that state. 👑
13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) 🦋
The request has succeeded, but some supplied (1) attributes were ignored, or (2) unsupported values were replaced with supported values or ignored, so the operation could be performed without rejecting it. 🪄 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. When the supplied values of the "requested-attributes" operation attribute 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 section 3.2.1.2. 🌸
13.1.2.3 successful-ok-conflicting-attributes (0x0002) 🔥
The request has succeeded, but some supplied attribute values conflicted with the values of other supplied attributes. 😬 These conflicting values were either (1) replaced with (supported) values, or (2) the attributes were removed, so the job could be processed without rejecting it. Attributes or values that conflict with other attributes and got replaced or ignored MUST be returned in the Unsupported Attributes group of the response for all operations, as supplied by the client. See section 3.2.1.2. Receipts, bestie. 🧾
13.1.3 Redirection Status Codes ✨
okay so this class of status code is basically saying "not done yet, you need to take another step" 🦋 the request isn't finished until you go do that next thing
there are no status codes defined in IPP/1.0 for this class 🙈 so it's a whole empty shelf rn, nothing to see here bestie
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 that explains what went wrong and whether the problem is temporary or permanent 🫶
13.1.4.1 client-error-bad-request (0x0400) 🎀
the IPP object couldn't understand the request because the syntax was malformed 💀 like, a fixed length attribute whose value doesn't match the length it's supposed to have (check the Implementer's Guide [ipp-iig] for the deets)
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 it's straight up refusing to do it 💅 extra authentication info or credentials won't help, so the request SHOULD NOT be repeated
this one is super common when the IPP object doesn't want to say exactly why it said no, or when no other response really 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 info
if the request already had authentication info in it, then this code means authorization got refused for those credentials 😭 and if the response has the same challenge as the last one, and the user agent already tried authenticating at least once, the response may include relevant diagnostic info 🧚
this one reveals more info than "client-error-forbidden" 👀
13.1.4.4 client-error-not-authorized (0x0403) 👑
the requester isn't authorized to do the thing 💅 extra authentication info or credentials won't help, and the request SHOULD NOT be repeated
this is used when the IPP object wants to show that the auth info is understandable, but the requester is explicitly not allowed to do the request 🫠 it reveals more than "client-error-forbidden" and "client-error-not-authenticated" 💜
13.1.4.5 client-error-not-possible (0x0404) 🙈
this one's for when the request is for something that literally can't happen 💀 like trying 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 willing to wait ✨ for example, a client made a Create-Job operation, then waited a long time and made a Send-Document operation, and this code came back as the response to that Send-Document request (see section 3.3.1) 😭
the IPP object might have been forced to clean up resources it was holding for the extra Documents, and it was forced to close the Job because the client took too long 🥺 so the client SHOULD NOT repeat the request without modifications
13.1.4.7 client-error-not-found (0x0406) 🧚
the IPP object didn't find anything matching the request URI 🙈 there's no hint about whether it's temporary or permanent
for example, a client has an old reference to a Job (a URI) and tries to cancel it, but in the meantime the Job might have been completed and all record of it at the Printer got deleted 💀 so client-error-not-found comes back to say the referenced Job can't be found ✨ this error is also used when a client gives a URI pointing to the document data in a Print-URI or Send-URI operation, and the document can't be found 🫶
In practice, an IPP application should avoid a not found situation by first querying and presenting a list of valid Printer URIs and Job URIs to the end-user. 💅
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, then "client-error-not-found" should be used instead 🙈
this response is mainly there to help with maintenance ✨ it tells the recipient that the resource is intentionally unavailable and that the IPP object administrator wants remote links to that resource removed 🧹 you don't have to mark every permanently unavailable resource as "gone", and you don't have to keep the mark for any length of time, because that's up to the discretion of the IPP object administrator 💅
13.1.4.9 client-error-request-entity-too-large (0x0408) 🍓
the IPP object is refusing to process the request because the request entity is bigger than the IPP object is willing or able to handle 😭 a Printer returns this when it limits the size of print jobs and gets a job over that limit, or when there are so many attributes that their encoding makes the request entity go over the IPP object's capacity 🖨️
13.1.4.10 client-error-request-value-too-long (0x0409) 🦋
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 IPP object might not have enough resources (memory, buffers, etc.) to process, interpret, and/or ignore a value that's larger than the maximum length, even temporarily 🥺 another use is when the IPP object can handle a large value that's still under the maximum, but while processing the request as a whole, it may pass the value on to some other system component that can't accept the large value 💀 for more details, check the Implementer's Guide [ipp-iig] 📖
Note: For attribute values that are URIs, this rare condition is only likely to occur when a client has improperly submitted a request with long query information (e.g. an IPP application lets an end-user enter an invalid URI), when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the IPP object is under attack by a client trying to exploit security holes in some IPP objects that use fixed-length buffers for reading or manipulating the Request-URI. 🚨😭
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 (as specified in the "document-format" operation attribute) that the Printer object doesn't support 💀 this error is returned no matter what the client supplied for "ipp-attribute-fidelity" ✨ the Printer object MUST return this status code, even if there are other attributes it doesn't support too, because this error is a way bigger problem than Job Template attributes 👑
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 in the request, and the client supplied the "ipp-attributes-fidelity" operation attribute with the 'true' value, the Printer object MUST return this status code 🫠 for example, if the request asks for 'iso-a4' media but the Printer doesn't support that media type, or if the client supplies an optional attribute that the Printer doesn't support at all 😤
if the "ipp-attribute-fidelity" attribute is 'false', the Printer MUST ignore or substitute values for unsupported attributes and values, instead of rejecting the request and returning this status code 🧚
for any operation where a client requests attributes (like a Get-Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if the IPP object doesn't support one or more of the requested attributes, it just ignores those unsupported requested attributes and processes the request like they were never supplied 💅 so it doesn't return this status code in that case ✨ instead, the IPP object MUST return the 'successful-ok-ignored-or-substituted-attributes' status code, and it 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 type of the client-supplied URI in a Print-URI or a Send-URI operation isn't supported 🙈
13.1.4.14 client-error-charset-not-supported (0x040D) 🌐
for any operation, if the IPP Printer doesn't support the charset the client supplied in the "attributes-charset" operation attribute, the Printer MUST reject the operation 🚫 it has to return this status, and any 'text' or 'name' attributes must use the 'utf-8' charset (see Section 3.1.4.1) 💜
13.1.4.15 client-error-conflicting-attributes (0x040E) 🥊
the request gets rejected because some attribute values conflicted with the values of other attributes, and this specification doesn't allow them to be substituted or ignored 😵💫
13.1.5 Server Error Status Codes 🧯
this class is for cases where the IPP object knows it messed up, or it just can't do the request 😭 the IPP object SHOULD include a message explaining the error and whether it's a temporary or permanent condition 🫶
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 it implies something unexpected (unlike a paper jam or running out of toner, which are annoying but expected) 🖨️ this error code probably means some knowledgeable human has 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 isn't capable of supporting it 💅
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 temporary and will get better after some delay ⏳ if the length of the delay is known, it may be indicated 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 🧚 and if the condition is more permanent, then "client-error-gone" or "client-error-not-found" could be used instead 👀
13.1.5.4 server-error-version-not-supported (0x0503) ✨
okay so this one is about versions 🦋 The IPP object doesn't support the IPP protocol version used in the request, or it straight up refuses to. It's basically saying "I can't do this version, I'm not doing it on that version," and it sends this error instead. The response should contain a Message explaining why that version isn't supported and which other versions that IPP object does support 💅
Now the rules, bestie 🫶 A conforming IPP/1.0 client MUST specify the valid version ('1.0') on each request. A conforming IPP/1.0 object MUST NOT return this status code to a conforming IPP/1.0 client, because that would be messy 🙈 But an IPP object MUST return this status code to a non-conforming IPP client. And the response MUST identify, in the "version-number" operation attribute, the closest version number that the IPP object does support. No skipping that part 💜
13.1.5.5 server-error-device-error (0x0504) 🔥
so this is when a printer error happens, like a paper jam, 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), which is giving honesty. You can also get extra info in the optional "job-state-message" attribute value, or in the OPTIONAL status message that explains the error in more detail 🎀
This error code only comes back when the Printer can't accept the create request because of a device error like that. Like, if the Printer can't spool and only takes one job at a time, it might reject a create request because it has a paper jam right now 🖨️💀 But lowkey, if the Printer object can still accept the request even with some error condition, you get 'successful-ok' instead. Then the client looks at the returned Job Object Attributes, or asks the Printer later for its state and state reasons ✨
13.1.5.6 server-error-temporary-error (0x0505) 🌸
a temporary error is something like a buffer full write error, a memory overflow (aka the document data is bigger than the Printer's memory), or a disk full condition 😵 It happens 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 clears, so no error is returned at all. Main character energy for the printer 👑
13.1.5.7 server-error-not-accepting-jobs (0x0506) 🍓
this one's a temporary error saying the Printer isn't accepting jobs right now. Why? Because the administrator set the Printer's "printer-is-not-accepting-jobs" attribute to 'false' (through means outside of IPP/1.0) 🙃 Not the printer's fault, just the admin being the admin 💅
13.1.5.8 server-error-busy (0x0507) 💜
another temporary error, but this one's just the Printer being too busy with jobs and/or other requests 🫠 The client SHOULD try the unmodified request again later, hoping the busy condition has been cleared. Patience is a whole vibe 🌈
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. If not, then no job-id and job-uri come back in the response. Super simple, but it hits different 🥺
13.2 Status Codes for IPP Operations 🎀
here's the cheat sheet, bestie 📋 First, the key for the operation abbreviations:
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-JobAnd here's the table of which status keywords go with which operations. Iykyk 💖
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
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 x14. APPENDIX C: "media" keyword values ✨
okay so the standard keyword values come from a few different places, bestie 🎀
Standard values are defined (taken from DPA[ISO10175] and the Printer MIB[RFC1759]):
default: the default medium for the output device 🧚iso-a4-white: the ISO A4 white medium 🤍iso-a4-colored: the ISO A4 colored medium 🌈iso-a4-transparent: the ISO A4 transparent medium 🦋iso-a3-white: the ISO A3 white mediumiso-a3-colored: the ISO A3 colored mediumiso-a5-white: the ISO A5 white mediumiso-a5-colored: the ISO A5 colored mediumiso-b4-white: the ISO B4 white mediumiso-b4-colored: the ISO B4 colored mediumiso-b5-white: the ISO B5 white mediumiso-b5-colored: the ISO B5 colored mediumjis-b4-white: the JIS B4 white mediumjis-b4-colored: the JIS B4 colored mediumjis-b5-white: the JIS B5 white mediumjis-b5-colored: the JIS B5 colored medium
the North American crew gets its own list 🇺🇸 these are the standard values defined for North American media:
na-letter-white: the North American letter white mediumna-letter-colored: the North American letter colored mediumna-letter-transparent: the North American letter transparent mediumna-legal-white: the North American legal white mediumna-legal-colored: the North American legal colored medium
envelopes get their own moment 💌 the following standard values are defined for envelopes:
iso-b4-envelope: the ISO B4 envelope mediumiso-b5-envelope: the ISO B5 envelope mediumiso-c3-envelope: the ISO C3 envelope mediumiso-c4-envelope: the ISO C4 envelope mediumiso-c5-envelope: the ISO C5 envelope mediumiso-c6-envelope: the ISO C6 envelope mediumiso-designated-long-envelope: the ISO Designated Long envelope mediumna-10x13-envelope: the North American 10x13 envelope mediumna-9x12-envelope: the North American 9x12 envelope mediummonarch-envelope: the Monarch envelopena-number-10-envelope: the North American number 10 business envelope mediumna-7x9-envelope: the North American 7x9 inch envelopena-9x11-envelope: the North American 9x11 inch envelopena-10x14-envelope: the North American 10x14 inch envelopena-number-9-envelope: the North American number 9 business envelopena-6x9-envelope: the North American 6x9 inch envelopena-10x15-envelope: the North American 10x15 inch envelope
the less commonly used media are white-only, so these are the standard values defined for them:
executive-white: the white executive mediumfolio-white: the folio white mediuminvoice-white: the white invoice mediumledger-white: the white ledger mediumquarto-white: the white quarto mediumiso-a0-white: the ISO A0 white mediumiso-a1-white: the ISO A1 white mediumiso-a2-white: the ISO A2 white mediumiso-a6-white: the ISO A6 white mediumiso-a7-white: the ISO A7 white mediumiso-a8-white: the ISO A8 white mediumiso-a9-white: the ISO A9 white mediumiso-10-white: the ISO A10 white mediumiso-b0-white: the ISO B0 white mediumiso-b1-white: the ISO B1 white mediumiso-b2-white: the ISO B2 white mediumiso-b3-white: the ISO B3 white mediumiso-b6-white: the ISO B6 white mediumiso-b7-white: the ISO B7 white mediumiso-b8-white: the ISO B8 white mediumiso-b9-white: the ISO B9 white mediumiso-b10-white: the ISO B10 white mediumjis-b0-white: the JIS B0 white mediumjis-b1-white: the JIS B1 white mediumjis-b2-white: the JIS B2 white mediumjis-b3-white: the JIS B3 white mediumjis-b6-white: the JIS B6 white mediumjis-b7-white: the JIS B7 white mediumjis-b8-white: the JIS B8 white mediumjis-b9-white: the JIS B9 white mediumjis-b10-white: the JIS B10 white medium
engineering media next 📐 the following standard values are defined for engineering media:
a: the engineering A size mediumb: the engineering B size mediumc: the engineering C size mediumd: the engineering D size mediume: the engineering E size medium
input trays are up next, and these are defined from ISO DPA and the Printer MIB 🖨️ the following standard values are defined for input-trays:
top: the top input tray in the printermiddle: the middle input tray in the printerbottom: the bottom input tray in the printerenvelope: the envelope input tray in the printermanual: the manual feed input tray in the printerlarge-capacity: the large capacity input tray in the printermain: the main input trayside: the side input tray
and last but definitely not least, media sizes (from ISO DPA) 📏✨ the following standard values are defined for media sizes:
iso-a0: the ISO A0 size, 841 mm by 1189 mm, as defined in ISO 216iso-a1: the ISO A1 size, 594 mm by 841 mm, as defined in ISO 216iso-a2: the ISO A2 size, 420 mm by 594 mm, as defined in ISO 216iso-a3: the ISO A3 size, 297 mm by 420 mm, as defined in ISO 216iso-a4: the ISO A4 size, 210 mm by 297 mm, as defined in ISO 216iso-a5: the ISO A5 size, 148 mm by 210 mm, as defined in ISO 216iso-a6: the ISO A6 size, 105 mm by 148 mm, as defined in ISO 216iso-a7: the ISO A7 size, 74 mm by 105 mm, as defined in ISO 216iso-a8: the ISO A8 size, 52 mm by 74 mm, as defined in ISO 216iso-a9: the ISO A9 size, 37 mm by 52 mm, as defined in ISO 216iso-a10: the ISO A10 size, 26 mm by 37 mm, as defined in ISO 216iso-b0: the ISO B0 size, 1000 mm by 1414 mm, as defined in ISO 216iso-b1: the ISO B1 size, 707 mm by 1000 mm, as defined in ISO 216iso-b2: the ISO B2 size, 500 mm by 707 mm, as defined in ISO 216iso-b3: the ISO B3 size, 353 mm by 500 mm, as defined in ISO 216iso-b4: the ISO B4 size, 250 mm by 353 mm, as defined in ISO 216iso-b5: the ISO B5 size, 176 mm by 250 mm, as defined in ISO 216iso-b6: the ISO B6 size, 125 mm by 176 mm, as defined in ISO 216iso-b7: the ISO B7 size, 88 mm by 125 mm, as defined in ISO 216iso-b8: the ISO B8 size, 62 mm by 88 mm, as defined in ISO 216iso-b9: the ISO B9 size, 44 mm by 62 mm, as defined in ISO 216iso-b10: the ISO B10 size, 31 mm by 44 mm, as defined in ISO 216na-letter: the North American letter size, 8.5 inches by 11 inchesna-legal: the North American legal size, 8.5 inches by 14 inchesexecutive: the executive size (7.25 X 10.5 in)folio: the folio size (8.5 X 13 in)invoice: the invoice size (5.5 X 8.5 in)ledger: the ledger size (11 X 17 in)quarto: the quarto size (8.5 X 10.83 in)iso-c3: the ISO C3 size, 324 mm by 458 mm, as defined in ISO 269iso-c4: the ISO C4 size, 229 mm by 324 mm, as defined in ISO 269iso-c5: the ISO C5 size, 162 mm by 229 mm, as defined in ISO 269iso-c6: the ISO C6 size, 114 mm by 162 mm, as defined in ISO 269iso-designated-long: the ISO Designated Long size, 110 mm by 220 mm, as defined in ISO 269na-10x13-envelope: the North American 10x13 size, 10 inches by 13 inchesna-9x12-envelope: the North American 9x12 size, 9 inches by 12 inchesna-number-10-envelope: the North American number 10 business envelope size, 4.125 inches by 9.5 inchesna-7x9-envelope: the North American 7x9 inch envelope sizena-9x11-envelope: the North American 9x11 inch envelope sizena-10x14-envelope: the North American 10x14 inch envelope sizena-number-9-envelope: the North American number 9 business envelope sizena-6x9-envelope: the North American 6x9 envelope sizena-10x15-envelope: the North American 10x15 envelope sizemonarch-envelope: the Monarch envelope size (3.87 x 7.5 in)jis-b0: the JIS B0 size, 1030mm x 1456mmjis-b1: the JIS B1 size, 728mm x 1030mmjis-b2: the JIS B2 size, 515mm x 728mmjis-b3: the JIS B3 size, 364mm x 515mmjis-b4: the JIS B4 size, 257mm x 364mmjis-b5: the JIS B5 size, 182mm x 257mmjis-b6: the JIS B6 size, 128mm x 182mmjis-b7: the JIS B7 size, 91mm x 128mmjis-b8: the JIS B8 size, 64mm x 91mmjis-b9: the JIS B9 size, 45mm x 64mmjis-b10: the JIS B10 size, 32mm x 45mm
15. APPENDIX D: Processing IPP Attributes 🎀
okay bestie, so when you submit a print job to a Printer object, IPP lets the client send operation and Job Template attributes along with the document data 💌 those Job Template attributes in the create request affect how the documents in the job get rendered, produced and finished ✨ the print data itself can also hold similar instructions, so the instructions are embedded right inside what gets printed 🖨️ on top of that, the Printer has its own set of attributes that describe which rendering and finishing options it supports 🧚
this model is super flexible and powerful, but it also means the client-supplied attributes at job submission time could conflict with either of these:
- what the implementation is capable of realizing (i.e., what the Printer supports), as well as
- the instructions embedded within the print data itself.
the following sections explain how these two types of conflicts get handled in the IPP model 💖
15.1 Fidelity ✨
Okay so, when what the client asks for and what a Printer object actually supports don't match, the client gets to pick one of two conflict handling options 🫶
- reject the job, since 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.
Option 1 basically means "print it exactly as I asked, no exceptions, and if that's impossible, don't even bother printing it." 💀 Option 2 means "it matters more that this actually gets printed than that it's processed exactly as written, so make sure it prints even if 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 is OPTIONALLY supplied by the client. The value true means total fidelity to the Job Template attributes and values the client supplied is required. The client wants the Job printed exactly as specified, and if that isn't possible, the job MUST be rejected rather than processed incorrectly. The value false means a reasonable attempt at printing the Job is fine. If a Printer doesn't support some of the client-supplied Job Template attributes or values, the Printer MUST ignore them or substitute a supported value for the unsupported ones, respectively. The Printer may use the default value for that attribute, or some other supported value that's similar to the unsupported one that was requested. For example, if a client supplies a media value of na-letter, the Printer may substitute iso-a4 instead of falling back to a default 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 (that is, 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. It ignores unsupported Job Template attributes and swaps in supported values for unsupported values of supported Job Template attributes. - If the client supplies
true, the Printer object MUST reject the request when 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 super useful when:
- The End-User uses a command line interface to request attributes that might not be supported.
- In a GUI context, the End-User expects 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 🌈
If there's a conflict between an IPP Job Template attribute and a matching instruction in the document data, the IPP attribute SHOULD take precedence over the document instruction. Picture this: a previously formatted file gets sent to an IPP Printer. If the client supplies any attributes at submission time, they want those attributes to override the instructions embedded in the file 👑
Say a formatted document has commands inside it to load iso-a4 media. But then it gets passed to an end user who only has a printer with na-letter media loaded. That person most likely wants to submit the document to an IPP Printer with the media Job Template attribute set to na-letter. The job submission attribute should win over the embedded PDL instruction. However, until the companies that make document data interpreters provide a way for external IPP attributes to take precedence over embedded job production instructions, a Printer might not be able to support the idea that IPP attributes override embedded instructions 😭
The IPP model handles this with a pdl-override-supported attribute, which describes the Printer object's ability to override instructions embedded in the PDL data stream. The value of pdl-override-supported is configured by means outside IPP/1.0 💜
This REQUIRED Printer attribute takes one of the following values:
attempted: The Printer object tries to make IPP attribute values take precedence over embedded instructions in the document data, but there's no guarantee.not-attempted: The Printer object makes no attempt to make IPP attribute values take precedence over embedded instructions in the document data.
At job processing time, an implementation that supports attempted might do one of several things:
- Generate an output device specific command sequence to realize the feature represented by the IPP attribute value.
- Parse the document data itself and replace the conflicting embedded instruction with a new embedded instruction that matches the intent of the IPP attribute value.
- Tell the Printer that externally supplied attributes take precedence over embedded instructions, then pass the external IPP attribute values to the document data interpreter.
- Anything else that allows the semantics that IPP attributes override embedded document data instructions. ✨
Since attempted doesn't offer any kind of guarantee, a Printer object might not do a very "good" job of making IPP attributes win over 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 prepend the document data with the PDL instruction that corresponds to the client-supplied PDL attribute, so that if the document data also has that same PDL instruction, it overrides what the Printer prepended. In other words, this implementation uses the same semantics for client-supplied IPP attributes as it does for Printer object defaults.
- Parse the document data and replace the conflicting embedded instruction with a new embedded instruction that approximates, but does not match, the semantic intent of the IPP attribute value.
Note: Theipp-attribute-fidelityattribute applies to the Printer's ability to either accept or reject other unsupported Job Template attributes. In other words, ifipp-attribute-fidelityis set totrue, a Job is accepted if and only if the client-supplied Job Template attributes and values are supported by the Printer. Whether these attributes actually affect processing when the document data contains embedded instructions depends on the Printer's ability to override those embedded instructions with the semantics of the IPP attributes. If the document data attributes can be overridden (pdl-override-supportedset toattempted), the Printer makes an attempt to use the IPP attributes when processing the Job. If they can't be overridden (pdl-override-supportedset tonot-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 Job processing and output when the corresponding instruction is embedded in the document data. 🙈
15.3 Using Job Template Attributes During Document Processing 🎀
okay so the Printer object is literally borrowing some of the Job object's Job Template attributes while it processes the document data for that job 💅 The ones named here are "orientation", "number-up", "sides", "media", and "copies", but that list is not the whole story, bestie ✨ Every document in a Job Object MUST go through the steps below, periodt. These steps only exist to show when and how each attribute gets used. Any alternative steps that get the same effect are totally fine for implementing this spec 🦋
- First, 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 detection algorithm is implementation defined and this spec doesn't specify it. Formatting uses the "orientation-requested" attribute to decide how the formatted print data gets placed on a print-stream page. See section 4.2.10 for the details 🌸
- The document data is now a print-stream in a known media type 💖 The "page-ranges" attribute selects, 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, and 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 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 of document data from subsequent documents get used to complete the impression 🍓
The size (scaling), position (translation) and rotation of the print-stream pages on the impression is implementation defined. Note that during this process the print-stream pages may be rendered 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 nearly the same as the print-stream page. The only differences would be in the size, position and rotation of the print-stream page, and/or any decoration (such as a frame to the page) that the implementation adds 🌈
- The collection of impressions is placed, in sequence, onto sides of the media sheets 📄 This placement is controlled by the "sides" attribute and the orientation of the print-stream page, as described in section 4.2.8. The orientation of the print-stream pages affects the orientation of the impression. For example, if "number-up" equals 2, then typically two portrait print-stream pages become one landscape impression 🔥 The placement of impressions onto media sheets is also controlled by the "multiple-document-handling" attribute, as described in section 4.2.4.
- The "copies" and "multiple-document-handling" attributes determine how many copies of each media instance are created and in what order. See sections 4.2.5 and 4.2.4 for the details 👑
- 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 💅 Sometimes finishing operations need manual intervention to perform them on the copies, especially uncollated copies, so no shade if it's not all automatic 🙈 This specification 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 this section is about a generic schema for an entry in a directory service, and honestly it's giving organized 📂 A directory service is how service users find service providers. In IPP environments, that means IPP Printers can be registered as entries of type printer in the directory, either automatically or with help from an administrator. The registration uses an implementation specific mechanism, like entry attributes, entry type fields, specific branches, etc. 💖 IPP clients can search or browse for entries of type printer. They use the directory service to find entries based on naming, organizational contexts, or filtered searches on attribute values. For example, a client can find all printers in the "Local Department" context 🏢
Authentication and authorization are also often part of a directory service, so an administrator can put limits on end users. They can only find entries they have the right access to, which is very main character of security 🔐 IPP itself does not require any specific directory service protocol or provider 🦋
Note: Some directory implementations allow for the notion of "aliasing". That means one directory entry object can appear as multiple directory entry objects with different names. In each case, each alias refers to the same directory entry object, which 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). Some of these attributes are labeled as either RECOMMENDED or OPTIONAL for the directory entry itself. This conformance labeling is not the same conformance labeling applied to the attributes of IPP Printer objects 😭 The labeling in this Appendix is meant to apply to directory templates, and to IPP Printer implementations that subscribe by adding one or more entries to a directory. RECOMMENDED attributes SHOULD be associated with each directory entry. OPTIONAL attributes MAY be associated with the directory entry (if known or supported). On top of that, all directory entry attributes SHOULD reflect the current attribute values for the corresponding Printer object 🫶
The names of attributes in the directory schema and entries SHOULD be the same as the IPP Printer attribute names as shown 💜
To bridge between the directory service and the IPP Printer object, one of the RECOMMENDED directory entry attributes is the Printer object's "printer-uri-supported" attribute 🌈 The IPP client queries the "printer-uri-supported" attribute in the directory entry, and then addresses the IPP Printer object using one of its URIs. The "uri-security-supported" attribute identifies the protocol (if any) used to secure a channel 🔒
The following attributes define the generic schema for directory entries of type PRINTER ⭐
printer-uri-supported RECOMMENDED Section 4.4.1
uri-security-supported RECOMMENDED Section 4.4.2
printer-name RECOMMENDED Section 4.4.3
printer-location RECOMMENDED Section 4.4.4
printer-info OPTIONAL Section 4.4.5
printer-more-info OPTIONAL Section 4.4.6
printer-make-and-model RECOMMENDED Section 4.4.8
charset-supported OPTIONAL Section 4.4.15
generated-natural-language-
supported OPTIONAL Section 4.4.17
document-format-supported RECOMMENDED Section 4.4.19
color-supported RECOMMENDED Section 4.4.23
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: Change History for the IPP Model and Semantics document ✨
okay so this is the receipts section 🧾 bestie, the IPP crew ran interop testing September 23-25 1998 and then kept debating on the mailing list and in meetings, and this is everything that came out of it 💅 Everything below is changes from the June 30, 1998 version, listed in the order they show up in the document. Only the changes that might affect implementations are listed. Tiny clarifications that probably won't touch anyone's code are left out 🌸
The issue numbers point at the IPP Issues List, which lives here: ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/ 🎀
Section Description
global Replaced TLS references with SSL3 references as agreed with
our Area Director on 11/12/1998.
global Removed the indications that some of these IPP documents
are informational, since the intent is now to publish all
IPP/1.0 documents as informational as agreed with our Area
Director on 11/12/1998.
3.1.2, Clarify that the IPP object SHOULD NOT validate the
16.3.3 range of the request-id being 1 to 2**31-1, but accepts
[now ipp- and returns any value. Clients MUST still keep in the
iig] range 1 to 2**31 though. If the request is terminated
before the complete "request-id" is received, the IPP
object rejects the request and returns a response with a
"request-id" of 0 (Issue 1.36).
3.1.4.1, Clarified that when a client submits a request in a
13.1.4.14 charset that is not supported, the IPP object SHOULD
return any 'text' or 'name' attributes in the 'utf-8'
charset, if it returns any, since clients and IPP
objects MUST support 'utf-8'. (Issue 1.19)
3.1.4.1 Clarified Section 3.1.4.1 Request Operation Attributes
that a client MAY use the attribute level natural
language override (text/nameWithLanguage) redundantly in
a request. (Issue 1.46)
3.1.4.2 Clarified Section 3.1.4.2 Response Operation Attributes
that an IPP object MAY use the attribute level natural
language override (text/nameWithLanguage) redundantly in
a response. (Issue 1.46)
3.1.6 Clarified section 3.1.6: If the Printer object supports
the "status-message" operation attribute, it NEED NOT
return a status message for the following error status
codes: 'client-error-bad-request', 'client-error-
charset-not-supported', 'server-error-internal-error',
'server-error-operation-not-supported', and 'server-
error-version-not-supported'.
3.2.1.1 Clarified that if a client is not supplying any Job
Template attributes in a request, the client SHOULD omit
Group 2 rather than sending an empty group. However, a
Printer object MUST be able to accept an empty group.
This makes [RFC2566] agree with [RFC2565]. (Issue 1.16)
3.2.1.2, Clarified that if an IPP object is not returning any
3.2.5.2, Unsupported Attributes in a response, the IPP object
3.2.6.2, SHOULD omit Group 2 rather than sending an empty group.
3.3.1.2, However, a client MUST be able to accept an empty group.
3.3.3.2, This makes [RFC2566] agree with [RFC2565]. (Issue 1.17)
3.3.4.2
3.2.1.2, Clarified that an IPP object MUST treat an unsupported
13.1.2.2, attribute syntax supplied in a request in the same way
13.1.4.12 as an unsupported value. The IPP object MUST return the
attribute, the attribute syntax, and the value in the
Unsupported Attributes group. (Issue 1.26)
3.2.5.2, Clarified for Get-Printer-Attributes, Get-Jobs, and Get-
3.2.6.2, Job-Attributes that an IPP object MUST return
3.3.4.2, 'successful-ok-ignored-or-substituted-attributes' (0x1),
13.1.2.1, rather than 'successful-ok' (0x0), when a client
13.1.2.2, supplies unsupported attributes as values of the
13.1.4.12 'requested-attributes' operation attribute. (Issue
1.24)
Also clarified that 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.
(Issue 1.18)
3.2.6.2 Deleted the job-level natural language override (NLO)
4.1.1.2 from Section 3.2.6.2 Get-Jobs Response so that all
4.3.24 operation responses are the same with respect to NLO.
(Issue 1.47)
3.3.1 Clarified that an IPP Printer that supports the Create-
Job operation MUST handle the situation when a client
does not supply Send-Document or Send-URI operations
within a one- to four-minute time period. Also
clarified that a client MUST send documents in a multi-
document job without undue or unbounded delay. (Issue
1.28)
3.3.3 Clarified that the IPP object MUST reject a Cancel-Job
request if the job is in 'completed', 'canceled', or
'aborted' job states. (Issue 1.12)
4.1.2.3 Added this new sub-section: it specifies that
nameWithoutLanguage plus the implicit natural language
matches nameWithLanguage, if the values and natural
languages are the same. Also added that keyword never
matches nameWithLanguage or nameWithoutLanguage.
Clarified that if both have countries, that the
countries SHOULD match as well. If either do not, then
the country field SHOULD be ignored. (Issues 1.33 and
1.34)
4.1.5 Clarified regarding the case-insensitivity of URLs to
refer only to the RFCs that define them. (Issue 1.10)
4.1.11 Clarified that 'boolean' is not a full-sized integer.
(Issue 1.38)
4.1.15 Clarified that 'resolution' is not three full-sized
integers. (Issue 1.20)
4.2.* Clarified that standard values are keywords or enums,
not names. (Issue 1.49).
4.2.4 Added the 'single-document-new-sheet' value to Section
4.2.4 multiple-document-handling. (Issue 1.54)
4.4.18, Clarified that the "document-format-default" and
4.4.19 "document-format-supported" Printer Description
attributes are REQUIRED to agree with the table. (Issue
1.4)
4.4.21 Changed "queued-job-count" from OPTIONAL to RECOMMENDED.
(Issue 1.14)
4.4.28 Clarified that the implementation supplied value for the
"multiple-operation-time-out" attribute SHOULD be
between 30 and 240 seconds, though the implementation
MAY allow the administrator to set values, and MAY allow
values outside this range. (Issue 1.28)
5.1, Clarified Client Conformance that if a client supports
5.2.5 an attribute of 'text' attribute syntax, that it MUST
support both the textWithoutLanguage and the
textWithLanguage forms. Same for 'name' attribute
syntax. Same for an IPP object (Issue 1.48)
6.5, Added new section to allow Attribute Groups to be
12.8 registered as extensions for being passed in operation
requests and responses. (Issue 1.25)
7. Updated the table of text and name attributes to agree
with Section 4.2.
8.5 Added a new section RECOMMENDING that the Get-Jobs
SHOULD return non-IPP jobs whether or not assigning them
a job-id and job-uri. Also RECOMMENDED generating, if
possible, job-id and job-uri and supporting other IPP
operations on foreign jobs as an implementer option.
(Issue 1.32)
9. Updated document references.
13.1.4.14 Clarified 'client-error-charset-not-supported' that
'utf-8' must be used for any 'text' or 'name' attributes
returned in the error response (Issue 1.19).
13.1.5.9 Added a new error code 'server-error-job-canceled'
(0x0508) to be returned if a job is canceled by another
client or aborted by the IPP object while the first
client is still sending the document data. (Issue 1.29)
15.3, Moved these sections recommending operation processing
15.4 steps to the new Implementer's Guide (informational).
There indicated that all of the error checks are not
required, so an IPP object MAY be forgiving and accept
non-conforming requests. However, a conforming client
MUST supply requests that would pass all of the error
checks indicated. (Issue 1.21)
16 Changed directory schema attributes from REQUIRED to
RECOMMENDED. Changed some of the OPTIONAL to
RECOMMENDED to agree with the SLP template. Changed the
"charset-supported" and "natural-language-supported"
from REQUIRED to OPTIONAL. Recommended that the names
be the same in a directory entry as the IPP attribute
names. (Issue 1.53)18. Full Copyright Statement 🎀
ok and last but definitely not least, the legal bit 🙈 I'm keeping this one word-for-word so nothing gets twisted, because copyright text is serious business 💜
Copyright (C) The Internet Society (1999). 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.📦 where this page comes from
- ietf: rfc2566 1999-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms