RFC 3196
Internet Printing Protocol/1.1: Implementor's Guide
Internet Printing Protocol/1.1: Implementor's Guide 🖨️✨
Okay bestie, here's the title block tea ☕. This is RFC 3196, from the Network Working Group, and it's Informational (so it's guidance, not a standard 💅). It was published in November 2001. It's written by five people from three companies:
- T. Hastings, C. Manros, and P. Zehler from Xerox Corporation
- C. Kugler from IBM Printing Systems Co
- H. Holst from i-data Printing Systems
It obsoletes RFC 2639 🦋, so this one replaces that older doc. The original title block doesn't list anything it updates, so I'm not adding anything there 🙈.
Status of this Memo 📜
Lowkey the most important vibe check: this memo is for information for the Internet community 💜. It is not an Internet standard of any kind, so don't treat it like one 🫶. Distribution is totally unlimited, so share it with everyone 🌸.
Copyright Notice ©️
The Internet Society owns the copyright here, and it's (C) The Internet Society (2001). All Rights Reserved. 💖
Abstract ✨
This doc is one piece of a whole set 🧚. Together, the set describes every single part of the new Internet Printing Protocol (IPP) 🖨️🎀.
Table of Contents 🗺️
Here's the full map, copied exactly so you can find your way around 💅:
Network Working Group T. Hastings
Request for Comments: 3196 C. Manros
Obsoletes: 2639 P. Zehler
Category: Informational Xerox Corporation
C. Kugler
IBM Printing Systems Co
H. Holst
i-data Printing Systems
November 2001 1 Introduction................................................... 4
1.1 Conformance language........................................ 5
1.2 Other terminology........................................... 6
1.3 Issues Raised from Interoperability Testing Events.......... 6
2 IPP Objects.................................................... 6
3 IPP Operations................................................. 7
3.1 Common Semantics............................................ 7
3.1.1 Summary of Operation Attributes............................ 8
3.1.2 Suggested Operation Processing Steps for IPP Objects....... 16
3.1.2.1 Suggested Operation Processing Steps for all Operations. 17
3.1.2.1.1 Validate version number............................... 18
3.1.2.1.2 Validate operation identifier......................... 20
3.1.2.1.3 Validate the request identifier....................... 20
3.1.2.1.4 Validate attribute group and attribute presence and
order................................................. 20
3.1.2.1.4.1 Validate the presence and order of attribute groups. 20
3.1.2.1.4.2 Ignore unknown attribute groups in the expected
position............................................ 21
3.1.2.1.4.3 Validate the presence of a single occurrence of
required Operation attributes....................... 21
3.1.2.1.5 Validate the values of the REQUIRED Operation
attributes............................................ 29
3.1.2.1.6 Validate the values of the OPTIONAL Operation
attributes............................................ 33
3.1.2.2 Suggested Additional Processing Steps for Operations
that Create/Validate Jobs and Add Documents............. 37
3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...... 37
3.1.2.2.2 Check that the Printer object is accepting jobs....... 38
3.1.2.2.3 Validate the values of the Job Template attributes.... 38
3.1.2.3 Algorithm for job validation............................ 39
3.1.2.3.1 Check for conflicting Job Template attributes values.. 45
3.1.2.3.2 Decide whether to REJECT the request.................. 46
3.1.2.3.3 For the Validate-Job operation, RETURN one of the
success status codes.................................. 48
3.1.2.3.4 Create the Job object with attributes to support...... 48
3.1.2.3.5 Return one of the success status codes................ 50
3.1.2.3.6 Accept appended Document Content...................... 50
3.1.2.3.7 Scheduling and Starting to Process the Job............ 50
3.1.2.3.8 Completing the Job.................................... 50
3.1.2.3.9 Destroying the Job after completion................... 51
3.1.2.3.10 Interaction with "ipp-attribute-fidelity"............. 51
3.1.2.3.11 Character set code conversion support................. 51
3.1.2.3.12 What charset to return when an unsupported charset is
requested (Issue 1.19)?....... ....................... 52
3.1.2.3.13 Natural Language Override (NLO)....................... 53
3.1.3 Status codes returned by operation......................... 55
3.1.3.1 Printer Operations...................................... 55
3.1.3.1.1 Print-Job............................................. 55
3.1.3.1.2 Print-URI............................................. 58
3.1.3.1.3 Validate-Job.......................................... 58
3.1.3.1.4 Create-Job............................................ 58
3.1.3.1.5 Get-Printer-Attributes................................ 59
3.1.3.1.6 Get-Jobs.............................................. 60
3.1.3.1.7 Pause-Printer......................................... 61
3.1.3.1.8 Resume-Printer........................................ 62
3.1.3.1.8.1 What about Printers unable to change state due to
an error condition?................................. 63
3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?... 63
3.1.3.1.9 Purge-Printer......................................... 63
3.1.3.2 Job Operations.......................................... 64
3.1.3.2.1 Send-Document......................................... 64
3.1.3.2.2 Send-URI.............................................. 65
3.1.3.2.3 Cancel-Job............................................ 65
3.1.3.2.4 Get-Job-Attributes.................................... 67
3.1.3.2.5 Hold-Job.............................................. 68
3.1.3.2.6 Release-Job........................................... 69
3.1.3.2.7 Restart-Job........................................... 69
3.1.3.2.7.1 Can documents be added to a restarted job?.......... 69
3.1.4 Returning unsupported attributes in Get-Xxxx responses
(Issue 1.18)............................................... 70
3.1.5 Sending empty attribute groups............................. 70
3.2 Printer Operations.......................................... 71
3.2.1 Print-Job operation........................................ 71
3.2.1.1 Flow controlling the data portion of a Print-Job
request (Issue 1.22).................................... 71
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30).. 71
3.2.2 Get-Printer-Attributes operation........................... 72
3.2.3 Get-Jobs operation......................................... 72
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name'
(Issue 1.39)?.......................................... 72
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs
operation?.............................................. 73
3.2.4 Create-Job operation....................................... 73
3.3 Job Operations.............................................. 74
3.3.1 Validate-Job............................................... 74
3.3.2 Restart-Job................................................ 74
4 Object Attributes.............................................. 74
4.1 Attribute Syntax's.......................................... 74
4.1.1 The 'none' value for empty sets (Issue 1.37)............... 74
4.1.2 Multi-valued attributes (Issue 1.31)....................... 75
4.1.3 Case Sensitivity in URIs (issue 1.6)....................... 75
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
4.2 Job Template Attributes..................................... 76
4.2.1 multiple-document-handling(type2 keyword).................. 76
4.2.1.1 Support of multiple document jobs....................... 76
4.3 Job Description Attributes.................................. 76
4.3.1 Getting the date and time of day........................... 76
4.4 Printer Description Attributes.............................. 77
4.4.1 queued-job-count (integer(0:MAX)).......................... 77
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
4.4.1.2 Is "queued-job-count" a good measure of how busy a
printer is (Issue 1.15)?................................ 77
4.4.2 printer-current-time (dateTime)............................ 78
4.4.3 Printer-uri................................................ 78
4.5 Empty Jobs.................................................. 79
5 Directory Considerations....................................... 79
5.1 General Directory Schema Considerations..................... 79
5.2 IPP Printer with a DNS name................................. 79
6 Security Considerations........................................ 80
6.1 Querying jobs with IPP that were submitted using other job
submission protocols (Issue 1.32)........................... 80
7 Encoding and Transport......................................... 81
7.1 General Headers............................................. 83
7.2 Request Headers............................................ 84
7.3 Response Headers............................................ 86
7.4 Entity Headers............................................. 87
7.5 Optional support for HTTP/1.0............................... 88
7.6 HTTP/1.1 Chunking........................................... 88
7.6.1 Disabling IPP Server Response Chunking..................... 88
7.6.2 Warning About the Support of Chunked Requests.............. 88
8 References..................................................... 89
9 Authors' Addresses............................................. 91
10 Description of the Base IPP Documents.......................... 94
11 Full Copyright Statement....................................... 96Tables 📊
Table 1 - Summary of Printer operation attributes that sender MUST
supply ................................................. 8
Table 2 - Summary of Printer operation attributes that sender MAY
supply ................................................. 10
Table 3 - Summary of Job operation attributes that sender MUST
supply.................................................. 12
Table 4 - Summary of Job operation attributes that sender MAY
supply.................................................. 14
Table 5 - Printer operation response attributes................... 16
Table 6 - Examples of validating IPP version...................... 19
Table 7 - Rules for validating single values X against Z.......... 40Part 1 of 17 is done, so there's more to come 👑. Stay tuned for Section 1 and the rest of the IPP goodness 💅🌈.
1. Introduction ✨
Okay so, IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies 🖨️💖 This document is a supplement to the IPP Model and Semantics [RFC2911] and the IPP Transport and Encoding [RFC2910] docs. It's meant to help implementers understand IPP/1.1, plus IPP/1.0 [RFC2565, RFC2566], and some of the things to think about when designing a client and/or IPP object implementation 🎀 For example, a typical order of processing requests is given, including error checking. The motivation behind some of the spec decisions is in here too 💅
This document obsoletes RFC 2639, which was the Implementor's Guide for IPP/1.0. The IPP Implementor's Guide (IIG) (this document) contains information that supplements the IPP Model and Semantics [RFC2911] and the IPP Transport and Encoding [RFC2910] documents. This document is just one of a suite of documents that fully define IPP. The base 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.1: Model and Semantics [RFC2911]
- Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
- Internet Printing Protocol/1.1: Implementor's Guide (this document)
- Mapping between LPD and IPP Protocols [RFC2569]
See section 10 for a description of these base IPP documents. Anyone reading these documents for the first time is strongly encouraged to read the IPP documents in the above order 📚
So the info in this doc is not part of the formal specification of IPP/1.1 🙃 It's here to help implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565, RFC2566], including some of the motivation behind the decisions the committee made. Some of the implementation considerations are meant to help you design your client and/or IPP object implementations. If there are any contradictions between this document and [RFC2911] or [RFC2910], those documents take precedence over this document 👑
Platform-specific implementation considerations will be added to this guide as they become known 🌸
Note: So you can cross-reference easily, the sections in this document line up with the matching sections in the IPP Model and Semantics document and are numbered the same way. The sections that match the IPP Transport and Encoding document are offset to match it 🦋
1.1. Conformance language
Usually, this document does not contain the terminology MUST, MUST NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. However, when those terms do appear, their intent is to repeat what [RFC2911] and [RFC2910] require and allow, rather than adding any new conformance requirements. These terms are defined in section 12 on conformance terminology in [RFC2911], most of which is taken from RFC 2119 [RFC2119].
Implementers should read section 12 (APPENDIX A) in [RFC2911] to understand these capitalized words. The words MUST, MUST NOT, and REQUIRED indicate what implementations are required to support in a client or IPP object in order to be conformant to [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate what is merely allowed as an implementer option. The verbs SHOULD and SHOULD NOT indicate suggested behavior, but which is not required or disallowed, respectively, in order to conform to the specification 🫶
1.2. Other terminology
This document uses other terms, such as "attributes", "operation", and "Printer", as defined in [RFC2911] section 12. In addition, the term "sender" refers to the client that sends a request or an IPP object that returns a response. The term "receiver" refers to the IPP object that receives a request and to a client that receives a response 💜
1.3. Issues Raised from Interoperability Testing Events
The IPP WG has conducted three open Interoperability Testing Events. The first one was held in September 1998, the second one was held in March 1999, and the third one was held in October 2000. See the summary reports in:
ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
The issues raised from the first Interoperability Testing Event are numbered 1.n in this document and have been incorporated into "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and Transport" [RFC2565] documents. However, some of the discussion is left here in the Implementor's Guide to help understanding 🧚
The issues raised from the second Interoperability Testing Event are numbered 2.n in this document and have been incorporated into "IPP/1.1 Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and Transport" [RFC2910] documents. However, some of the discussion is left here in the Implementor's Guide to help understanding 🍓
The issues raised from the third Interoperability Testing Event are numbered 3.n in this document and are described in:
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.pdfftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.docftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt
2. IPP Objects 🎀
The term "client" in IPP is intended to mean any client that issues IPP operation requests and accepts IPP operation responses, whether it be a desktop or a server. In other words, the term "client" doesn't just mean end-user clients, like the ones associated with desktops 💖
The term "IPP Printer" in IPP is intended to mean an object that accepts IPP operation requests and returns IPP operation responses, whether it's implemented in a server or a device. An IPP Printer object MAY, if implemented in a server, turn around and forward received jobs (and other requests) to other devices and print servers/services, either using IPP or some other protocol 🦋
3. IPP Operations 💅
This section corresponds to Section 3 "IPP Operations" in the IPP/1.1 Model and Semantics document [RFC2911].
3.1. Common Semantics
This section discusses semantics common to all operations ✨
3.1.1. Summary of Operation Attributes
Okay, here's the big table bestie, and it's giving everything 🔥 It lays out which operation parameters and attributes the sender MUST supply.
Table 1 - Summary of Printer operation attributes that sender MUST supply
Printer Operations
Requests Responses
Operation PJ, PU CJ GPA GJ PP, All
Attributes VJ (O) (O) (R) (R) RP, Operations
(R) PP
(O+)
Operation parameters--REQUIRED to be supplied by the sender:
operation-id R R R R R R
status-code R
request-id R R R R R R R
version-number R R R R R R R
Operation attributes--REQUIRED to be supplied by the sender:
attributes- R R R R R R R
charset
attributes- R R R R R R R
natural-
language
document-uri R
job-id*
job-uri*
Printer Operations
Requests Responses
Operation PJ, PU CJ GPA GJ PP, All
Attributes VJ (O) (O) (R) (R) RP, Operations
(R) PP
(O+)
last-document
printer-uri R R R R R R
Operation attributes--RECOMMENDED to be supplied by the
sender:
job-name R R R
requesting-user- R R R R R R
name
Legend:
PJ, VJ: Print-Job, Validate-Job
PU: Print-URI
CJ: Create-Job
GPA: Get-Printer-Attributes
GJ: Get-Jobs
PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.Table 2 - Summary of Printer operation attributes that sender MAY supply 🌈
Printer Operations
Requests Respon-
ses
Operation Attributes PJ, PU CJ GPA GJ PP, All
VJ (O) (O) (R) (R) RP, Opera
(R) PP tions
(O+)
Operation attributes--OPTIONAL to be supplied by the sender:
status-message O
detailed-status- O
message
document-access- O**
error
compression R R
document-format R R R
document-name O O
document-natural- O O
language
ipp-attribute- R R R
fidelity
job-impressions O O O
job-k-octets O O O
job-media-sheets O O O
Printer Operations
Requests Respon-
ses
Operation Attributes PJ, PU CJ GPA GJ PP, All
VJ (O) (O) (R) (R) RP, Opera
(R) PP tions
(O+)
limit R
message
my-jobs R
requested-attributes R R
which-jobs R
Legend:
PJ, VJ: Print-Job, Validate-Job
PU: Print-URI
CJ: Create-Job
GPA: Get-Printer-Attributes
GJ: Get-Jobs
PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.
* "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED.
** "document-access-error" applies to the Print-URI response only.Table 3 - Summary of Job operation attributes that sender MUST supply 💜
Okay so the attribute tables are next, and they're giving main character energy 💅🎀 Let's go!
Job Operations
Requests Responses
Operation SD SU CJ GJA HJ All
Attributes (O) (O) (R) (R) RJ, RJ Opera-
(O+) tions
Operation parameters--REQUIRED to be supplied by the sender:
operation-id R R R R R
status-code R
request-id R R R R R R
version-number R R R R R R
Operation attributes--REQUIRED to be supplied by the sender:
attributes-charset R R R R R R
attributes-natural- R R R R R R
language
document-uri R
job-id* R R R R R
job-uri* R R R R R
last-document R R
printer-uri R R R R R
Operation attributes--RECOMMENDED to be supplied by the sender:
job-nameJob Operations
Requests Responses
Operation SD SU CJ GJA HJ All
Attributes (O) (O) (R) (R) RJ, RJ Opera-
(O+) tions
requesting-user- R R R R R
name
Legend:
SD: Send-Document
SU: Send-URI
CJ: Cancel-Job
GJA: Get-Job-Attributes
HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.
* "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED.Table 4 - Summary of Job operation attributes that sender MAY supply
Job Operations
Requests Responses
Operation SD SU CJ GJA HJ, SD All
Attributes (O) (O) (R) (R) RJ, (O) Opera-
RJ tions
(O+)
Operation attributes--OPTIONAL to be supplied by the sender:
status-message O
detailed-status- O
message
document-access- O**
error
compression R R
document-format R R
document-name O O
document-natural- O O
language
ipp-attribute-
fidelity
job-impressions
job-k-octets
job-media-sheetsJob Operations
Requests Responses
Operation SD SU CJ GJA HJ, SD All
Attributes (O) (O) (R) (R) RJ, (O) Opera-
RJ tions
(O+)
limit
message O O O
job-hold-until R
my-jobs
requested- R
attributes
which-jobs
Legend:
SD: Send-Document
SU: Send-URI
CJ: Cancel-Job
GJA: Get-Job-Attributes
HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).
+ indicates that this is not an IPP/1.0 feature, but is only a part
of IPP/1.1 and future versions of IPP.
* "job-id" is REQUIRED only if used together with "printer-uri" to
identify the target job; otherwise, "job-uri" is REQUIRED.
** "document-access-error" applies to the Send-URI operation onlyTable 5 - Printer operation response attributes
Printer Operations
Response
Operation PJ (R) VJ (R) PU (O) CJ (O) GPA GJ (R) PP,
Attributes SD (O) SU (O) (R) RP, PP
(O+)
job-uri R R R
job-id R R R
job-state R R R
job-state- R+ R+ R+
reasons
number-of- O O O
intervening-
jobs
document- O
access-
error+
Legend:
PJ, SJ: Print-Job, Send-Document
VJ: Validate-Job
PU, SU: Print-URI, Send-URI
CJ: Create-Job
GPA: Get-Printer-Attributes
GJ: Get-Jobs
PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
R indicates a REQUIRED operation that MUST be supported by the IPP
object (Printer or Job). For attributes, R indicates that the
attribute MUST be supported by the IPP object that supports the
associated operation.
O indicates an OPTIONAL operation or attribute that MAY be supported
by the IPP object (Printer or Job).3.1.2 Suggested Operation Processing Steps for IPP Objects ✨
This bit suggests the steps and error checks an IPP object MAY run when it handles requests and sends back responses. An IPP object MAY do some or all of the error checks 🙈 Some implementations MAY choose to be more forgiving than the checks listed here, so they can accept requests from clients that aren't conforming. Skipping some of these checks is what we call a "forgiving" implementation. On the other hand, clients whose requests work on IPP objects that do every single check are way more likely to interoperate with other IPP object implementations 💖 So an implementer has to decide whether they're going "forgiving" or "strict". That also means the error status codes returned may differ between implementations. Consequently, a client SHOULD NOT expect exactly the error code processing described in this section.
When an IPP object gets a request, it either accepts or rejects it. To decide which one, the IPP object SHOULD go through the following steps. The order of the steps may be rearranged and/or combined, including making one or multiple passes over the request.
A client MUST supply requests that would pass all of the error checks indicated here if it wants to be a conforming client. So a client SHOULD supply conforming requests, to avoid getting rejected by some IPP object implementations and to avoid risking different semantics across forgiving implementations 😭 For example, a forgiving implementation that accepts multiple occurrences of the same attribute, rather than rejecting the request, might use the first occurrence, while another might use the last one. That means a non-conforming client would get different results from the two forgiving implementations, which is a total mess 💀
In the following, processing continues step by step until a "RETURNS the xxx status code ..." statement is encountered. Error returns are indicated by the verb "REJECTS". Clients have a hard time getting the status code before they've sent all of the document data in a Print-Job request, so clients SHOULD use the Validate-Job operation before sending large documents to be printed. That way they can check whether the IPP Printer will accept the job or not 🦋
It is assumed that security authentication and authorization has already taken place at a lower layer. 🔐
IIG Sect # Flow IPP error status codes
---------- ---- ----------------------
|
v err
3.1.2.1.1 <Validate version> --> server-error-version-not-
supported
ok|
v err
3.1.2.1.2 <Validate operation> --> server-error-operation-not-
supported
ok|
v err
3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
3.1.2.1.4.2 <of attributes>
ok|
v err
3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
<of operation attr>
ok|
v err
3.1.2.1.5 <Validate values of> --> client-error-bad-request
<operation attrs> client-error-request-value-
too-long
<(length, tag, range,>
<multi-value)>
ok|
v err
3.1.2.1.5 <Validate values> --> client-error-bad-request
<with supported values> client-error-charset-not-
supported
ok| client-error-attributes-or-
values-
| not-supported
v err
3.1.2.1.6 <Validate optionally> --> client-error-bad-request
<operation attr> client-error-natural-language-
not-supported
| client-error-request-value-
| too-long
| client-error-attributes-or-
values-not-supported3.1.2.1 Suggested Operation Processing Steps for all Operations 🧚
This section is meant to cover every operation. The next section has the extra steps for the Print-Job, Validate-Job, Print-URI, Create-Job, Send-Document, and Send-URI operations, which are the ones that create jobs, add documents, and validate jobs 🍓
3.1.2.1.1 Validate version number
Every request and every response has the version-number attribute 🌈 Its value is the major and minor version number of the syntax and semantics that the client and the IPP object are using, respectively. The version-number attribute stays in a fixed position across all future versions, so every client and IPP object that supports future versions can figure out which version is being used 👑 The IPP object checks whether the major version number in the request is supported. If it isn't, the Printer object REJECTS the request and RETURNS the 'server-error-version-not-supported' status code in the response. The IPP object puts the major and minor version for the error response into the version-number response attribute, so the client can learn at least one major and minor version that the IPP object supports. The IPP object is encouraged to return the version number closest to the one the client supplied, which is honestly such a thoughtful move ✨
okay so the minor version check is totally up to each implementation 💅 but here's the lowkey strict part: if the client's minor version is one the IPP object explicitly supports, it MUST reply with that identical minor version number 🎀. If the major version number matches but the minor one doesn't, the Printer SHOULD accept and try to process the request, or it MAY reject the request and return the 'server-error-version-not-supported' status code 💀. Either way, the Printer MUST return the nearest version number it supports ✨ For example, say an IPP/1.2 Printer supports versions '1.1' and '1.2'. These responses are conforming 🦋
Table 6 - Examples of validating IPP version
Client supplies Printer Accept Request? Printer returns
1.0 yes (SHOULD) 1.1
1.0 no (SHOULD NOT) 1.1
1.1 yes (MUST) 1.1
1.2 yes (MUST) 1.2
1.3 yes (SHOULD) 1.2
1.3 no (SHOULD NOT) 1.2It's advantageous for Printers to support both IPP/1.1 and IPP/1.0 🌸 so they can interoperate with either client implementations. Some implementations may allow an Administrator to explicitly disable support for one or the other by setting the "ipp-versions-supported" Printer description attribute 🔥
Likewise, it's advantageous for clients to support both versions so they can interoperate with new and legacy Printers 🫶
3.1.2.1.2 Validate operation identifier
okay so the Printer object checks whether the "operation-id" attribute from the client is supported, as listed in the Printer object's "operations-supported" attribute 👀 if it's not, the Printer REJECTS the request and returns the 'server-error-operation-not-supported' status code in the response 💀
3.1.2.1.3 Validate the request identifier
the Printer object SHOULD NOT check whether the "request-id" attribute from the client is in range (between 1 and 2**31 - 1, inclusive) 🙈 it just copies all 32 bits, no drama ✨
Note: the "version-number", "operation-id", and the "request-id" parameters live in fixed octet positions in the IPP/1.1 encoding 🧚 the "version-number" parameter is in that same fixed octet position in all versions of the protocol 🍓 these fields get validated before anything else in the validation happens 💖
3.1.2.1.4 Validate attribute group and attribute presence and order
the order of the following validation steps depends on the implementation, so no fixed script here 🌈
3.1.2.1.4.1 Validate the presence and order of attribute groups
client requests and IPP object responses contain attribute groups that Section 3 requires to be present, in a specified order 📋 an IPP object checks that the attribute groups are there and in the right order in requests from clients (attribute groups without an * in the following tables) 🎀
If an IPP object gets a request with (1) required attribute groups missing, (2) attribute groups out of order, or (3) groups repeated, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code 💀 for example, it's an error for the Job Template Attributes group to come before the Operation Attributes group, for the Operation Attributes group to be omitted, or for an attribute group to show up more than once, except in the Get-Jobs response 🙅♀️
since this kind of attribute group error is most likely to be caught by a client developer rather than a customer 🧑💻, the IPP object NEED NOT return an indication of which attribute group was in error, either in the Unsupported Attributes group or the Status Message 🙈 also, the IPP object NEED NOT find all attribute group errors before returning this error 💅
3.1.2.1.4.2 Ignore unknown attribute groups in the expected position
future attribute groups may be added to the spec at the end of requests, right before the Document Content, and at the end of responses 🔮 except for the Get-Jobs response, where the group may be there or before the first job attributes returned 🍓 if an IPP object gets an unknown attribute group in these positions, it ignores the entire group instead of throwing an error 🙌 that's because the group might be new in a later minor version of the protocol and totally safe to ignore 🦋 (if a new attribute group can't be ignored without confusing the client, the major version number would have been increased in the protocol document and in the request 💀) if the unknown group shows up in a different position, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code 🚫
Clients also ignore unknown attribute groups returned in a response ✨
Note: by validating that requests are in the proper form, IPP objects force clients to use the proper form 🎀 which, in turn, makes it more likely that customers can use those clients from multiple vendors with IPP objects from other vendors 👑
3.1.2.1.4.3 Validate the presence of a single occurrence of required Operation attributes
client requests and IPP object responses contain Operation attributes that [RFC2911] Section 3 requires to be present 📦 attributes within a group can be in any order, except for the ordering of target, charset, and natural languages attributes 🌸 those MUST be first, and MUST be supplied in this order: charset, natural language, and then target 💜 an IPP object checks that the attributes Section 4 requires the client to supply were actually supplied in the request (attributes without an * in the following tables) 🔍 an asterisk (*) marks groups and Operation attributes that the client may leave out of a request, or that an IPP object may leave out of a response 🫧
if an IPP object receives a request with required attributes missing, repeated from a group, or in the wrong position, the behaviour of the IPP object is IMPLEMENTATION DEPENDENT 🤷♀️ some of the possible implementations are:
- REJECTS the request and RETURNS the 'client-error-bad-request' status code
- accepts the request and uses the first occurrence of the attribute no matter where it is
- accepts the request and uses the last occurrence of the attribute no matter where it is
- accept the request and assume some default value for the missing attribute
so, the client MUST send conforming requests if it wants to get the same behaviour from all IPP object implementations 💅 for example, it's an error for the "attributes-charset" or "attributes-natural-language" attribute to be omitted in any operation request, or for an Operation attribute to be supplied in a Job Template group, or a Job Template attribute to be supplied in an Operation Attribute group in a create request 😭 it's also an error to supply the "attributes-charset" attribute twice 💀
since these kinds of attribute errors are most likely to be caught by a client developer rather than a customer 🧑💻, the IPP object NEED NOT return an indication of which attribute was in error, either in the Unsupported Attributes group or the Status Message 🙈 also, the IPP object NEED NOT find all attribute errors before returning this error 💅
the tables below list all the attributes for all the operations, by attribute group, in each request and each response 📊 the order of the groups is the order the client supplies them, as specified in [RFC2911] Section 3 🎀 the order of attributes within a group is arbitrary, except for the special operation attributes (charset, natural language, and target) 🦋 the tables use this notation:
R indicates a REQUIRED attribute or operation that an IPP
object MUST support
O indicates an OPTIONAL attribute or operation that an IPP
object NEED NOT support
* indicates that a client MAY omit the attribute in a request
and that an IPP object MAY omit the attribute in a response.
The absence of an * means that a client MUST supply the
attribute in a request and an IPP object MUST supply the
attribute in a response.
+ indicates that this is not a IPP/1.0 operation, but is only
a part of IPP/1.1 and future versions of IPP.Operation Requests
the tables below show the attributes in their proper attribute groups for operation requests 🍃
Note: all operation requests contain "version-number", "operation-id", and "request-id" parameters ✨
Print-Job Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [RFC2911] Section 4.2)
Group 3: Document Content (R)
<document content>
Validate-Job Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [RFC2911] Section 4.2)
Print-URI Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
document-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [RFC2911] Section 4.2)
Create-Job Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [RFC2911] Section 4.2)
Get-Printer-Attributes Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
document-format (R*)
Get-Jobs Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
limit (R*)
requested-attributes (R*)
which-jobs (R*)
my-jobs (R*)The request tables wrap up first, then the response tables with their notes, and then we're into the validation rules.
Send-Document Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
Group 2: Document Content (R*)
<document content>
Send-URI Request (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
document-uri (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (R*)
Cancel-Job Request (R):
Release-Job Request (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
message (O*)
Get-Job-Attributes Request (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
Pause-Printer Request (O+):
Resume-Printer Request (O+):
Purge-Printer Request (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
Hold-Job Request (O+):
Restart-Job Request (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
job-hold-until (R*)
message (O*)Okay bestie, so those are all the request shapes, each one lined up with its groups so you can see exactly what goes where 💖 Now for the replies!
Operation Responses ✨
The tables below show where each response attribute sits inside its attribute group 🎀 And every single operation response carries "version-number", "status-code", and "request-id" parameters, no exceptions 💅
Print-Job Response (R):
Create-Job Response (O):
Send-Document Response (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
n <unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R)
job-id (R)
job-state (R)
job-state-reasons (O* | R+)
job-state-message (O*)
number-of-intervening-jobs (O*)
Validate-Job Response (R):
Cancel-Job Response (R):
Hold-Job Response (O+):
Release-Job Response (O+):
Restart-Job Response (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Print-URI Response (O):
Send-URI Response (O):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
document-access-error (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R)
job-id (R)
job-state (R)
job-state-reasons (O* | R+)
job-state-message (O*)
number-of-intervening-jobs (O*)
Get-Printer-Attributes Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Printer Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
Get-Jobs Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2, 5)
<requested attributes> (R*)
Get-Job-Attributes Response (R):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
Pause-Printer Response (O+):
Resume-Printer Response (O+):
Purge-Printer Response (O+):
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
detailed-status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)Now the notes, which are important so read them 👀
Note 2 🦋: the Job Object Attributes and Printer Object Attributes only come back if the IPP object returns one of the success status codes. No success, no object attributes, periodt.
Note 3 🌸: the Unsupported Attributes Group only shows up if the client sent some Operation and/or Job Template attributes or values that the Printer doesn't support, whether the answer is a success or an error.
Note 4 🧚: the Unsupported Attributes Group only shows up if the client sent some Operation attributes the Printer doesn't support, again whether it's a success or an error.
Note 5 💜: for Get-Jobs, the response has a separate Job Object Attributes group 3 to N, with the requested-attributes for each job object in the response. Iconic multi-group energy 👑
3.1.2.1.5 Validate the values of the REQUIRED Operation attributes ✨
An IPP object checks the values the client gives for the REQUIRED Operation attributes that the IPP object MUST support 🫶 The next section covers the validation of values for the OPTIONAL Operation attributes that IPP objects MAY support, so that's where the optional stuff lives 🌈
The IPP object runs these syntactic validation checks on each Operation attribute value:
- a) that the length of each Operation attribute value is correct for the attribute syntax tag supplied by the client according to [RFC2911] Section 4.1,
- b) that the attribute syntax tag is correct for that Operation attribute according to [RFC2911] Section 3,
- c) that the value is in the range specified for that Operation attribute according to [RFC2911] Section 3,
- d) that multiple values are supplied by the client only for operation attributes that are multi-valued, i.e., that are 1setOf X according to [RFC2911] Section 3.
If any of these checks fail, the IPP object REJECTS the request and RETURNS theclient-error-bad-requestor theclient-error-request-value-too-longstatus code. Since that error is most likely caused by a client developer rather than an end-user, the IPP object need not return an indication of which attribute had the error, either in the Unsupported Attributes Group or in the Status Message. The first IF statement in the table below explains each of these syntactic checks 🙈
On top of that, the IPP object checks each Operation attribute value against some Printer object attribute, or against a hard-coded value if there's no "xxx-supported" Printer object attribute defined 💅 If the value isn't among the supported values or isn't in the supported range, the IPP object REJECTS the request and RETURNS the error status code that the second IF statement in the table names. And if the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured one), the check always fails 💀
attributes-charset (charset)
IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "charset-supported" attribute,
REJECT/RETURN "client-error-charset-not-supported".
attributes-natural-language(naturalLanguage)
IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN
'client-error-request-value-too-long'.
ACCEPT the request even if not a member of the set in the Printer
object's "generated-natural-language-supported" attribute. If the
supplied value is not a member of the Printer object's
"generated-natural-language-supported" attribute, use the Printer
object's "natural-language- configured" value.
requesting-user-name
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF the IPP object can obtain a better-authenticated name, use it
instead.
job-name(name)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT supplied by the client, the Printer object creates a name
from the document-name or document-uri.
document-name (name)
IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
ipp-attribute-fidelity (boolean)
IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'.
IF the value length is NOT equal to 1 octet, REJECT/RETURN
'client-error-request-value-too-long'
IF NOT supplied by the client, the IPP object assumes the value
'false'.
document-format (mimeMediaType)
IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "document-format-supported"
attribute, REJECT/RETURN 'client-error-document-format-not-
supported'
IF NOT supplied by the client, the IPP object assumes the value of
the Printer object's "document-format-default" attribute.
document-uri (uri)
IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 1023 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
request'.
If the client-supplied URI scheme is not supported, i.e., the
value is 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. The Printer object MAY check to see if the document exists
and is accessible. If the document is not found or is not
accessible, REJECT/RETURN 'client-error-not found'.The last few request checks are all about making sure the Printer can trust what the client sends, so let's keep going 🎀
- IF NEITHER a single
trueNOR a singlefalsebooleanvalue, REJECT/RETURNclient-error-bad-request. 🙈 - IF the value length is NOT equal to 1 octet, REJECT/RETURN
client-error-request-value-too-long
job-id (integer(1:MAX)) is next, and it's giving strict 💅
- IF NOT a single
integervalue equal to 4 octets AND in the range 1 to MAX, REJECT/RETURNclient-error-bad-request. - IF NOT a job-id of an existing Job object, REJECT/RETURN
client-error-not-foundorclient-error-gonestatus code, if keep track of recently deleted jobs. 🦋
requested-attributes (1setOf keyword) is a list of keywords, so it's a little more chill but still picky:
- IF NOT one or more
keywordvalues, REJECT/RETURNclient-error-bad-request. - IF the value length is greater than 255 octets, REJECT/RETURN
client-error-request-value-too-long. - Ignore unsupported values, which are the keyword names of unsupported attributes. Don't bother to copy such requested (unsupported) attributes to the Unsupported Attribute response group since the response will not return them. ✨
which-jobs (type2 keyword) is where the filtering happens, and it only accepts two vibes:
- IF NOT a single
keywordvalue, REJECT/RETURNclient-error-bad-request. - IF the value length is greater than 255 octets, REJECT/RETURN
client-error-request-value-too-long. - IF NEITHER
completedNORnot-completed, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURNclient-error-attributes-or-values-not-supported. - Note: a Printer still supports the
completedvalue even if it keeps no completed/canceled/aborted jobs, by returning no jobs when so queried. 🫶 - IF NOT supplied by the client, the IPP object assumes the
not-completedvalue.
my-jobs (boolean) is a yes-or-no thing, so the same boolean rules apply:
- IF NEITHER a single
trueNOR a singlefalsebooleanvalue, REJECT/RETURNclient-error-bad-request. - IF the value length is NOT equal to 1 octet, REJECT/RETURN
client-error-request-value-too-long - IF NOT supplied by the client, the IPP object assumes the
falsevalue.
Last one, limit (integer(1:MAX)):
- IF NOT a single
integervalue equal to 4 octets AND in the range 1 to MAX, REJECT/RETURNclient-error-bad-request. - IF NOT supplied by the client, the IPP object returns all jobs, no matter how many. 🍓
3.1.2.1.6. Validate the values of the OPTIONAL Operation attributes 🌈
OPTIONAL Operation attributes are the ones an IPP object MAY support, so this is a bit of a choose-your-own-adventure. An IPP object validates the values of the OPTIONAL attributes the client sends, and it does the same syntactic checks for each OPTIONAL attribute value as it did in Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any of them fail, the IPP object REJECTS the request and RETURNS the client-error-bad-request or the client-error-request-value-too-long status code. 💜
Also, the IPP object checks each Operation attribute value against some Printer attribute, or against some hard-coded value if there is no "xxx-supported" Printer attribute defined. If its value is not among those supported or is not in the range supported, the IPP object REJECTS the request and RETURNS the error status code indicated in the table. If the value of the Printer object's "xxx-supported" attribute is no-value (because the system administrator hasn't configured a value), the check always fails. 🔥
If the IPP object doesn't recognize or support an attribute, it treats that attribute as an unknown or unsupported attribute (see the last row in the table below). 🦋
document-natural-language(naturalLanguage)- IF NOT a single non-empty
naturalLanguagevalue, REJECT/RETURNclient-error-bad-request. - IF the value length is greater than 63 octets, REJECT/RETURN
client-error-request-value-too-long. - IF NOT a value that the Printer object supports in document formats, (no corresponding "xxx-supported" Printer attribute), REJECT/RETURN
client-error-natural-language-not-supported.
- IF NOT a single non-empty
compression(type3 keyword)- IF NOT a single
keywordvalue, REJECT/RETURNclient-error-bad-request. - IF the value length is greater than 255 octets, REJECT/RETURN
client-error-request-value-too-long. - IF NOT in the Printer object's "compression-supported" attribute, REJECT/RETURN
client-error-compression-not-supported. - Note to IPP/1.0 implementers: Support for the "compression" attribute was optional in IPP/1.0 and was changed to REQUIRED in IPP/1.1. However, an IPP/1.0 object SHOULD at least check for the "compression" attribute being present and reject the create request, if they don't support "compression". Not checking is a bug, since the data will be unintelligible. 😭
- IF NOT a single
job-k-octets(integer(0:MAX))- IF NOT a single
integervalue equal to 4 octets, REJECT/RETURNclient-error-bad-request. - IF NOT in the range of the Printer object's "job-k-octets-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN
client-error-attributes-or-values-not-supported.
- IF NOT a single
job-impressions(integer(0:MAX))- IF NOT a single
integervalue equal to 4 octets, REJECT/RETURNclient-error-bad-request. - IF NOT in the range of the Printer object's "job-impressions-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN
client-error-attributes-or-values-not-supported.
- IF NOT a single
job-media-sheets(integer(0:MAX))- IF NOT a single
integervalue equal to 4 octets, REJECT/RETURNclient-error-bad-request. - IF NOT in the range of the Printer object's "job-media-sheets-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN
client-error-attributes-or-values-not-supported.
- IF NOT a single
message(text(127))- IF NOT a single
textvalue, REJECT/RETURNclient-error-bad-request. - IF the value length is greater than 127 octets, REJECT/RETURN
client-error-request-value-too-long.
- IF NOT a single
- unknown or unsupported attribute
- IF the attribute syntax supplied by the client is supported but the length is not legal for that attribute syntax, REJECT/RETURN
client-error-request-value-too-long. - ELSE copy the attribute and value to the Unsupported Attributes response group and change the attribute value to the "out-of-band"
unsupportedvalue, but otherwise ignore the attribute. 🌸
- IF the attribute syntax supplied by the client is supported but the length is not legal for that attribute syntax, REJECT/RETURN
Note: Future Operation attributes may be added to the protocol specification that may occur anywhere in the specified group. When the operation is otherwise successful, the IPP object returns the successful-ok-ignored-or-substituted-attributes status code. Ignoring unsupported Operation attributes in all operations is analogous to the handling of unsupported Job Template attributes in the create and Validate-Job operations when the client supplies the "ipp-attribute-fidelity" Operation attribute with the false value. This last rule is so that we can add OPTIONAL Operation attributes to future versions of IPP so that older clients can inter-work with new IPP objects and newer clients can inter-work with older IPP objects. (If the new attribute cannot be ignored without performing unexpectedly, the major version number would have been increased in the protocol document and in the request). This rule for Operation attributes is independent of the value of the "ipp-attribute-fidelity" attribute. For example, if an IPP object doesn't support the OPTIONAL "job-k-octets" attribute, the IPP object treats "job-k-octets" as an unknown attribute and only checks the length for the integer attribute syntax supplied by the client. If it is not four octets, the IPP object REJECTS the request and RETURNS the client-error-bad-request status code, else the IPP object copies the attribute to the Unsupported Attribute response group, setting the value to the "out-of-band" unsupported value, but otherwise ignores the attribute. this rule is literally designed so old and new versions can vibe together 🌈✨
3.1.2.2 Suggested Additional Processing Steps for Operations that Create/Validate Jobs and Add Documents ✨
Okay bestie, this section plus the last one is the full processing recipe for Print-Job, Validate-Job, Print-URI, Create-Job, Send-Document, and Send-URI 🖨️. These are the ops that make jobs, check a Print-Job request, and add documents to a job. IPP objects SHOULD use these steps 💅
IIG Sect # Flow IPP error status codes
---------- ---- ----------------------
|
v No
3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
<supplied?> |
Yes| |
| ipp-attribute-fidelity = no |
|<------------------------------+
v No
3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
<accepting jobs?>
Yes|
v err
3.1.2.3 <Validate values of> --> client-error-bad-request
<Job template attributes> client-error-request-value-too-
long
<(length, tag, range,>
<multi-value)>
ok|
v err
3.1.2.3 <Validate values with> --> client-error-bad-request
<supported values> client-error-attributes-or-
| values-not-supported
v err
3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
attributes
<Job Template attr values> client-error-attributes-or-
values-not-supported
v3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied 🫶
Okay so the Printer object checks whether the client sent an "ipp-attribute-fidelity" Operation attribute 👀. If the client didn't include it, the IPP object just assumes the value is 'false' 💖
3.1.2.2.2 Check that the Printer object is accepting jobs 🚪
If the value of the Printer objects "printer-is-accepting-jobs" is 'false', the Printer object REJECTS the request and RETURNS the 'server-error-not-accepting-jobs' status code 💀 Not the vibe, but at least it's clear.
3.1.2.2.3 Validate the values of the Job Template attributes 🔍
Next up, the IPP object validates the values of every Job Template attribute the client supplied 🧐 It runs the same kind of syntactic checks it runs on Operation attributes (see Section 3.1.2.1.5.), which means checking that:
- a) the length of each value is correct for the attribute syntax tag the client supplied, according to [RFC2911] Section 4.1.
- b) the attribute syntax tag is correct for that attribute, according to [RFC2911] Sections 4.2 to 4.4.
- c) multiple values only show up for multi-valued attributes, i.e., ones that are 1setOf X according to [RFC2911] Sections 4.2 to 4.4.
As in Section 3.1.2.1.5, if any of these syntactic checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or 'client-error-request-value-too-long' status code as appropriate, no matter what "ipp-attribute-fidelity" is set to 🙅♀️. Since this kind of error is most likely caught by a client developer rather than an end-user, the IPP object NEED NOT say which attribute caused the error in either the Unsupported Attributes Group or the Status Message 🤓 The description for each of these syntactic checks is spelled out in the first IF statement of the table below 📋
Each Job Template attribute MUST occur no more than once 🚫 If an IPP Printer gets a create request with multiple occurrences of a Job Template attribute, it MAY:
- reject the operation and return the
'client-error-bad-request'error status code - accept the operation and use the first occurrence of the attribute
- accept the operation and use the last occurrence of the attribute
Which one it picks depends on the implementation 🤷♀️ So, clients MUST NOT supply multiple occurrences of the same Job Template attribute in the Job Attributes group in the request. Don't make the Printer guess, bestie 🫠
3.1.2.3 Algorithm for job validation 🧮
Validating a Job-Template attribute "xxx" against a Printer attribute "xxx-supported" can use the following validation algorithm (see section 3.2.1.2 in [RFC2911]) ✨
To validate the value U of Job-Template attribute "xxx" against the value V of Printer "xxx-supported", you run this algorithm:
- If U is multi-valued, validate each value X of U by running the algorithm in Table 7 with each value X. Each validation is separate when it comes to returning unsupported values. Example: If U is "finishings" that the client supplies with 'staple', 'bind' values, then X takes on the successive values: 'staple', then 'bind'
- If V is multi-valued, validate X against each Z of V by running the algorithm in Table 7 with each value Z. If a value Z validates, the validation for the attribute value X succeeds. If it fails, the algorithm moves on to the next value Z of V. If there are no more values Z of V, validation fails. Example: If V is "sides-supported" with values: 'one-sided', 'two-sided-long', and 'two-sided-short', then Z takes on the successive values: 'one-sided', 'two-sided-long', and 'two-sided-short'. If the client supplies "sides" with 'two-sided-long', the first comparison fails ('one-sided' is not equal to 'two-sided-long'), the second comparison succeeds ('two-sided-long' is equal to 'two-sided-long'), and the third comparison ('two-sided-short' with 'two-sided-long') is not even performed 🏃♀️
- If both U and V are single-valued, let X be U and Z be V and use the validation rules in Table 7.
Table 7 - Rules for validating single values X against Z
Attribute syntax attribute syntax validated if:
of X of Z
integer rangeOfInteger X is within the range of Z
uri uriScheme the uri scheme in X is equal to
Z
any boolean the value of Z is TRUE
any any X and Z are of the same type
and are equal.If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails 😬 When a check fails, the IPP object copies the attribute to the Unsupported Attributes response group with its unsupported value. If the attribute has more than one value, each value gets checked and each unsupported value is copied separately, while supported values are NOT copied 🧹 If an IPP object doesn't recognize or support a Job Template attribute, meaning there is no matching Printer object "xxx-supported" attribute, the IPP object treats it as an unknown or unsupported attribute (see the last row in the table below) 👻
If some Job Template attributes are supported for some document formats and not others, or their values differ between document formats, the IPP object SHOULD take that into account during this validation, using the value of the "document-format" the client supplied (or the Printer's "document-format-default" attribute, if the client didn't supply one) 📄 For example, if "number-up" is supported for the 'text/plain' document format but not for 'application/postscript', the check SHOULD (though it NEED NOT) depend on the value of the "document-format" operation attribute. See "document-format" in [RFC2911] section 3.2.1.1 and 3.2.5.1 📚
Note: whether the request is accepted or rejected is decided by the value of the "ipp-attribute-fidelity" attribute in a later step, so every Job Template attribute the client supplies gets examined, and all unsupported attributes and/or values are copied to the Unsupported Attributes response group 🎀
Here are the per-attribute rules, bestie 👑
-----------------------------------------------
job-priority (integer(1:100))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, use the value of the Printer
object's "job-priority-default" attribute at job submission time.
IF NOT in the range 1 to 100, inclusive, copy the attribute and
the unsupported value to the Unsupported Attributes response
group.
Map the value to the nearest supported value in the range 1:100 as
specified by the number of discrete values indicated by the value
of the Printer's "job-priority-supported" attribute. See the
formula in [RFC2911] Section 4.2.1.
job-hold-until (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT supplied by the client, use the value of the Printer
object's "job-hold-until" attribute at job submission time.
IF NOT in the Printer object's "job-hold-until-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
job-sheets (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "job-sheets-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
multiple-document-handling (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "multiple-document-handling-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group.
copies (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in range of the Printer object's "copies-supported"
attribute
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
finishings (1setOf type2 enum)
IF NOT an 'enum' value(s) each with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "finishings-supported" attribute,
copy the attribute and the unsupported value(s), but not any
supported values, to the Unsupported Attributes response group.
page-ranges (1setOf rangeOfInteger(1:MAX))
IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
octets, REJECT/RETURN 'client-error-bad-request'.
IF first value is greater than second value in any range, the
ranges are not in ascending order, or ranges overlap,
REJECT/RETURN 'client-error-bad-request'.Okay so, picking up right where we left off 💅 If the Printer object's "page-ranges-supported" attribute is 'false', we copy that attribute into the Unsupported Attributes response group and set its value to the "out-of-band" 'unsupported' value 🎀
Next up, the per-attribute checks, bestie 🧚
sides(type2 keyword) 🌸- If it's not a single
'keyword'value, we REJECT/RETURN'client-error-bad-request'🙅♀️ - If the value length is greater than 255 octets, we REJECT/RETURN
'client-error-request-value-too-long'😭 - If it's not in the Printer object's
"sides-supported"attribute, copy the attribute and the unsupported value into the Unsupported Attributes response group 💅
- If it's not a single
number-up(integer(1:MAX)) 🦋- If it's not a single
'integer'value with a length equal to 4 octets, we REJECT/RETURN'client-error-bad-request'💀 - If it's not a value in, or within the range of one of the values of, the Printer object's
"number-up-supported"attribute, copy the attribute and value into the Unsupported Attribute response group 🫶
- If it's not a single
orientation-requested(type2 enum) 🍓- If it's not a single
'enum'value with a length equal to 4 octets, we REJECT/RETURN'client-error-bad-request'✨ - If it's not in the Printer object's
"orientation-requested-supported"attribute, copy the attribute and the unsupported value into the Unsupported Attributes response group 🌈
- If it's not a single
media(type3 keyword | name) 🧁- If it's not a single
'keyword'or'name'value, we REJECT/RETURN'client-error-bad-request'🙈 - If the value length is greater than 255 octets, we REJECT/RETURN
'client-error-request-value-too-long'😤 - If it's not in the Printer object's
"media-supported"attribute, copy the attribute and the unsupported value into the Unsupported Attributes response group 👑
- If it's not a single
printer-resolution(resolution) 🔮- If it's not a single
'resolution'value with a length equal to 9 octets, we REJECT/RETURN'client-error-bad-request'💜 - If it's not in the Printer object's
"printer-resolution-supported"attribute, copy the attribute and the unsupported value into the Unsupported Attributes response group ⭐
- If it's not a single
print-quality(type2 enum) 🌷- If it's not a single
'enum'value with a length equal to 4 octets, we REJECT/RETURN'client-error-bad-request'🥺 - If it's not in the Printer object's
"print-quality-supported"attribute, copy the attribute and the unsupported value into the Unsupported Attributes response group 🫧
- If it's not a single
Now the unknown or unsupported attributes, which are a whole vibe 🌌 These are attributes with no matching Printer object "xxx-supported" attribute (i.e., there is no corresponding Printer object "xxx-supported" attribute).
If the attribute syntax the client supplied is supported, but the length isn't legal for that syntax, we REJECT/RETURN 'client-error-bad-request' when the length of the attribute syntax is fixed, or 'client-error-request-value-too-long' when it's variable. 😬
Otherwise, we ELSE copy the attribute and value into the Unsupported Attributes response group and change the attribute value to the "out-of-band" 'unsupported' value. Any remaining Job Template Attributes are either unknown or unsupported Job Template attributes, and they get validated algorithmically according to their attribute syntax for proper length (see below) 🧠
If the attribute syntax is supported AND the length check fails, the IPP object REJECTS the request and RETURNS 'client-error-bad-request' if the length of the attribute syntax is fixed, or 'client-error-request-value-too-long' if it's variable. Otherwise, the IPP object copies the unsupported Job Template attribute into the Unsupported Attributes response group and changes the attribute value to the "out-of-band" 'unsupported' value. The table below shows the length checks for all attribute syntaxes. In it, "<=" means less than or equal, and "=" means equal to 🍰
Name Octet length check for read-write attributes
---------- ---------------------------------------------
'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
'textWithoutLanguage' <= 1023
'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63
'nameWithoutLanguage' <= 255
'keyword' <= 255
'enum' = 4
'uri' <= 1023
'uriScheme' <= 63
'charset' <= 63
'naturalLanguage' <= 63
'mimeMediaType' <= 255
'octetString' <= 1023
'boolean' = 1
'integer' = 4
'rangeOfInteger' = 8
'dateTime' = 11
'resolution' = 9
'1setOf X'Note: it's possible for a Printer to receive a zero length keyword in a request 👀 Since that's a keyword, its value has to be compared with the supported values. Assuming the Printer doesn't have any zero length keywords in its corresponding "xxx-supported" attribute, the comparison will fail. Then the request gets accepted or rejected depending on whether "ipp-attributes-fidelity" is 'false' or 'true', respectively. No special handling is required for
3.1.2.3.1 Check for conflicting Job Template attributes values
Once all the Operation and Job Template attributes have been checked one by one, the Printer object SHOULD check for any conflicting values among all the supported values the client supplied 🔍 For example, a Printer might be able to staple and also print on transparencies, but because of physical stapling constraints, it might not be able to staple transparencies. The IPP object copies the supported attributes and their conflicting attribute values into the Unsupported Attributes response group. The Printer object only copies over the attributes it either ignores or substitutes to resolve the conflict, and it returns the original values the client supplied 🙌
Say the client supplies "finishings" equal to 'staple' and "media" equal to 'transparency', but the Printer doesn't support stapling transparencies. If the Printer chooses to ignore the stapling request to resolve the conflict, it returns "finishings" equal to 'staple' in the Unsupported Attributes response group 📎 If any attributes are multi-valued, only the conflicting values get copied 🧩
Note: the decisions made to resolve a conflict (if there is a choice) are implementation dependent 🤷♀️
3.1.2.3.2 Decide whether to REJECT the request
If there were any unsupported Job Template attributes, or unsupported or conflicting Job Template attribute values, and the client supplied the "ipp-attribute-fidelity" attribute with the 'true' value, the Printer object REJECTS the request and returns one of these status codes:
'client-error-conflicting-attributes'status code, if there were any conflicts between attributes the client supplied.'client-error-attributes-or-values-not-supported'status code, otherwise.
Note: unsupported Operation attributes or values that get returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, it already rejected the request in a previous step. If control reaches this step with unsupported Operation attributes being returned, they're not serious errors 🫶
Real talk: the final results of Job processing are usually unknown at submission time, so the client has to rely on notifications or polling to find out what happens during processing ⏳ However, some Printers can tell at submission time that processing is going to fail. As an optimization, we'd like the Printer to reject the Job in these cases ⚡
There are three types of "processing" errors that might be detectable at submission time 🕵️♀️
'client-error-document-format-not-supported': for the Print-Job, Send-Document, Print-URI, and Send-URI operations, if all of these conditions are true:- the Printer supports auto-sensing,
- the request's "document-format" operation attribute is
'application/octet-stream', - the Printer receives document data before responding,
- the Printer auto-senses the document format before responding,
- the sensed document format is not supported by the Printer,
then the Printer should respond with the 'client-error-document-format-not-supported' status 🙃
'client-error-compression-error': for the Print-Job, Send-Document, Print-URI, and Send-URI operations, if all of these conditions are true:- the client supplies a supported value for the "compression" operation attribute in the request,
- the Printer receives document data before responding,
- the Printer attempts to decompress the document data before responding,
- the document data cannot be decompressed using the algorithm specified by the "compression" operation attribute,
then the Printer should respond with the 'client-error-compression-error' status 🗜️
'client-error-document-access-error': for the Print-URI and Send-URI operations, if the Printer attempts and fails to pull the referenced document data before responding, it should respond with the'client-error-document-access-error'status 🔗
Some Printers can't detect these errors until processing time. In that case, the errors get recorded in the corresponding job-state and job-state reason attributes. (There's no standard way for a client to figure out whether a Printer can detect these errors at submission time 🤫) For example, if auto-sensing happens after the Job is accepted, the implementation aborts the Job, puts it in the 'aborted' state, and sets the 'unsupported-document-format' value in the Job's "job-state-reasons" 💔
A client should always provide a valid "document-format" operation attribute whenever it's practical 📄 Without other information, a client itself may sniff the document data to determine the document format 👃
Auto sensing at submission time may be trickier for the Printer when it's combined with compression 🌀 For auto-sensed Jobs, a client may be better off deferring compression to the transfer protocol layer, e.g.; by using the HTTP Content-Encoding header 🎁
3.1.2.3.3 For the Validate-Job operation, RETURN one of the success status codes
If the requested operation is the Validate-Job operation, the Printer object returns:
- the
"successful-ok"status code, if there are no unsupported or conflicting Job Template attributes or values. ✅ - the
"successful-ok-conflicting-attributes, if there are any conflicting Job Template attribute or values. 🤔 - the
"successful-ok-ignored-or-substituted-attributes, if there are only unsupported Job Template attributes or values. 🫠
Note: unsupported Operation attributes or values that get returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, it already rejected the request in a previous step. If control reaches this step with unsupported Operation attributes being returned, they're not serious errors 💖
3.1.2.3.4 Create the Job object with attributes to support
If "ipp-attribute-fidelity" is set to 'false' (or it wasn't supplied by the client), the Printer object:
- creates a Job object 💖, assigns a unique value to the job's
job-uriandjob-idattributes, and initializes all of the job's other supported Job Description attributes. - removes all unsupported attributes from the Job object 🧹.
- for each unsupported value, removes either the unsupported value or substitutes the unsupported attribute value with some supported value. If an attribute has no values after removing unsupported values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute).
- for each conflicting value, removes either the conflicting value or substitutes the conflicting attribute value with some other supported value. If an attribute has no values after removing conflicting values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute).
Okay so if there were no attributes or values flagged as unsupported, or the value of ipp-attribute-fidelity was false, the Printer object is able to accept the create request and create a new Job object ✨. If ipp-attribute-fidelity is set to true, the Job Template attributes that populate the new Job object are necessarily all the Job Template attributes supplied in the create request 🎀. If ipp-attribute-fidelity is set to false, the Job Template attributes that populate the new Job object are all the client supplied Job Template attributes that are supported or that have value substitution. Thus, some of the requested Job Template attributes will not appear in the Job object because the Printer object did not support those attributes. The attributes that populate the Job object are persistently stored with the Job object for that Job. A Get-Job-Attributes operation on that Job object will return only those attributes that are persistently stored with the Job object 🧚.
Note: All Job Template attributes that are persistently stored with the Job object are intended to be "override values"; that is, they that take precedence over whatever other embedded instructions might be in the document data itself. However, it is not possible for all Printer objects to realize the semantics of "override". End users may query the Printer's pdl-override-supported attribute to determine if the Printer either attempts or does not attempt to override document data instructions with IPP attributes 🙈.
There are some cases, where a Printer supports a Job Template attribute and has an associated default value set for that attribute. In the case where a client does not supply the corresponding attribute, the Printer does not use its default values to populate Job attributes when creating the new Job object; only Job Template attributes actually in the create request are used to populate the Job object. The Printer's default values are only used later at Job processing time if no other IPP attribute or instruction embedded in the document data is present 💅.
Note: If the default values associated with Job Template attributes that the client did not supply were to be used to populate the Job object, then these values would become "override values" rather than defaults. If the Printer supports the 'attempted' value of thepdl-override-supportedattribute, then these override values could replace values specified within the document data. This is not the intent of the default value mechanism. A default value for an attribute is used only if the create request did not specify that attribute (or it was ignored when allowed byipp-attribute-fidelitybeingfalse) and no value was provided within the content of the document data 🍓.
If the client does not supply a value for some Job Template attribute, and the Printer does not support that attribute, as far as IPP is concerned, the result of processing that Job (with respect to the missing attribute) is undefined 🤷♀️.
3.1.2.3.5 Return one of the success status codes ✨
Once the Job object has been created, the Printer object accepts the request and returns to the client:
- the
successful-okstatus code, if there are no unsupported or conflicting Job Template attributes or values. - the
successful-ok-conflicting-attributesstatus code, if there are any conflicting Job Template attribute or values. - the
successful-ok-ignored-or-substituted-attributesstatus code, if there are only unsupported Job Template attributes or values.
Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors.
The Printer object also returns Job status attributes that indicate the initial state of the Job (pending, pending-held, processing, etc.), etc. See Print-Job Response, [RFC2911] section 3.2.1.2 🦋.
3.1.2.3.6 Accept appended Document Content 📦
The Printer object accepts the appended Document Content data and either starts it printing, or spools it for later processing.
3.1.2.3.7 Scheduling and Starting to Process the Job 🔥
The Printer object uses its own configuration and implementation specific algorithms for scheduling the Job in the correct processing order. Once the Printer object begins processing the Job, the Printer changes the Job's state to processing. If the Printer object supports PDL override (the pdl-override-supported attribute set to attempted), the implementation does its best to see that IPP attributes take precedence over embedded instructions in the document data 👑.
3.1.2.3.8 Completing the Job 🌈
The Printer object continues to process the Job until it can move the Job into the completed state. If a Cancel-Job operation is received, the implementation eventually moves the Job into the canceled state. If the system encounters errors during processing that do not allow it to progress the Job into a completed state, the implementation halts all processing, cleans up any resources, and moves the Job into the aborted state 😭.
3.1.2.3.9 Destroying the Job after completion 🫶
Once the Job moves to the completed, aborted, or canceled state, it is an implementation decision as to when to destroy the Job object and release all associated resources. Once the Job has been destroyed, the Printer would return either the client-error-not-found or client-error-gone status codes for operations directed at that Job.
Note: the Printer object SHOULD NOT re-use ajob-uriorjob-idvalue for a sufficiently long time after a job has been destroyed, so that stale references kept by clients are less likely to access the wrong (newer) job 💀.
3.1.2.3.10 Interaction with "ipp-attribute-fidelity" 🧩
Some Printer object implementations may support ipp-attribute-fidelity set to true and pdl-override-supported set to attempted and yet still not be able to realize exactly what the client specifies in the create request. This is due to legacy decisions and assumptions that have been made about the role of job instructions embedded within the document data and external job instructions that accompany the document data and how to handle conflicts between such instructions. The inability to be 100% precise about how a given implementation will behave is also compounded by the fact that the two special attributes, ipp-attribute-fidelity and pdl-override-supported, apply to the whole job rather than specific values for each attribute. For example, some implementations may be able to override almost all Job Template attributes except for number-up.
Character Sets, natural languages, and internationalization 🌸
This section discusses character set support, natural language support and internationalization 🌍.
3.1.2.3.11 Character set code conversion support 💜
IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY support additional charsets. It is RECOMMENDED that an IPP object also support US-ASCII, since many clients support US-ASCII, and indicate that UTF-8 and US-ASCII are supported by populating the Printer's charset-supported with utf-8 and us-ascii values. An IPP object is required to code covert with as little loss as possible between the charsets that it supports, as indicated in the Printer's charsets-supported attribute 🔤.
How should the server handle the situation where the attributes-charset of the response itself is us-ascii, but one or more attributes in that response is in the utf-8 format? 🤔
Example: Consider a case where a client sends a Print-Job request with utf-8 as the value of attributes-charset and with the job-name attribute supplied. Later another client submits a Get-Job-Attribute or Get-Jobs request. This second request contains the attributes-charset with value us-ascii and requested-attributes attribute with exactly one value job-name.
According to the RFC2911 document (section 3.1.4.2), the value of the attributes-charset for the response of the second request must be us-ascii since that is the charset specified in the request. The job-name value, however, is in utf-8 format. Should the request be rejected even though both utf-8 and us-ascii charsets are supported by the server? or should the job-name value be converted to us-ascii and return successful-ok-conflicting-attributes (0x0002) as the status code? 😬
Answer: An IPP object that supports both utf-8 (REQUIRED) and us-ascii, the second paragraph of section 3.1.4.2 applies so that the IPP object MUST accept the request, perform code set conversion between these two charsets with "the highest fidelity possible" and return successful-ok, rather than a warning successful-ok-conflicting-attributes, or an error. The printer will do the best it can to convert between each of the character sets that it supports -- even if that means providing a string of question marks because none of the characters are representable in US ASCII. If it can't perform such conversion, it MUST NOT advertise us-ascii as a value of its attributes-charset-supported and MUST reject any request that requests us-ascii 🙌.
One IPP object implementation strategy is to convert all request text and name values to a Unicode internal representation. This is 16-bit and virtually universal. Then convert to the specified operation attributes-charset on output 🧠.
Also it would be smarter for a client to ask for utf-8, rather than us-ascii and throw away characters that it doesn't understand, rather than depending on the code conversion of the IPP object ✨.
3.1.2.3.12 What charset to return when an unsupported charset is requested (Issue 1.19)? 💅
okay bestie, so Section 3.1.4.1 Request Operation attributes got clarified in November 1998, and this is the tea 🍵
All clients and IPP objects MUST support the 'utf-8' charset [RFC2044] and MAY support additional charsets provided that 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 and any 'text' or 'name' attributes using the 'utf-8' charset.
Since the client and IPP object MUST support UTF-8, sending back any text or name attributes in UTF-8 when the client asks for a charset that isn't supported means the client can still show them to the user. Literally the safety net 🫶
It's a client error, not a user error, so the client should check the status code first. That way it can skip displaying any other returned 'text' and 'name' attributes that aren't in the charset it asked for. Main character energy for the status code 🎀
Also, [RFC2911] section 14.1.4.14 client-error-charset-not-supported (0x040D) got the same glow-up in November 1998:
For any operation, if the IPP Printer does not support the charset supplied by the client in the "attributes-charset" operation attribute, the Printer MUST reject the operation and return this status and any 'text' or 'name' attributes using the 'utf-8' charset (see Section 3.1.4.1).
3.1.2.3.13 Natural Language Override (NLO) 🌸
okay so the 'text' and 'name' attributes each come in two flavours 🦋 One has an implicit natural language and the other has an explicit one. 'textWithoutLanguage' and 'textWithLanguage' are the two 'text' forms, and 'nameWithoutLanguage" and 'nameWithLanguage are the two 'name' forms.
If a receiver (IPP object or IPP client) supports an attribute with attribute syntax 'text', it MUST support both forms in a request and a response. A sender (IPP client or IPP object) MAY send either form for any such attribute. When a sender uses a WithoutLanguage form, the implicit natural language goes in the "attributes-natural-language" operation attribute, and all senders MUST include that in every request and response. Bestie, that one is non-negotiable 💖
When a sender uses a WithLanguage form, that language MAY be different from the implicit natural language the sender supplied, or it MAY be the same. Either way, the receiver MUST treat both forms equivalently ✨
Now the senders get a choice 🎀 They can always send the WithLanguage forms, which keeps the sender code simpler. Or they can use the WithoutLanguage form whenever the attribute's language matches the request or response. That one is more efficient on the wire, and it lets things talk to non-conforming receivers that can't handle the WithLanguage forms. Both approaches have their perks, so the call is totally up to the sender's implementer 🍓
Here's the plot twist 😭 When a client gets back a 'text' or 'name' job attribute that it supplied earlier, it MUST NOT expect the attribute to be in the same form it used when creating the job. That means WithoutLanguage or WithLanguage, whichever it originally sent. The IPP object can switch between the two forms whenever it likes, as long as the natural language stays the same. It's usually easier to store the natural language right alongside the value, basically an internal representation that looks like the WithLanguage form 🧚
The IPP Printer MUST copy the natural language of a job to the Job object as a Job Description attribute, so the client can query it. That natural language is the value of "attributes-natural-language" that the client sent in the create operation. When the IPP object returns a Get-Job-Attributes response, it MAY return one of three natural language values in the response's "attributes-natural-language" operation attribute:
- (1) the language the requester asked for,
- (2) the natural language of the job, or
- (3) the configured natural language of the IPP Printer, if the requested language isn't supported by the IPP Printer.
This "attributes-natural-language" Job Description attribute is super useful for an IPP object that prints start sheets in the language of whoever submitted the job 📄 It's also clutch for a multilingual operator who has to talk to submitters in different languages. And it's expected to be used later to generate notification messages in the submitter's natural language 🌈
Fun backstory 💅 Early drafts of [RFC2911] had a job-level natural language override (NLO) for the Get-Jobs response. A job-level NLO was an (unrequested) Job Attribute that set the implicit natural language for any other WithoutLanguage job attributes in that job's response. Interop testing showed that nobody was actually implementing the job-level NLO in Get-Job responses, so it got cut from the Get-Jobs response 🙈 Now every request and response is consistent: the implicit natural language for any WithoutLanguage 'text' or 'name' form is always supplied in the request's or response's "attributes-natural-language" operation attribute. Clean, iconic, done ✨
3.1.3 Status codes returned by operation 🧾
okay this section is the sibling of [RFC2911] section 3.1.6 "Operation Response Status Codes and Status Messages" 🦋 It lists every status code once, under the first operation (Print-Job). After that, it only calls out the status codes that are different or specialised for each later operation.
3.1.3.1 Printer Operations 🖨️
3.1.3.1.1 Print-Job 💖
The Printer object MUST return one of the following "status-code" values for the reason it's given. Whether all of the document data has been accepted before the success or error response goes out depends on the implementation. For a fuller explanation of each status code, see Section 13 in [RFC2911] ✨
For the following success status codes, the Job object has been created, and the "job-id" and "job-uri" got assigned and returned in the response:
successful-ok: no request attributes were substituted or ignored.successful-ok-ignored-or-substituted-attributes: some supplied (1) attributes were ignored, or (2) unsupported attribute syntax's or values were substituted with supported values or were ignored. Unsupported attributes, attribute syntax's, or values MUST be returned in the Unsupported Attributes group of the response.successful-ok-conflicting-attributes: some supplied attribute values conflicted with the values of other supplied attributes, and were either substituted or ignored. Attributes or values that conflict with other attributes and got substituted or ignored MUST be returned in the Unsupported Attributes group of the response, as supplied by the client 🫶
[RFC2911] section 3.1.6 Operation Status Codes and Messages states:
If the Printer object supports the "status-message" operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a status message for the following error status codes (see section 13 in [RFC2911]): '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 this case, it MUST set the value of the "attributes-charset" operation attribute to 'utf-8' in the error response.
For the following error status codes, no job gets created, and no "job-id" or "job-uri" is returned 😭
client-error-bad-request: The request syntax does not conform to the specification.client-error-forbidden: The request is being refused for authorization or authentication reasons. The implementation security policy is to not reveal whether the failure is one of authentication or authorization. 🙈client-error-not-authenticated: Either the request requires authentication information to be supplied, or the authentication information is not sufficient for authorization.client-error-not-authorized: The requester is not authorized to perform the request on the target object.client-error-not-possible: The request cannot be carried out because of the state of the system. Theserver-error-not-accepting-jobsstatus code is also relevant here, and it MUST take precedence if the Printer object's"printer-accepting-jobs"attribute is 'false' 💀client-error-timeout: not applicable.client-error-not-found: the target object does not exist.client-error-gone: the target object no longer exists and no forwarding address is known.client-error-request-entity-too-large: the size of the request and/or print data exceeds the capacity of the IPP Printer to process it.client-error-request-value-too-long: the size of request variable length attribute values, such as 'text' and 'name' attribute syntax's, exceeds the maximum length specified in [RFC2911] for the attribute, and the value MUST be returned in the Unsupported Attributes Group.- supplied is not supported. The "document-format" attribute with the unsupported value MUST be returned in the Unsupported Attributes Group. This error SHOULD take precedence over any other 'xxx-not-supported' error, except
client-error-charset-not-supported. client-error-attributes-or-values-not-supported: one or more supplied attributes, attribute syntax's, or values are not supported, and the client supplied the"ipp-attributes-fidelity"operation attribute with a 'true' value. They MUST be returned in the Unsupported Attributes Group as explained below. ✨client-error-uri-scheme-not-supported: not applicable.client-error-charset-not-supported: the charset supplied in the"attributes-charset"operation attribute is not supported. The Printer's"configured-charset"MUST be returned in the response as the value of the"attributes-charset"operation attribute, and it MUST be used for any 'text' and 'name' attributes returned in the error response. This error SHOULD take precedence over any other error, unless the request syntax is so bad that the client's supplied"attributes-charset"cannot be determined. 🌸client-error-conflicting-attributes: one or more supplied attribute values conflicted with each other, and the client supplied the"ipp-attributes-fidelity"operation attribute with a 'true' value. They MUST be returned in the Unsupported Attributes Group as explained below.server-error-internal-error: an unexpected condition prevents the request from being fulfilled.server-error-operation-not-supported: not applicable (since Print-Job is REQUIRED).server-error-service-unavailable: the service is temporarily overloaded. 💜
Okay bestie, the status codes keep going, so let's dive back in 💅✨
server-error-version-not-supported: the version in the request isn't supported 😭. The "closest" version number supported MUST be returned in the response 🎀server-error-device-error: a device error happened while receiving or spooling the request or document data, or the IPP Printer object can only accept one job at a time 🖨️server-error-temporary-error: a temporary hiccup like a buffer full write error, a memory overflow, or a disk full condition happened while receiving the request and/or the document data 💀server-error-not-accepting-jobs: the Printer object'sprinter-is-not-accepting-jobsattribute is'false'🙈server-error-busy: the Printer is too busy processing jobs to take another one right now 🍓server-error-job-canceled: an operator or the system canceled the job while the client was still transmitting the document data 😭🫶
3.1.3.1.2 Print-URI 🦋
All of the Print-Job status codes from Section 3.1.3.1.1 Print-Job Response apply to Print-URI, with these specializations and differences. See Section 14 for a more complete description of each status code 📚
client-error-uri-scheme-not-supported: the URI scheme in thedocument-urioperation attribute isn't supported, and it gets returned in the Unsupported Attributes group 🌸server-error-operation-not-supported: the Print-URI operation isn't supported 💅
3.1.3.1.3 Validate-Job 🧚
All of the Print-Job status codes from Section 3.1.3.1.1 Print-Job Response apply to Validate-Job. See Section 13 in [RFC2911] for a more complete description of each status code ✨
3.1.3.1.4 Create-Job 👑
All of the Print-Job status codes from Section 3.1.3.1.1 Print-Job Response apply to Create-Job, with these specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code 💖
server-error-operation-not-supported: the Create-Job operation isn't supported 🙃client-error-multiple-document-jobs-not-supported: Create-Job and Send-Document are both supported, but this implementation doesn't allow more than one document with data 🌈
3.1.3.1.5 Get-Printer-Attributes 🔥
All of the Print-Job status codes from Section 3.1.3.1.1 Print-Job Response apply to Get-Printer-Attributes, with these specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code 🎀
For the following success status codes, the requested attributes come back in Group 3 of the response ✨
successful-ok: no operation attributes or values were substituted or ignored (same as Print-Job), and no requested attributes were unsupported 💯successful-ok-ignored-or-substituted-attributes: therequested-attributesoperation attribute MAY, but need not, be returned with the unsupported values 🫶successful-ok-conflicting-attributes: same as Print-Job 🦋
For the error status codes, Group 3 either contains no attributes or isn't returned at all 🙈
client-error-not-possible: same as Print-Job, plus the Printer object isn't accepting any requests 💀client-error-request-entity-too-large: same as Print-Job, except that no print data is involved 🍓client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above) 🌸client-error-conflicting-attributes: same as Print-Job, except thatipp-attribute-fidelityisn't involved 🧚server-error-operation-not-supported: not applicable (since Get-Printer-Attributes is REQUIRED) 👑server-error-device-error: same as Print-Job, except that no document data is involved 🖨️server-error-temporary-error: same as Print-Job, except that no document data is involved 😭server-error-not-accepting-jobs: not applicable 🙃server-error-busy: same as Print-Job, except the IPP object is too busy to accept even query requests 🔥server-error-job-canceled: not applicable 💅
3.1.3.1.6 Get-Jobs 💜
All of the Print-Job status codes from Section 3.1.3.1.1 Print-Job Response apply to Get-Jobs, with these specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code 📚
For the following success status codes, the requested attributes come back in Group 3 of the response ✨
successful-ok: same as Get-Printer-Attributes (see Section 3.1.3.1.5) 🦋successful-ok-ignored-or-substituted-attributes: same as Get-Printer-Attributes (see Section 3.1.3.1.5) 🫶successful-ok-conflicting-attributes: same as Get-Printer-Attributes (see Section 3.1.3.1.5) 💖
For any error status codes, Group 3 either contains no attributes or isn't returned at all. These brief error descriptions have unique info for Get-Jobs. See Section 14 for the other error status codes that apply to all operations uniformly 🌈
client-error-not-possible: same as Print-Job, plus the Printer object isn't accepting any requests 💀client-error-request-entity-too-large: same as Print-Job, except that no print data is involved 🍓client-error-document-format-not-supported: not applicable 🙈client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above) 🌸client-error-conflicting-attributes: same as Print-Job, except thatipp-attribute-fidelityisn't involved 🧚server-error-operation-not-supported: not applicable (since Get-Jobs is REQUIRED) 👑server-error-device-error: same as Print-Job, except that no document data is involved 🖨️server-error-temporary-error: same as Print-Job, except that no document data is involved 😭server-error-not-accepting-jobs: not applicable 🙃server-error-job-canceled: not applicable 💅
3.1.3.1.7 Pause-Printer ⭐
All of the Print-Job status codes from Section 3.1.3.1.1 Print-Job Response apply to Pause-Printer, with these specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code 🎀
For the following success status codes, the Printer object is being stopped from scheduling jobs on all its devices 🛑
successful-ok: no request attributes were substituted or ignored (same as Print-Job) 💯successful-ok-ignored-or-substituted-attributes: same as Print-Job 🫶successful-ok-conflicting-attributes: same as Print-Job 🦋
For any of the error status codes, the Printer object has NOT been stopped from scheduling jobs on all its devices 🙈
Quick aside: this one is the "nothing changed" situation, so the printer keeps doing its thing 💅
client-error-not-possible: not applicable 🌸client-error-not-found: the target Printer object doesn't exist 🧚client-error-gone: the target Printer object no longer exists and no forwarding address is known 😭client-error-request-entity-too-large: same as Print-Job, except that no document data is involved 🍓client-error-document-format-not-supported: not applicable 🙃client-error-conflicting-attributes: same as Print-Job, except that the Printer'sprinter-is-accepting-jobsattribute isn't involved 🌈server-error-operation-not-supported: the Pause-Printer operation isn't supported 💀server-error-device-error: not applicable 🖨️server-error-temporary-error: same as Print-Job, except that no document data is involved 😭server-error-not-accepting-jobs: not applicable 🙃server-error-job-canceled: not applicable 💅
3.1.3.1.8 Resume-Printer 🌸
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response, with the specializations described for Pause-Printer, apply to Resume-Printer. See Section 13 in [RFC2911] for a more complete description of each status code 📚
For the following success status codes, the Printer object resumes scheduling jobs on all its devices 🎉
successful-ok: no request attributes were substituted or ignored (same as Print-Job) 💯successful-ok-ignored-or-substituted-attributes: same as Print-Job 🫶successful-ok-conflicting-attributes: same as Print-Job 🦋
For any of the error status codes, the Printer object does not resume scheduling jobs 🙈
server-error-operation-not-supported: the Resume-Printer operation isn't supported 💅
3.1.3.1.8.1 What about Printers unable to change state due to an error condition? 💀
Okay so, what if the IPP printer can't change its state because of some problem with the actual printer device? Like, it's shut down, or there's a media-jam, as described in [RFC2911]. What should the result of the "Resume-Printer" operation be? Should it still change the 'printer-state-reasons' and return success, or should it fail? 🤔
The Resume-Printer operation must clear the 'paused' or 'moving-to-paused' 'printer-state-message' 🧹 It must return a 'successful-ok' status code ✨
3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? 🌈
So if Resume-Printer succeeds, what should the value of "printer-state" be, and who looks after the "printer-state" attribute value later on? 👀
The Resume-Printer operation may change the "printer-state-reasons" value 💜
The "printer-state" changes to one of three states:
- 'idle' - no additional jobs and no error conditions present 😴
- 'processing' - job available and no error conditions present 🏃♀️
- current state (i.e. no change) - an error condition is present (e.g. media jam) 🛠️
In the third case, the "printer-state-reason" gets cleared by automata once it detects the error condition is gone. The "printer-state" moves to 'idle' or 'processing' when conditions permit (i.e. no more error conditions) 🎀
3.1.3.1.9 Purge-Printer 🧹
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response, with the specializations described for Pause-Printer, apply to Purge-Printer. See Section 13 in [RFC2911] for a more complete description of each status code ✨
For the following success status codes, the Printer object purges all of its jobs 🫧
successful-ok: no request attributes were substituted or ignored (same as Print-Job) 💯successful-ok-ignored-or-substituted-attributes: same as Print-Job 🫶successful-ok-conflicting-attributes: same as Print-Job 🦋
For any of the error status codes, the Printer object does not purge any jobs 🙈
server-error-operation-not-supported: the Purge-Printer operation isn't supported 💅
3.1.3.2 Job Operations ✨
Okay bestie, now we're in job-land 💅 All of the Print-Job status codes from Section 3.1.3.1.1 Print-Job Response apply here too, with the tweaks below. For the full tea on each code, check Section 13 in [RFC2911] 🎀
3.1.3.2.1 Send-Document
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to the Get-Printer-Attributes operation, with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
For these success codes, the document has been added to the specified Job object and the job's number-of-documents attribute has been incremented 🌸
successful-ok: no request attributes were substituted or ignored (same as Print-Job).successful-ok-ignored-or-substituted-attributes: same as Print-Job.successful-ok-conflicting-attributes: same as Print-Job.
For the error codes, no document has been added to the Job object and the job's number-of-documents attribute has not been incremented 🙈
client-error-not-possible: Same as Print-Job, except that the Printer'sprinter-is-accepting-jobsattribute is not involved, so that the client is able to finish submitting a job that was created with a Create-Job operation after this attribute has been set to 'true'. Another condition is that the state of the job precludes Send-Document, i.e., the job has already been closed out by the client. However, if the IPP Printer closed out the job due to timeout, theclient-error-timeouterror status SHOULD be returned instead.client-error-timeout: This request was sent after the Printer closed the job, because it has not received a Send-Document or Send-URI operation within the Printer'smultiple-operation-time-outperiod.client-error-request-entity-too-large: same as Print-Job.client-error-conflicting-attributes: same as Print-Job, except thatipp-attributes-fidelityoperation attribute is not involved..server-error-operation-not-supported: the Send-Document request is not supported.server-error-not-accepting-jobs: not applicable.server-error-job-canceled: the job has been canceled by an operator or the system while the client was transmitting the data.
3.1.3.2.2 Send-URI
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response, with the specializations described for Send-Document, are applicable to Send-URI. See Section 13 in [RFC2911] for a more complete description of each status code.
client-error-uri-scheme-not-supported: the URI scheme supplied in thedocument-urioperation attribute is not supported, and thedocument-uriattribute MUST be returned in the Unsupported Attributes group.server-error-operation-not-supported: the Send-URI operation is not supported.
3.1.3.2.3 Cancel-Job
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Cancel-Job with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
For these success codes, the Job object is being canceled or has been canceled 🫶
successful-ok: no request attributes were substituted or ignored (same as Print-Job).successful-ok-ignored-or-substituted-attributes: same as Print-Job.successful-ok-conflicting-attributes: same as Print-Job.
For any of the error codes, the Job object has not been canceled or was previously canceled 💀
client-error-not-possible: The request cannot be carried out because of the state of the Job object ('completed', 'canceled', or 'aborted') or the state of the system.client-error-not-found: the target Printer and/or Job object does not exist.client-error-gone: the target Printer and/or Job object no longer exists and no forwarding address is known.client-error-request-entity-too-large: same as Print-Job, except no document data is involved.client-error-document-format-not-supported: not applicable.client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and values MUST be ignored.client-error-conflicting-attributes: same as Print-Job, except that the Printer'sprinter-is-accepting-jobsattribute is not involved.server-error-operation-not-supported: not applicable (Cancel-Job is REQUIRED).server-error-device-error: same as Print-Job, except no document data is involved.server-error-temporary-error: same as Print-Job, except no document data is involved.server-error-not-accepting-jobs: not applicable.server-error-job-canceled: not applicable.
3.1.3.2.4 Get-Job-Attributes
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Get-Job-Attributes with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
For these success codes, the requested attributes are returned in Group 3 in the response 🧚
successful-ok: same as Get-Printer-Attributes (see section 3.1.3.1.5).successful-ok-ignored-or-substituted-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).successful-ok-conflicting-attributes: same as Get-Printer-Attributes (see section 3.1.3.1.5).
For the error codes, Group 3 is returned containing no attributes or is not returned at all.
client-error-not-possible: Same as Print-Job, in addition the Printer object is not accepting any requests.client-error-document-format-not-supported: not applicable.client-error-attributes-or-values-not-supported: not applicable.client-error-uri-scheme-not-supported: not applicable.client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and/or values MUST be ignored and an appropriate success code returned (see above).client-error-conflicting-attributes: not applicableserver-error-operation-not-supported: not applicable (since Get-Job-Attributes is REQUIRED).server-error-device-error: same as Print-Job, except no document data is involved.server-error-temporary-error: sane as Print-Job, except no document data is involved..server-error-not-accepting-jobs: not applicable.server-error-job-canceled: not applicable.
3.1.3.2.5 Hold-Job
All of the Print-Job status codes described in Section 3.1.3.1.1 Print-Job Response are applicable to Hold-Job with the following specializations and differences. See Section 13 in [RFC2911] for a more complete description of each status code.
For these success codes, the Job object is being held or has been held ✨
successful-ok: no request attributes were substituted or ignored (same as Print-Job).successful-ok-ignored-or-substituted-attributes: same as Print-Job.successful-ok-conflicting-attributes: same as Print-Job.
For any of the error codes, the Job object has not been held or was previously held.
client-error-not-possible: The request cannot be carried out because of the state of the Job object ('completed', 'canceled', or 'aborted') or the state of the system.client-error-not-found: the target Printer and/or Job object does not exist.client-error-gone: the target Printer and/or Job object no longer exists and no forwarding address is known.client-error-request-entity-too-large: same as Print-Job, except no document data is involved.client-error-document-format-not-supported: not applicable.client-error-conflicting-attributes: same as Print-Job, except that the Printer'sprinter-is-accepting-jobsattribute is not involved.server-error-operation-not-supported: the Hold-Job operation is not supported.server-error-device-error: not applicable.server-error-temporary-error: same as Print-Job, except no document data is involved.server-error-not-accepting-jobs: not applicable.server-error-job-canceled: not applicable.
3.1.3.2.6 Release-Job
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response, with the specializations described for Hold-Job, are applicable to Release-Job. See Section 13 in [RFC2911] for a more complete description of each status code.
server-error-operation-not-supported: the Release-Job operation is not supported.
3.1.3.2.7 Restart-Job
All of the Print-Job status code descriptions in Section 3.1.3.1.1 Print-Job Response, with the specializations described for Hold-Job, are applicable to Restart-Job. See Section 13 in [RFC2911] for a more complete description of each status code.
server-error-operation-not-supported: the Restart-Job operation is not supported.
3.1.3.2.7.1 Can documents be added to a restarted job?
Okay, the classic question 🙈 Say I give a Create-Job request along with a set of 5 documents. All the documents get printed and the job state moves to completed. I issue a Restart-Job request on the job. Now, if I try to add new documents to the restarted job, will the IPP Server let me do it, or return client-error-not-possible and print those 5 jobs all over again?
A job can not move to the 'completed' state until all the documents have been processed. The 'last-document' flag indicates when the last document for a job is being sent from the client. This is the semantic equivalent of closing a job. No documents may be added once a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job is moved to the 'pending' job state and restarts the beginning on the same IPP Printer object with the same attribute values." number-of-documents is a job attribute.
3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue 1.18) 🌈
In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes responses, the client cannot depend on getting back the unsupported attributes it asked for in the Unsupported Attributes group 🥺 Those attributes won't show up in the Job Attributes or Printer Attributes group either, since they're unsupported. So the IPP object is REQUIRED to return the successful-ok-ignored-or-substituted-attributes status code, which tells the client that not everything it requested came back 💜
3.1.5 Sending empty attribute groups
okay bestie so [RFC2911] and [RFC2910] RECOMMEND that a sender not send an empty attribute group in a request or a response 🫶 BUT the receiver has to be chill about it, because they REQUIRE a receiver to accept an empty attribute group as equivalent to just leaving that group out 💅. So a client SHOULD omit the Job Template Attributes group entirely in a create operation that is not supplying any Job Template attributes ✨, and an IPP object SHOULD omit an empty Unsupported Attributes group if there are no unsupported attributes to be returned in a response 🌸.
The [RFC2910] specification REQUIRES a receiver to be able to receive either an empty attribute group or an omitted attribute group and treat them the same way 🦋. The term "receiver" means an IPP object for a request and a client for a response. The term "sender'" means a client for a request and an IPP object for a response. Main character energy for the terms, honestly 💜.
There is an exception to the rule for Get-Jobs when there are no attributes to be returned 👑. [RFC2910] has this paragraph about it:
The syntax allows an xxx-attributes-tag to be present when the xxx- attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.
So the sender is strongly encouraged to skip the tag, except for that Get-Jobs case, but the receiver has to be able to decode it anyway 🙈✨.
3.2 Printer Operations
3.2.1 Print-Job operation
3.2.1.1 Flow controlling the data portion of a Print-Job request (Issue 1.22)
okay so a paused printer, or one that's stopped because of paper out, a jam, spool space full, or buffer space full 😭, can flow control the data of a Print-Job operation (at the TCP/IP layer). That means the client might not be able to send all the document data 💀. Because of that, the Printer just won't send back a response until the condition changes 🌈.
The Printer should not return a Print-Job response with an error code in any of these conditions 🙅♀️, since the printer will be resumed and/or the condition will clear either because a human fixed it or because jobs keep printing 🖨️✨.
If you're writing test scripts for IPP Printers, the script also has to be written so it doesn't expect a response while the printer is paused 🎀. It should wait until the printer is resumed, so it works with all possible implementations 💖.
3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)
so picture this 🍓: an IPP client submits a small job via Print-Job. By the time the IPP printer/print server is putting together the response, the job has already finished printing and been removed as an object from the print system 😱. So what should the job-state be in the response? Big question, bestie 🧚.
The Model suggests that the Printer return a response before it even accepts the document content. The Job Object Attributes only come back if the IPP object returns one of the success status codes. So the job-state would always be "pending" or "pending-held" 🫠.
This issue shows up when an IPP Printer object is a server that forwards jobs to devices that don't send job status back to the server 🖥️. If the server is reasonably certain the job completed successfully, then it should return the job-state as 'completed' 🎉. The server can also keep the job in its "job history" long after it's gone from the device. Then a user can query the server, see the job in the 'completed' state, and see it completed at the time in the job's "time-at-completed" attribute, which would be the same as when the server submitted the job to the device ✨.
Another option is for the server to respond to the client before or while sending the job to the device, instead of waiting until it has finished sending the job 🏃♀️. In that case, the server can return the job's state as 'pending' with the 'job-outgoing' value in the job's "job-state-reasons" attribute 💜.
If the server doesn't know for sure whether the job completed successfully (or at all), it could return the (out-of-band) 'unknown' value 🤷♀️.
On the other hand, if the server can query the device and/or set up some kind of event notification that the device starts when the job changes state, then the server can return the current job state in the Print-Job response and in later queries, because it knows the job state in the device (or can ask the device) 🔥.
All of these options depend on how the server and the device are implemented 🛠️. Literally every choice is an implementation thing, so no one-size-fits-all answer here 🙃.
3.2.2 Get-Printer-Attributes operation
if a Printer supports the printer-make-and-model attribute and returns the .INF file model name of the printer in that attribute, the Microsoft client will automatically install the correct driver (if one is available) 🖨️💅.
Clients that poll periodically for printer status or queued-job-count should use the "requested-attributes" operation attribute to limit the scope of the query 🌸. That saves Printer and network resources, which is so considerate 🫶✨.
3.2.3 Get-Jobs operation
3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue 1.39)?
ok so in [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' attribute be there too? And if it's not present, what should the IPP printer do? 🤔
[RFC2911] Section 8.3 covers all the cases for "requesting-user-name" being present or not, for any operation. If the client does not supply a value for "requesting-user-name", the printer MUST assume the client is supplying some anonymous name, such as "anonymous" 🙈💖.
3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
the "limit" attribute is so a client can stay snappy 🏎️. A client implementer might want to limit how many jobs the client shows on the first screenful. For example, if its UI can only display 50 jobs, it can protect itself from a printer that would otherwise return 500 jobs, which could take forever on a slow dial-up line 😩. The client can then ask for a bigger number of jobs in the background while showing the user the first 50 🧚.
Here's the vibe: job history comes back in reverse order, so the most recently completed jobs come first, and the user is most likely interested in those first ones 👑. Limiting the count is especially useful for a client asking for 'completed' jobs from a printer with a long job history 📜. Clients that don't mind sometimes getting very large responses can just leave out the "limit" attribute in their Get-Jobs requests 🌈.
3.2.4 Create-Job operation
a Printer may respond to a Create-Job operation with "job-state" 'pending' or 'pending-held', plus "job-state-reason" 'job-data-insufficient'. That means the operation was accepted, but the Printer is waiting for more document data before it can move the job into the 'processing' state 🦋. Or it may respond with "job-state" 'processing' and "job-state-reason" 'job-incoming'. That also means the Create-Job operation was accepted, but the Printer is waiting for more Send-Document and/or Send-URI operations and/or is accessing or accepting document data 📥. The second option is for non-spooling Printers that don't implement the 'pending' state 💅.
Should the server wait for the "last-document" operation attribute set to 'true' before it starts to "process" the job? 🤨
It depends on the implementation 🫠. Some servers spool the entire job, including all the document data, before they start processing. Those servers would wait for the "last-document" before processing the job. If the time-out happens without the "last-document", then the server takes one of the actions indicated in section 3.3.1 in the [RFC2911] document 😬. Other servers start processing document data as soon as they have some. These are the so-called "non-spooling" printers ⚡. Right now there isn't a way for a client to tell whether the Printer will spool all the data or start processing (and printing) as soon as it has some 🤷♀️✨.
3.3 Job Operations
3.3.1 Validate-Job
Validate-Job is designed so its implementation can be part of the Print-Job operation 🧩. That means requiring Validate-Job isn't a burden on implementers 💅. It's also useful for clients to be able to count on it being in every conformant implementation, so a client can check whether the IPP Printer will accept the job before sending a long document 🎀. Iconic planning, honestly 👑.
3.3.2 Restart-Job
Restart-Job lets you reprocess a completed job 🔁. Some jobs store the document data on the printer. Jobs created with the Print-Job operation are an example. It is required that the printer keeps the job data after the job moves to a 'completed' state, so that Restart-Job can succeed 🫶.
Some jobs only contain a reference to the job data. A job created using Print-URI is an example of that 🔗. When Restart-Job is issued, the job is reprocessed. The job data MUST be retrieved again in order to print the job 🖨️.
It's possible that a job fails while trying to access the print data 😵. When a job like that is the target of a Restart-Job, the Printer SHALL attempt to retrieve the job data again 💜.
4 Object Attributes ✨
4.1 Attribute Syntax's
4.1.1 The 'none' value for empty sets (Issue 1.37)
[RFC2911] states that the 'none' value should be used as the value of a 1setOf when the set is empty 🙃. In most cases, sets that might be empty contain keywords, so the keyword 'none' is used. But for the 3 finishings attributes, the values are enums, so the empty set is represented by the enum 3 🌸. There are currently no other attributes with 1setOf values that can be empty and can contain values that aren't keywords. This exception needs special code and is a potential place for bugs 🐛. It would have been better to pick an out-of-band value, either "no-value" or some new value such as 'none' 😩. Since that didn't happen, implementations have to deal with the different representations of 'none', depending on the attribute syntax 💀.
4.1.2 Multi-valued attributes (Issue 1.31)
what is the attribute syntax for a multi-valued attribute? 🧐 Some attributes support values in more than one data type, like "media", "job-hold-until", and "job-sheets". So IPP semantics associate the attribute syntax with each value, not with the attribute as a whole 🦋. The protocol attaches the attribute syntax tag to each value. Don't be fooled just because the attribute syntax tag comes before the attribute keyword 🙈. Every attribute value after the first has a zero-length attribute keyword, and that's how you know it's another value of the same attribute 🫶✨.
4.1.3 Case Sensitivity in URIs (issue 1.6) 🔤✨
okay bestie, IPP client and server implementations NEED to be aware that URIs are wildly inconsistent about uppercase and lowercase 😭. RFC 2396 says URL schemes and Host names are case insensitive, but it also warns that the rest of the URL may totally be case sensitive 🙈. When you're making URLs for fields where the choice is completely arbitrary, it's probably best to pick lower case 🍓. BUT that can't be guaranteed, so implementations MUST NOT rely on any fields being case-sensitive or case-insensitive in the URL beyond the URL scheme and host name fields 💅.
The reason the IPP specification doesn't put any restrictions on URIs is so implementations can use off-the-shelf components that already follow the standards that define URIs, like RFC 2396 and the HTTP/1.1 specifications [RFC2616] 🧚. Check those specs for the rules on matching, comparison, and case-sensitivity, they've got you 🫶.
It's also recommended that System Administrators and implementations avoid creating URLs for different printers that differ only in their case 🌸. For example, don't have Printer1 and printer1 as two different IPP Printers 😭🖨️.
Example of equivalent URI's:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http:/ABC.com:/%7esmith/home.htmlExample of equivalent URI's using the IPP scheme:
ipp://abc.com:631/~smith/home.html
ipp://ABC.com/%7Esmith/home.html
http:/ABC.com:631/%7esmith/home.htmlThe HTTP/1.1 specification [RFC2616] has more details on comparing URLs, so go read it if you're curious 🦋.
4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage 📏💖
okay so the 'textWithLanguage' and 'nameWithLanguage' syntaxes are compound, meaning they have two parts 🎀. The first part is the 'language' component, which can hold up to 63 octets. The second part is the 'text' or 'name' component. The max lengths are 1023 octets for 'text' and 255 octets for 'name' 🙌. Some attributes can restrict the length even more when they're defined. For example, printer-name (name(127)) 💅.
The length of the 'language' component has zero effect on how long 'text' can be in 'textWithLanguage', or how long 'name' can be in 'nameWithLanguage' 🌈. Separate lanes, no drama ✨.
4.2. Job Template Attributes 🎀
4.2.1 multiple-document-handling(type2 keyword) 📄
4.2.1.1 Support of multiple document jobs 📚
IPP/1.0 was silent on which of the four effects an implementation would perform if it supported Create-Job but did not support "multiple-document-handling" or multiple documents per job 🤷♀️. IPP/1.1 changed things so a Printer could support Create-Job without having to support multiple document jobs 💜. The "multiple-document-jobs-supported" (boolean) Printer description attribute was added to IPP/1.1, along with the 'server-error-multiple-document-jobs-not-supported' status code. These let a Printer say whether or not it supports multiple document jobs, when it supports the Create-Job operation 🫶. IPP/1.1 also clarified that the Printer MUST support the "multiple-document-handling" (type2 keyword) Job Template attribute with at least one value if the Printer supports multiple documents per job 👑.
4.3. Job Description Attributes 🧾
4.3.1 Getting the date and time of day ⏰
The "date-time-at-creation", "date-time-at-processing", and "date-time-at-completed" attributes are returned as dateTime syntax 🗓️. These attributes are OPTIONAL for a Printer to support. BUT there are a bunch of ways a Printer can get the date and time of day, so here are some suggestions 💅:
- A Printer can get time from an NTP timeserver if there's one reachable on the network . See RFC 1305. Also DHCP option 32 in RFC 2132 returns the IP address of the NTP server 🛰️.
- Get the date and time at startup from a human operator 🧑💻.
- Have an operator set the date and time using a web administrative interface 🌐.
- Get the date and time from incoming HTTP requests, though the problems of spoofing need to be considered 🕵️♀️. Perhaps comparing several HTTP requests could reduce the chances of spoofing 🧠.
- Internal date time clock battery driven 🔋.
- Query
http://tycho.usno.navy.mil/cgi-bin/timer.pl🕰️.
4.4. Printer Description Attributes 🖨️💖
4.4.1 queued-job-count (integer(0:MAX)) 🔢
4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? 🤔
The reason "queued-job-count" is RECOMMENDED is that some clients look at that attribute alone when summarizing the status of a list of printers, instead of doing a Get-Jobs to find out how many jobs are in the queue 📋. Implementations that fail to support "queued-job-count" will make that client display 0 jobs when there are actually queued jobs 😭.
We would have made it a REQUIRED Printer attribute, but some implementations were already finished before the issue was raised, so making it a SHOULD was a compromise 🤝. Honestly, that's very mature of everyone involved 🥹.
4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is (Issue 1.15)? 🚦
The "queued-job-count" is not a good measure of how busy the printer is when there are held jobs 🙅♀️. A future registration could add a "held-job-count" (or an "active-job-count") Printer Description attribute, if experience shows that such an attribute (or combination) is needed to quickly indicate how busy a printer really is 📈. Watch this space 👀✨.
4.4.2 printer-current-time (dateTime) 🕐
A Printer implementation MAY support this attribute by obtaining the date and time by any number of implementation-dependent means, at startup or subsequently 🌙. Examples include:
- an internal date time clock,
- from the operator at startup using the console,
- from an operator using an administrative web page,
- from HTTP headers supplied in client requests,
- use HTTP to query
http://tycho.usno.navy.mil/cgi-bin/timer.pl - from the network, using NTP [RFC1305] or DHCP option 32 [RFC2132] that returns the IP address of the NTP server.
If an implementation supports this attribute by getting the current time from the network (at startup or later), but the time isn't available, then the implementation MUST return the value of this attribute using the out-of-band 'no-value' meaning not configured 😱. See the beginning of section 4.1 🔙.
Since the new "date-and-time-at-xxx" Job Description attributes refer to the "printer-current-time", they'll be covered too 💅✨.
4.4.3 Printer-uri 🔗
Must the operational attribute for printer-uri match one of the values in "printer-uri-supported"? 🧐
A forgiving printer implementation would not reject the operation 🥰. BUT the implementation has its rights to reject a printer or job operation if the operational attribute printer-uri is not a value of the printer-uri-supported 🚫. The printer might not be improperly configured, and the request obviously reached the printer 📬. The printer could treat the printer-uri as the logical equivalent of a value in the printer-uri-supported 🪞. Which value, and which associated security policy, would apply is implementation dependent 🛡️. This also applies to a job object specified with a printer-uri and job-id, or with a job-uri. See section 4.1.3 for how to compare URI's 🔍.
4.5. Empty Jobs 🫙
The IPP object model does not prohibit a job that contains no documents 📭. Such a job may be created in a number of ways, including a 'create-job' followed by an 'add-document' that contains no data and has the 'last-document' flag set 🧃.
An empty job is processed just like any other job ✨. The operation that "closes" an empty job is not rejected just because the job is empty 🙌. If no other conditions exist, other than the job being empty, the response to the operation will indicate success 🥳. After the job is scheduled and processed, the job state SHALL be 'completed' 🏁.
There will be some variation in the value(s) of the "job-state-reasons" attribute 🌈. It is required that if no conditions, other than the job being empty, exist, the "job-state-reasons" SHALL include 'completed-successfully' 💯. If other conditions existed, the 'completed-with-warnings' or 'completed-with-errors' values may be used ⚠️.
5 Directory Considerations 📂💜
5.1 General Directory Schema Considerations 🗂️
The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object attributes for directory schemas 📜. See [RFC2911] APPENDIX E: Generic Directory Schema 📖.
The SLP printer template is defined in the "Definition of the Printer Abstract Service Type v2.0" document [svrloc-printer] 🧩. The LDAP printer template is defined in the "Internet Printing Protocol (IPP): LDAP Schema for Printer Services" document [ldap-printer] 🧩. Both documents systematically add "printer-" to any attribute that doesn't already start with "printer-", so the printer directory attributes stay distinct from other directory attributes 🏷️. Also, instead of using "printer-uri-supported", "uri-authentication-supported", and "uri-security-supported", they use a "printer-xri-supported" attribute with special syntax to hold all of the same information in a single attribute 🎁.
5.2 IPP Printer with a DNS name 🌐
If the IPP printer has a DNS name, should there be at least two values for the printer-uri-supported attribute? One URL with the fully qualified DNS name, the other with the IP address in the URL? 🤨 The printer may contain one or the other, or both. It's up to the administrator to configure this attribute 🧑🔧💅.
6 Security Considerations 🔐🚨
The security considerations given in [RFC2911] Section 8 "Security Considerations" all apply to this document 🛡️. In addition, the following sub-sections describe security considerations that have arisen as a result of implementation testing 😱🔥. Those are next, bestie, so stay tuned 👀💖.
6.1. Querying jobs with IPP that were submitted using other job submission protocols (Issue 1.32) 🎀
okay so this one is a clarification that got added to [RFC2911] section 8.5 💅 It's about jobs that came in through other job submission protocols, not IPP, and how you can still ask about them. bestie this is lowkey so iconic 🦋
The clarification basically says: if the device behind an IPP Printer can take jobs through other protocols too, it is RECOMMEND that it at least lets those "foreign" jobs be queried with Get-Jobs, returning "job-id" and "job-uri" as 'unknown'. It doesn't have to support every IPP job attribute for foreign jobs 🌸 The IPP object just hands back the 'unknown' out-of-band value for any requested attribute that IPP jobs get but foreign jobs don't.
It is further RECOMMENDED that the IPP Printer generate "job-id" and "job-uri" values for those foreign jobs, if possible, so they can be targets of other IPP operations, like Get-Job-Attributes and Cancel-Job 🔥
Now the authentication part, which is the spicy bit 🙈 The implementation also has to deal with who owns these foreign jobs. One approach is to treat all of them as belonging to users other than the user of the IPP client. Another is to have 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. Or, 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 👑
So yeah, IPP MAY be implemented as a "universal" protocol that gives access to jobs submitted with any job submission protocol ✨ And as IPP gets more widely implemented, a more universal access just makes sense 💜
7. Encoding and Transport ✨
okay now we're in the transport zone 🧚 This section talks about bits of IPP/1.1 Encoding and Transport [RFC2910].
A server is not required to send a response until after it has received the client's entire request. Hence, a client must not expect a response until after it has sent the entire request. However, we recommend that the server return a response as soon as possible if an error is detected while the client is still sending the data, rather than waiting until all of the data is received. Therefore, we also recommend that a client listen for an error response that an IPP server MAY send before it receives all the data 👀 In that case, a client that is chunking the data can send a premature zero-length chunk to end the request before sending all the data. That way the client can keep the connection open for other requests, rather than closing it 🫶 And if the request is blocked for some reason, a client MAY figure out the reason by opening another connection to query the server using Get-Printer-Attributes.
IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to throttle clients when Printers are busy 🌈 So it is perfectly normal for an IPP client transmitting a Job to be blocked for a really long time. Accordingly, socket timeouts must be avoided. Some socket implementations have a timeout option, which specifies how long a write operation on a socket can be blocked before it times out and the blocking ends. A client should set this option for infinite timeout when transmitting Job submissions 🍓
Some IPP client apps can get other useful work done while a Job transmission is blocked. For example, the client may have other jobs it could transmit to other Printers at the same time. A client may also have a GUI, which must stay responsive to the user while the Job transmission is blocked. These clients should be designed to spawn a thread to handle the Job transmission at its own pace, leaving the main application free to do other work. Alternatively, single-threaded applications could use non-blocking I/O 💅
Some Printer conditions, like a jam or lack of paper, could cause a client to be blocked indefinitely 😭 Clients may open additional connections to the Printer to Get-Printer-Attributes, figure out the state of the device, alert a user if the printer is stopped, and let a user decide whether to abort the job transmission or not.
In the following sections there are tables of all HTTP headers, showing how they're used in an IPP client or server. Here's what each column means 💖
- the "header" column contains the name of a header
- the "request/client" column indicates whether a client sends the header.
- the "request/ server" column indicates whether a server supports the header when received.
- the "response/ server" column indicates whether a server sends the header.
- the "response /client" column indicates whether a client supports the header when received.
- the "values and conditions" column specifies the allowed header values and the conditions for the header to be present in a request/response.
The table for "request headers" doesn't have columns for responses, and the table for "response headers" doesn't have columns for requests 🎀
Here's what the values in the "request/client" and "response/ server" columns mean ✨
- must: the client or server MUST send the header,
- must-if: the client or server MUST send the header when the condition described in the "values and conditions" column is met,
- may: the client or server MAY send the header
- not: the client or server SHOULD NOT send the header. It is not relevant to an IPP implementation.
And the values in the "response/client" and "request/ server" columns 🌸
- must: the client or server MUST support the header,
- may: the client or server MAY support the header
- not: the client or server SHOULD NOT support the header. It is not relevant to an IPP implementation.
7.1. General Headers 🦋
okay here's the general headers table, verbatim, no cap 💅
General- Request Response Values and Conditions
Header
Client Server Server Client
Cache- not must not "no-cache" only
Control must
Connection must- must must- must "close" only. Both
if if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
for the last operation
in such a sequence.
Date may may must may per RFC 1123 [RFC1123]
from RFC 2616
[RFC2616]
Pragma must not must not "no-cache" only
Transfer- must- must must- must "chunked" only. Header
Encoding if if MUST be present if
Content-Length is
absent.
Upgrade not not not not
Via not not not not7.2. Request Headers 💜
the request headers table is next, and it's giving detailed 😭
Request- Client Server Request Values and Conditions
Header
Accept may must "application/ipp" only. This
value is the default if the
client omits it
Accept- not not Charset information is within the
Charset application/ipp entity
Accept- may must empty and per RFC 2616 [RFC2616]
Encoding and IANA registry for content-
codings
Accept- not not language information is within the
Language application/ipp entity
Authorization must- must per RFC 2616. A client MUST send
if this header when it receives a
401 "Unauthorized" response and
does not receive a "Proxy-
Authenticate" header.
From not not per RFC 2616. Because RFC
recommends sending this header
only with the user's approval,
it is not very useful
Host must must per RFC 2616
If-Match not not
If-Modified- not not
Since
If-None-Match not not
If-Range not not
If- not not
Unmodified-
Since
Request- Client Server Request Values and Conditions
Header
Max-Forwards not not
Proxy- must- not per RFC 2616. A client MUST send
Authorizati if this header when it receives a
on 401 "Unauthorized" response and
a "Proxy-Authenticate" header.
Range not not
Referrer not not
User-Agent not not7.3. Response Headers ✨
and last but not least, the response headers table 🧚 (yes, it says "request headers" at the top. the original does that too, so we're keeping it as is 🙈)
Response- Server Client Response Values and Conditions
Header
Accept-Ranges not not
Age not not
Location must- may per RFC 2616. When URI needs
if redirection.
Proxy- must per RFC 2616
Authenticat
e not
Public may may per RFC 2616
Retry-After may may per RFC 2616
Server not not
Vary not not
Warning may may per RFC 2616
WWW- must- must per RFC 2616. When a server needs
Authenticate if to authenticate a client.7.4 Entity Headers ✨
okay bestie, here's the entity headers table 💅 it's giving spreadsheet, but it's the good kind. Each row is one entity header and each column tells you who's allowed to do what with it, for requests and responses, on the client side and the server side. The last column has the conditions and notes 🧚
Entity-Header Request Response Values and
Conditions
Client Server Server Client
Allow not not not not
Content-Base not not not not
Content- may must must must per RFC 2616 and
Encoding IANA registry for
content codings.
Content- not not not not Application/ipp
Language handles language
Content- must- must must- must the length of the
Length if if message-body per
RFC 2616. Header
MUST be present
if Transfer-
Encoding is
absent..
Content- not not not not
Location
Content-MD5 may may may may per RFC 2616
Content-Range not not not not
Content-Type must must must must "application/ipp"
only
ETag not not not not
Expires not not not not
Last-Modified not not not not7.5 Optional support for HTTP/1.0 🌸
okay so IPP implementations are made of two layers, an HTTP layer and an IPP layer 🎀 in this part, "client" means the HTTP client layer and "server" means the HTTP server layer. The Encoding and Transport document [RFC2910] says HTTP 1.1 MUST be supported by all clients and all servers, no exceptions 🫶 but a client and/or a server is allowed to also support HTTP 1.0 if it wants, which is lowkey a cute little bonus.
if a server decides to support HTTP 1.0, it can talk to a (non-conforming) client that only does HTTP 1.0. in that case the server should not use any HTTP 1.1 specific parameters or features, and it should answer with HTTP version number 1.0 🦋
the same goes the other way. a client can choose to talk to a (non-conforming) server that only does HTTP 1.0. if that server replies with an HTTP 'unsupported version number' to an HTTP 1.1 request, the client should retry using HTTP version number 1.0 💜
7.6 HTTP/1.1 Chunking 🍓
7.6.1 Disabling IPP Server Response Chunking
okay, main character moment: clients MUST anticipate that the HTTP/1.1 server might chunk its responses, and clients MUST accept them 🙈 but, and this is the tea ☕, a (non-conforming) HTTP client that can't accept chunked responses is allowed to ask an HTTP 1.1 server not to chunk its response to an operation, by sending this HTTP header:
TE: identityservers should not use this to stop a client from chunking a request, because chunking document data is a really important feature for clients that send long documents 📄💖
7.6.2 Warning About the Support of Chunked Requests 💀
this section is a heads up about some problems with chunked requests and HTTP/1.1 servers. so the HTTP/1.1 standard [RFC2616] says conforming servers have to support chunked requests for any method. the plot twist is that some HTTP/1.1 servers only handle chunked responses for GET, and they don't handle chunked POST requests 😭 some servers that run CGI scripts [CGI] and/or servlets [Servlet] insist that the client sends a Content-Length. those might reject a chunked POST with a 411 status code (Length Required), or try to buffer the request and run out of room and return a 413 status code (Request Entity Too Large), or they might just accept the chunked request and be chill about it 🌈
because of that gap between HTTP servers and the HTTP/1.1 standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP Printer object implementation supports chunked requests, and that conforming clients accept chunked responses 👑 so IPP object implementers are warned to look for HTTP server implementations that support chunked POST requests, so they can conform to the IPP standard, and/or use implementation techniques that support chunked POST requests 🧚
8 References 📚
okay here are all the references, copied exactly so nothing gets lost in translation 🫶
[CGI] CGI/1.1 (http://www.w3.org/CGI/).
[IANA-CS] IANA Registry of Coded Character Sets:
http://www.iana.org/assignments/character-sets
[ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald,
"Internet Printing Protocol (IPP): LDAP Schema for
Printer Services", Work in Progress.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", RFC 1123, October, 1989.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119 , March 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
and P. Powell, "Internet Printing Protocol/1.0:
Model and Semantics", RFC 2566, April 1999.
[RFC2566] Herriot, R., Butler, S., Moore, P. and R. Turner,
"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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee,
"Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
June 1999.
[RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2910, September, 2000.
[RFC2911] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
and P. Powell, "Internet Printing Protocol/1.0:
Model and Semantics", RFC 2911, September, 2000.
[Servlet] Servlet Specification Version 2.1
(http://java.sun.com/products/servlet/2.1/
index.html).
[svrloc-printer] St. Pierre, P., Isaacson, S., McDonald, I.,
"Definition of the Printer Abstract Service Type
v2.0", http://www.isi.edu/in-
notes/iana/assignments/svrloc-
templates/printer.2.0.en (IANA Registered, May 27,
2000).
[SSL] Netscape, The SSL Protocol, Version 3, (Text
version 3.02), November 1996.9. Authors' Addresses ✨
Here are the people who wrote this spec, with their addresses and emails, so you know exactly who to bug 💖
Thomas N. Hastings
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
EMail: hastings@cp10.es.xerox.com
Carl-Uno Manros
Independent Consultant
1601 N. Sepulveda Blvd. #505
Manhattan Beach, CA 90266
Email: carl@manros.com
Carl Kugler
Mail Stop 003G
IBM Printing Systems Co
6300 Diagonal Hwy
Boulder CO 80301
EMail: Kugler@us.ibm.com
Henrik Holst
i-data Printing Systems
Vadstrupvej 35-43
2880 Bagsvaerd, Denmark
EMail: hh@I-data.com
Peter Zehler
Xerox Corporation
800 Philips Road
Webster, NY 14580
EMail: PZehler@crt.xerox.com
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.orgWant to join the IPP mailing list? Here's how to subscribe, it's giving very simple 🧚
- Send it to
majordomo@pwg.org - Leave the subject line blank
- Put the following two lines in the message body:
subscribe ipp
endImplementers of this specification document are encouraged to join the IPP Mailing List, bestie 🦋 It's where people chat about clarification issues and review registration proposals for new attributes and values. The list is anti-spam, so it rejects mail from non-subscribers. That means you must subscribe before you can send a question or comment. No shortcuts, periodt 🙈
Other participants (the whole squad 🌈):
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Dennis Carney - IBM
Imaging Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Toshiba Lloyd Young - Lexmark
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang- Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon
Information Systems10. Description of the Base IPP Documents 📚
Okay, so this document isn't alone, lowkey it's part of a whole family 👑 The base 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.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Mapping between LPD and IPP Protocols [RFC2569]The "Design Goals for an Internet Printing Protocol" doc is the big-picture one 🌸 It looks at distributed printing and walks through real-life scenarios to figure out what a printing protocol for the Internet actually needs. It sorts requirements into three types of users: end users, operators, and administrators. It pulls out a subset of end user requirements that are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator operations were added to IPP/1.1 [RFC2911, RFC2910], which is giving extra flexibility ✨
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" doc describes IPP from a high-level view 🦋 It maps out the roadmap for the whole suite of IPP specification documents, and it explains the background and reasoning behind the IETF IPP working group's major decisions. Main character origin story, honestly 💜
The "Internet Printing Protocol/1.1: Model and Semantics" doc describes a simplified model with abstract objects, their attributes, and their operations. It introduces a Printer and a Job, and the Job supports multiple documents per Job. It also covers how security, internationalization, and directory issues are handled. The model is the foundation everything else is built on, so it's a must-read 🎀
The "Internet Printing Protocol/1.1: Encoding and Transport" doc is the formal mapping of the abstract operations and attributes from the model doc onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called "application/ipp". It also sets the rules for transporting a message body over HTTP whose Content-Type is application/ipp. And it defines the ipp scheme for identifying IPP printers and jobs 🧚
The "Mapping between LPD and IPP Protocols" doc gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations 🍓
11. Full Copyright Statement 💖
Copyright (C) The Internet Society (2001). All Rights Reserved.
Okay, the legal bit, but make it cute. Copies of this document and its translations can be shared and handed to others. You can also make derivative works that comment on or explain it, or that help with implementing it, and you can publish and distribute those in whole or in part with no restrictions at all. The one condition is that the copyright notice and this paragraph stay on every copy and every derivative work 🌈
This document itself may not be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can make changes when you're developing Internet standards (in which case you must follow the copyright procedures defined in the Internet Standards process), or you can translate it into languages other than English 🫶
These permissions are perpetual, and the Internet Society or its successors or assigns won't revoke them.
Now the warranty part, which has to stay exactly as written 😭
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3196 2001-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms