RFC 3998
Internet Printing Protocol (IPP): Job and Printer Administrative Operations
Part 1 of 10 🎀
RFC 3998 Title Block 🌸
Internet Printing Protocol (IPP): Job and Printer Administrative Operations is RFC 3998, and it's a Standards Track doc, so it's a real spec, not a vibe. It came out in March 2005 from the Network Working Group.
The authors are C. Kugler and H. Lewis from IBM Corporation, plus T. Hastings (the Ed.) from Xerox Corporation. Ed. just means they were the editor who pulled it all together. 💅
The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there. 🦋
Status of This Memo ✨
This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions to make it better 🫶 If you want to know where this protocol stands officially, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💜
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract 🔥
Okay so this doc adds 16 extra OPTIONAL system administration operations on top of the Internet Printing Protocol/1.1 (IPP) 😭 It also throws in a few attributes, values, and status codes, and it uses the IPP Printer object to manage printer fan-out and fan-in. Main character energy, honestly.
Here's the lineup, split into printer ops and job ops:
Printer operations: Job operations:
Enable-Printer and Disable-Printer Reprocess-Job
Pause-Printer-After-Current-Job Cancel-Current-Job
Hold-New-Jobs and Release-Held-New-Jobs Suspend-Current-Job
Deactivate-Printer and Activate-Printer Resume-Job
Restart-Printer Promote-Job
Shutdown-Printer and Startup-Printer Schedule-Job-AfterTable of Contents 📖
1. Introduction.................................................. 4
2. Terminology................................................... 4
2.1. Conformance Terminology................................. 4
2.2. Other Terminology....................................... 5
3. Definition of the Printer Operations.......................... 6
3.1. The Disable and Enable Printer Operations............... 7
3.1.1. Disable-Printer Operation....................... 7
3.1.2. Enable-Printer Operation........................ 8
3.2. The Pause and Resume Printer Operations................. 8
3.2.1. Pause-Printer-After-Current-Job Operation....... 9
3.3. Hold and Release New Jobs Operations.................... 11
3.3.1. Hold-New-Jobs Operation......................... 11
3.3.2. Release-Held-New-Jobs Operation................. 12
3.4. Deactivate and Activate Printer Operations.............. 12
3.4.1. Deactivate-Printer Operation.................... 13
3.4.2. Activate-Printer Operation...................... 13
3.5. Restart-Printer, Shutdown-Printer,
and Startup-Printer Operations.......................... 14
3.5.1. Restart-Printer Operation....................... 14
3.5.2. Shutdown-Printer Operation...................... 14
3.5.3. Startup-Printer Operation....................... 15
4. Definition of the Job Operations.............................. 16
4.1. Reprocess-Job Operation................................. 17
4.2. Cancel-Current-Job Operation............................ 17
4.3. Suspend and Resume Job Operations....................... 18
4.3.1. Suspend-Current-Job Operation................... 19
4.3.2. Resume-Job Operation............................ 20
4.4. Job Scheduling Operations............................... 20
4.4.1. Promote-Job Operation........................... 20
4.4.2. Schedule-Job-After Operation.................... 21
5. Additional Status Codes....................................... 23
5.1. 'server-error-printer-is-deactivated' (0x050A).......... 23
6. Use of Operation Attributes
That Are Messages from the Operator........................... 23
7. New Printer Description Attributes............................ 26
7.1. subordinate-printers-supported (1setOf uri)............. 26
7.2. parent-printers-supported (1setOf uri).................. 26
8. Additional Values for
the "printer-state-reasons" Printer Description Attribute..... 26
8.1. 'hold-new-jobs' Value................................... 27
8.2. 'deactivated' Value..................................... 27
9. Additional Values for
the "job-state-reasons" Job Description attribute............. 27
9.1. 'job-suspended' Value................................... 27
10. Use of the Printer Object to Represent
IPP Printer Fan-Out and IPP Printer Fan-In.................... 27
10.1. IPP Printer Fan-Out..................................... 28
10.2. IPP Printer Fan-In...................................... 28
10.3. Printer Object Attributes Used
to Represent Printer Fan-Out and Printer Fan-In......... 29
10.4. Subordinate Printer URI................................. 29
10.5. Printer Object Attributes Used
to Represent Output Device Fan-Out...................... 30
10.6. Figures to Show All Possible Configurations............. 30
10.7. Forwarding Requests..................................... 33
10.7.1. Forwarding Requests
that Affect Printer Objects..................... 33
10.7.2. Forwarding Requests that Affect Jobs............ 35
10.8. Additional Attributes to Help with Fan-Out.............. 37
10.8.1. output-device-assigned (name(127))
Job Description Attribute - from [RFC2911]...... 37
10.8.2. original-requesting-user-name (name(MAX))
Operation and Job Description Attribute......... 37
10.8.3. requesting-user-name (name(MAX))
Operation Attribute - Additional Semantics...... 38
10.8.4. job-originating-user-name (name(MAX))
Job Description Attribute -
Additional Semantics............................ 38
11. Conformance Requirements...................................... 38
12. Normative References.......................................... 39
13. Informative References........................................ 40
14. IANA Considerations........................................... 40
14.1. Attribute Registrations................................. 41
14.2. Attribute Value Registrations........................... 41
14.3. Additional Enum Attribute Value Registrations........... 41
14.4. Operation Registrations................................. 42
14.5. Status Code Registrations............................... 43
15. Internationalization Considerations........................... 43
16. Security Considerations....................................... 43
17. Summary of Base IPP Documents................................. 44
Authors' Addresses................................................ 45
Full Copyright Statement.......................................... 46List of Tables 🧚
Table 1. Printer Operation Operation-Id Assignments.............. 6
Table 2. Pause and Resume Printer Operations..................... 9
Table 3. State Transition Table for
Pause-Printer-After-Current-Job Operation............... 10
Table 4. Job Operation Operation-Id Assignments.................. 16
Table 5. Operation Attribute Support for Printer Operations...... 24
Table 6. Operation Attribute Support for Job Operations.......... 25
Table 7. Forwarding Operations that Affect Printer Objects....... 34
Table 8. Forwarding Operations that Affect Jobs Objects.......... 36
Table 9. Conformance Requirement Dependencies for Operations..... 38
Table 10. Conformance Requirement Dependencies
for "printer-state-reasons" Values...................... 39
Table 11. Conformance Requirement Dependencies
for "job-state-reasons" Values.......................... 39List of Figures 🌈
Figure 1. Embedded Printer Object................................ 31
Figure 2. Hosted Printer Object.................................. 31
Figure 3. Output Device Fan-Out.................................. 31
Figure 4. Chained IPP Printer Objects............................ 32
Figure 5. IPP Printer Object Fan-Out............................. 32
Figure 6. IPP Printer Object Fan-In.............................. 331. Introduction ✨
Okay so the Internet Printing Protocol (IPP) is an application level protocol that lets you do distributed printing using Internet tools and technologies 🖨️ IPP version 1.1 ([RFC2911, RFC2910]) is all about end-user stuff, with just a few admin operations sprinkled in.
This doc defines extra operations for end users, operators, and administrators to control Jobs and Printers. Those are OPTIONAL, so you only need them if you're into them 🌸 It also extends the Printer object's semantic model so printers can be set up as trees and/or inverted trees. Those represent Printer object Fan-Out and Printer object Fan-In, respectively. A tree with only a single Subordinate node is the special case called Chained Printers. Iconic. 🦋
Last bit: this doc is a registration proposal for an extension to IPP/1.0 and IPP/1.1, and it follows the registration procedures in those docs 💜
The requirements and use cases for all of this live in [RFC3239] 🫶
2. Terminology 💅
This section defines the terminology used throughout this document, so you're never guessing what a word means 🎀
2.1. Conformance Terminology
Capitalized terms such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL have special meaning for conformance, as defined in RFC 2119 [RFC2119] and [RFC2911], section 12.1 🔥 If an implementation supports the extension defined in this document, then these terms apply to it. If it doesn't, they don't. These terms only define conformance to this document, and they don't affect conformance to other documents, unless a document explicitly says otherwise ✨
2.2. Other Terminology ✨
okay so this doc throws around words like "client", "Printer", "Job", "attributes", "keywords", "operation", and "support" 💅 they're not random vibes tho. They have special meanings, and those are defined in the model terminology over in ([RFC2911], section 12.2) 🎀
On top of that, these capitalized terms get their own definitions:
- IPP Printer object (or Printer for short) - A software abstraction defined by [RFC2911]. 🖨️
- Printer Operation - An operation whose target is an IPP Printer object and whose effect is on the Printer object. 💜
- Output Device - The physical imaging mechanism that an IPP Printer controls. Note: although this term is capitalized in this specification (but not in [RFC2911]), there is no formal object called an Output Device defined in this document (or in [RFC2911]). 🙈
- Output Device Fan-Out - A configuration in which an IPP Printer controls more than one Output Device. 🌸
- Printer Fan-Out - A configuration in which an IPP Printer object controls more than one Subordinate IPP Printer object. 🦋
- Printer Fan-In - A configuration in which an IPP Printer object is controlled by more than one IPP Printer object. 🧚
- Subordinate Printer - An IPP Printer object that is controlled by another IPP Printer object. Such a Subordinate Printer MAY have zero or more Subordinate Printers. 🍓
- Leaf Printer - An IPP Printer object that has no Subordinate Printers. 🍃
- Non-Leaf Printer - An IPP Printer object that has one or more Subordinate Printers. A Non-Leaf Printer is also called a Parent Printer. 👑
- Chained Printer - A Non-Leaf Printer that has exactly one Subordinate Printer. ⭐
- Job Creation operations - IPP operations that create a Job object: Print-Job, Print-URI, and Create-Job. ✨
3. Definition of the Printer Operations ✨
Every Printer Operation is aimed at Printer objects, and that's non-negotiable 💅 A client MUST always supply the "printer-uri" operation attribute so the operation knows exactly which Printer it's hitting. These descriptions also assume all the common semantics from the IPP/1.1 Model and Semantics document ([RFC2911], section 3.1), so you get the whole shared vocab without it being repeated here 🫶
The Printer Operations defined in this document are summarized in Table 1. Think of it as the cheat sheet 🎀
Table 1. Printer Operation Operation-Id Assignments
Operation Name Operation-Id Brief Description
--------------------------------------------------------------------
Enable-Printer 0x22 Allows the target Printer to accept
Job Creation operations.
Disable-Printer 0x23 Prevents the target Printer from
accepting Job Creation operations.
Pause-Printer- 0x24 Pauses the Printer after the current
After-Current- job has been sent to the Output
Job Device.
Hold-New-Jobs 0x25 Finishes processing all currently
pending jobs. Any new jobs are
placed in the 'pending-held' state.
Release-Held- 0x26 Releases all jobs to the 'pending'
New-Jobs state that had been held by the
effect of a previous Hold-New-Jobs
operation and condition the Printer
so that it no longer holds new jobs.
Deactivate- 0x27 Puts the Printer into a read-only
Printer deactivated state.
Activate- 0x28 Restores the Printer to normal
Printer activity.
Restart-Printer 0x29 Restarts the target Printer and re-
initializes the software.
Shutdown- 0x2A Shuts down the target Printer so that
Printer it cannot be restarted or queried.
Startup-Printer 0x2B Starts up the instance of the Printer
object.All of the operations in this document are OPTIONAL for an IPP object to support. Unless the spec of an OPTIONAL operation requires support of another OPTIONAL operation, conforming implementations may support any combination of these operations. Lots of these come in pairs, so if you implement one, BOTH are REQUIRED 🥹
3.1. The Disable and Enable Printer Operations 🚦
This section defines the OPTIONAL Disable-Printer and Enable-Printer operations. They're the ones that stop and start an IPP Printer object from accepting new IPP jobs. If either of these operations is supported, both MUST be supported 💅
These operations let the operator decide whether the Printer will accept new Job Creation operations (Print-Job, Print-URI, and Create-Job). That's their whole deal. Otherwise they don't touch the Printer at all, so it keeps accepting every other operation and keeps scheduling and processing jobs like normal 🌈 In other words, these two control the "input of new jobs" into the IPP Printer, while the Pause and Resume operations (see section 3.2) handle the "output of new jobs" going to the Output Device. Two separate switches, no drama 🙌
3.1.1. Disable-Printer Operation 🙅♀️
This OPTIONAL operation lets a client stop the Printer object from accepting new jobs. It makes the Printer reject later Job Creation operations and return the server-error-not-accepting-jobs status code 😭 The Printer still accepts all the other operations, including Validate-Job, Send-Document, and Send-URI. So a client can keep sending the rest of a multiple document job if the Create-Job operation was already accepted, which is honestly so smart 🧠 Every job that was already created or submitted, plus anything currently processing, just keeps going unaffected ✨
The IPP Printer MUST accept the request in any state. The Printer sets its READ-ONLY Printer Description attribute "printer-is-accepting-jobs" to false (see [RFC2911], section 4.4.20), no matter what it was before. This operation has no immediate or direct effect on the Printer's "printer-state" and "printer-state-reasons" attributes 🫠
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911] sections 1 and 8.5). Only the right people get to flip this switch 🔐
The Disable-Printer Request and Disable-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2). That includes the new "printer-message-from-operator" operation attribute (see section 6). 💌
3.1.2. Enable-Printer Operation 🟢
This OPTIONAL operation lets a client start the Printer object accepting jobs again. It makes the Printer accept later Job Creation operations. The Printer still accepts all other operations, and every previously submitted job plus anything currently processing carries on unaffected 🌷
The IPP Printer MUST accept the request in any state. The Printer sets its READ-ONLY Printer Description attribute "printer-is-accepting-jobs" to true (see [RFC2911], section 4.4.20), no matter what it was before. Again, no immediate or direct effect on "printer-state" and "printer-state-reasons" ✨
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911] sections 1 and 8.5). Same energy as Disable, obviously 💅
The Enable-Printer Request and Enable-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.8.1 and 3.2.8.2). That includes the new "printer-message-from-operator" operation attribute (see section 6). 🎀
3.2. The Pause and Resume Printer Operations ⏸️
This section doesn't pin down the OPTIONAL IPP/1.1 Pause-Printer (see [RFC2911], sections 3.2.7). That one's kind of vague about whether the Printer stops right away or after the current job 🤷♀️ This section also defines the OPTIONAL Pause-Printer-After-Current-Job operation, which waits until the current job is done. These operations affect how IPP jobs get scheduled. If either of these Pause Printer operations is supported, then the Resume-Printer operation MUST be supported 💖
These operations let the operator decide whether the Printer keeps sending new IPP jobs to the Output Device(s) that the IPP Printer object represents. They don't do anything else to the Printer, so it keeps accepting all operations 🌸
Put simply, these control the "output of new jobs" to the Output Device(s), while the Disable and Enable Printer Operations (see section 3.1) independently control the "input of new jobs" to the IPP Printer. Input and output, two different dials 🎛️
Table 2. Pause and Resume Printer Operations
Pause and Resume Printers Description
--------------------------------------------------------------------
IPP/1.1 Pause Printer Stops the IPP Printer from sending
new IPP Jobs to the Output Device(s)
either immediately or after the
current job completes, depending on
implementation, as defined in
[RFC2911].
Pause-Printer-After- Stops the IPP Printer from sending
Current-Job new IPP Jobs to the Output Device(s)
after the current jobs finish.
Resume-Printer Starts the IPP Printer sending IPP
Jobs to the Output Device again.3.2.1. Pause-Printer-After-Current-Job Operation ✨
okay so this one is OPTIONAL 💖 and it lets a client tell the Printer object to stop sending IPP jobs to any of its Output Devices or Subordinate Printers 🛑. If the IPP Printer is already in the middle of sending an IPP job, it MUST complete sending that Job 🫶. But once it gets this operation, the IPP Printer MUST NOT send any additional IPP jobs to any of its Output Devices or Subordinate Printers 🚫. It also MUST NOT start processing any more jobs, so additional jobs MUST NOT enter the 'processing' state. no cap, that's a hard stop 💀
If the IPP Printer is not sending an IPP Job to the Output Device or Subordinate Printer (whether or not that device is busy processing stuff), the IPP Printer object goes straight to the 'stopped' state 🌸. It does this by setting its printer-state attribute to 'stopped', removing the 'moving-to-paused' value from its printer-state-reasons attribute if it's there, and adding the 'paused' value to printer-state-reasons. literally instant ✨
If the implementation will take appreciable time to finish sending an IPP job it already started sending to an Output Device or Subordinate Printer, the IPP Printer adds the 'moving-to-paused' value to the Printer object's printer-state-reasons attribute (see section [RFC2911], 4.4.12) 🦋. When the IPP Printer finishes sending the IPP jobs it was in the process of sending, the Printer object transitions to the 'stopped' state by setting printer-state to 'stopped', removing the 'moving-to-paused' value if it's present, and adding the 'paused' value to printer-state-reasons. the whole vibe is "finish what you started, then chill" 🍓
This operation MUST NOT affect the acceptance of Job Creation requests (see Disable-Printer Operation, section 3.1.1) 🙅
For any jobs that are 'pending' or 'pending-held', the 'printer-stopped' values of the jobs' job-state-reasons attribute also apply. However, the IPP Printer NEED NOT update those jobs' job-state-reasons attributes. It only has to return the 'printer-stopped' value when those jobs get queried using the Get-Job-Attributes or Get-Jobs operations (so-called "lazy evaluation") 😴 iykyk, the Printer is lazy and that's kinda iconic
The IPP Printer MUST accept the request in any state and transition the Printer to the indicated new printer-state, and it MUST add the indicated value to the printer-state-reasons attribute before returning, as follows:
Table 3. State Transition Table for Pause-Printer-After-Current-Job
Operation
Current New "printer IPP Printer's response status
"printer- "printer- -state- code and action (REQUIRED/
state" state" reasons" OPTIONAL state transition for
a Printer to support):
--------------------------------------------------------------------
'idle' 'stopped' 'paused' REQUIRED: 'successful-ok'
'processing' 'processing' 'moving- OPTIONAL: 'successful-ok';
to- Later, when the IPP Printer
has finished sending IPP jobs
to an Output Device, the
"printer-state" becomes
'stopped', and the 'paused'
value replaces the 'moving-to-
paused' value in the "printer-
state-reasons" attribute
'processing' 'stopped' 'paused' REQUIRED: 'successful-ok';
the IPP Printer wasn't in the
middle of sending an IPP job
to an Output Device
'stopped' 'stopped' 'paused' REQUIRED: 'successful-ok'Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5). 🔑
The Pause-Printer-After-Current-Job Request and Pause-Printer-After-Current-Job Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new "printer-message-from-operator" operation attribute (see section 6) 💌
3.3. Hold and Release New Jobs Operations ✨
this section is all about conditioning the Printer to hold any new jobs, and then letting them go 🎀
3.3.1. Hold-New-Jobs Operation ✨
This OPTIONAL operation lets a client condition the Printer to complete the current 'pending' and 'processing' IPP Jobs but not start processing any subsequently created IPP Jobs 🧊. If the IPP Printer is in the middle of sending an IPP job to an Output Device or Subordinate Printer, it MUST complete sending that Job 🫶. Furthermore, the IPP Printer MUST send all of the current 'pending' IPP Jobs to the Output Device(s) or Subordinate IPP Printer object(s) 📦. Any subsequently received Job Creation operations will cause the IPP Printer to put the Job into the 'pending-held' state, with the 'job-held-on-create' value added to the job's job-state-reasons attribute. so yeah, all newly accepted jobs get automatically held by the Printer 🙈
When the Printer completes all the 'pending' and 'processing' jobs, it enters the 'idle' state as usual ✨. An operator monitoring Printer state changes will know the Printer has finished all current jobs because it enters the 'idle' state 👀
This operation MUST NOT affect the acceptance of Job Creation requests (see Disable-Printer Operation, section 3.1.1), except to put the Jobs into the 'pending-held' state, instead of the 'pending' or 'processing' state.
The IPP Printer MUST accept the request in any state, MUST NOT transition the Printer to any other printer-state, and MUST add the 'hold-new-jobs' value to the Printer's printer-state-reasons attribute (whether the value was present or not) 💅
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5). 🔑
The Hold-New-Jobs Request and Hold-New-Jobs Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new "printer-message-from-operator" operation attribute (see section 6) 💌
3.3.2. Release-Held-New-Jobs Operation ✨
This OPTIONAL operation lets a client undo the effect of a previous Hold-New-Jobs operation 🔓. Basically the Printer releases all the jobs it held as a consequence of Hold-New-Jobs operations, i.e., while the 'hold-new-jobs' value was present in the Printer's printer-state-reasons attribute. The Printer MUST accept this request in any state, MUST NOT transition the Printer to any other printer-state, and MUST remove the 'hold-new-jobs' value from its printer-state-reasons attribute (whether the value was present or not), so the Printer no longer holds newly created jobs 🌈
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5). 🔑
The Release-Held-New-Jobs Request and Release-Held-New-Jobs Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new "printer-message-from-operator" operation attribute (see section 6) 💌
3.4. Deactivate and Activate Printer Operations ✨
this section defines the OPTIONAL Deactivate-Printer and Activate-Printer operations, which stop and start the IPP Printer object from accepting all requests except queries and performing work. If either of these operations is supported, both MUST be supported 🥹
These operations let the operator put the Printer into a dormant, read-only condition and take it back out of that condition 💤
3.4.1. Deactivate-Printer Operation ✨
This OPTIONAL operation lets a client stop the Printer object from sending IPP jobs to any of its Output Devices or Subordinate Printers (Pause-Printer-After-Current-Job), and stop the Printer object from accepting any requests except query requests 😶. The Printer performs a Disable-Printer and a Pause-Printer-After-Current-Job operation immediately. If these two operations cannot be completed immediately, it includes use of all of the "printer-state-reasons". The Printer MUST immediately reject all requests, except for Activate-Printer, queries (Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs, etc.), Send-Document, and Send-URI (so that partial job submission can be completed, see section 3.1.1) 📨. Then the Printer MUST return the 'server-error-service-unavailable' status code 🚨
The IPP Printer MUST accept the request in any state. Immediately, the Printer MUST set the 'deactivated' value in its printer-state-reasons attribute.
Note: neither the Disable-Printer nor the Pause-Printer-After-Current-Job set the 'deactivated' value. ⚠️
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5). 🔑
The Deactivate-Printer Request and Deactivate-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new "printer-message-from-operator" operation attribute (see section 6) 💌
3.4.2. Activate-Printer Operation ✨
This OPTIONAL operation lets a client undo the effects of the Deactivate-Printer. i.e., it allows the Printer object to start sending IPP jobs to any of its Output Devices or Subordinate Printers (Pause-Printer-After-Current-Job), and it starts the Printer object accepting any requests again 🌟. The Printer performs an Enable-Printer and a Resume-Printer operation immediately. In addition, the Printer MUST immediately start accepting all requests 🎉
The IPP Printer MUST accept the request in any state. The Printer MUST immediately remove the 'deactivated' value from its printer-state-reasons attribute (whether it is present or not) 🦋
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5). 🔑
The Activate-Printer Request and Activate-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new "printer-message-from-operator" operation attribute (see section 6) 💌
3.5. Restart-Printer, Shutdown-Printer, and Startup-Printer Operations ✨
this section defines the OPTIONAL Restart-Printer, Shutdown-Printer, and Startup-Printer operations, which initialize, shut down, and start up the Printer object, respectively. Each of these operations is OPTIONAL, and any combination MAY be supported 🌸
3.5.1. Restart-Printer Operation
okay bestie, this one is OPTIONAL 🎀 and it lets a client restart a Printer object whose behavior is giving wrong or erratic vibes 💀. Basically it's the software version of unplugging and replugging a device 🔌. The implementation MUST attempt to save any information about Jobs and the Printer object before re-initializing 💾. BUT this operation MAY have drastic consequences on the running system 😭, so the client SHOULD try the Deactivate-Printer operation first to keep the current state of the system as chill as possible 🫶. Also, the effects of previous Disable-Printer, Pause Printer, and Deactivate-Printer operations are lost 🥀.
The IPP Printer MUST accept the request in any state ✨. The Printer object MUST initialize its Printer's "printer-state" to 'idle', remove the state reasons from its "printer-state-reasons" attribute, and change its "printer-is-accepting-jobs" attribute to 'true' 👑. Main character reset energy 💅.
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5).
The Restart-Printer Request and Restart-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.8.1 and 3.2.8.2), including the new "printer-message-from-operator" operation attribute (see section 6) 🎀.
3.5.2. Shutdown-Printer Operation
This OPTIONAL operation lets a client shut down a Printer 🌙. That means it stops processing jobs without losing any jobs and makes the Printer object unavailable for any IPP operations 🚪. There's no way to bring that instance of the Printer object back into use, except through Startup-Printer (see section 3.5.3), which starts up a new instance of the Printer object for hosted implementations 🧚. Shutdown-Printer is for shutting the Printer down for an extended period, not for resetting the device(s) or changing a Printer attribute ❌. If you just want to reinitialize the software, look at Restart-Printer (section 3.5.1) and Startup-Printer (section 3.5.3) 🔁. And if you only want to stop the Printer from accepting Job Creation requests without stopping processing or shutting down, that's the Disable-Printer operation (section 3.1) 💜.
The Printer MUST add the 'shutdown' value (see [RFC2911], section 4.4.11) immediately to its "printer-state-reasons" Printer Description attribute 🛑. Then it performs a Deactivate-Printer operation (see section 3.4.1), which in turn performs Disable-Printer and Pause-Printer-After-Current-Job operations).
Note: To shut down the Printer after all the currently submitted jobs have completed, the operator issues a Disable-Printer operation (see section 3.1.1) and then waits until all the jobs have completed 🕰️. The Printer goes into the 'idle' state before issuing the Shutdown-Printer operation.
The Printer object MUST accept this operation in any state 🫡 and transition the Printer object through the "printer-states" and "printer-state-reasons" defined for the Pause-Printer-After-Current-Job operation until the activity is completed and the Printer object disappears 👋.
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5).
The Shutdown-Printer Request and Shutdown-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new "printer-message-from-operator" operation attribute (see section 6) 🦋.
3.5.3. Startup-Printer operation
This OPTIONAL operation lets a client start up an instance of a Printer object, as long as there isn't one already initiated 🌅. The whole point is to let a hosted implementation of the IPP Printer object (a Server that implements an IPP Printer on behalf of a networked or local Output Device) get started after the host is available, which happens by means outside this document 🌈. If the Printer object is already running and you need to reinitialize the software or reset the Output Device(s), see section 3.5.1 instead 🔧.
The host MUST accept this operation only when the Printer object has not been initiated. If the Printer object already exists, the host must return the 'client-error-not-possible' status code 🙅♀️.
The result of this operation MUST be that the Printer object's "printer-state" is set to 'idle', the state reasons are removed from its "printer-state-reasons" attribute, and its "printer-is-accepting-jobs" attribute is set to 'false' 🌱. Then the operator can reconfigure the Printer before performing an Enable-Printer operation. However, when a Printer is first powered up, it is RECOMMENDED that its "printer-is-accepting-jobs" attribute be set to 'true' so you get easy "out of the box" operation 📦✨.
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5).
The Shutdown-Printer Request and Shutdown-Printer Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911] sections 3.2.7.1 and 3.2.7.2), including the new "printer-message-from-operator" operation attribute (see section 6) 💖.
4. Definition of the Job Operations ✨
All Job operations are directed at Job objects 🎯. A client MUST always supply some way to identify the Job object so the correct target gets selected 🔍. That job identification MAY either be a single Job URI or a combination of a Printer URI and a Job ID 🔗. The IPP object implementation MUST support both forms of identification for every job 🫶.
The Job Operations defined in this document are summarized in Table 4 📋.
Table 4. Job Operation Operation-Id Assignments
Operation Name Operation-Id Brief description
--------------------------------------------------------------------
Reprocess-Job 0x2C Creates a copy of a completed target
job with a new Job ID and processes it.
Cancel-Current- 0x2D Cancels the current job on the target
Job Printer or the specified job if it is
the current job.
Suspend- 0x2E Suspends the current processing job on
Current-Job the target Printer or the specified
job if it is the current job, allowing
other jobs to be processed instead.
Resume-Job 0x2F Resumes the suspended target job.
Promote-Job 0x30 Promotes the pending target job to be
next after the current job(s) complete.
Schedule-Job- 0x31 Schedules the target job immediately
After after the specified job, all other
scheduling factors being equal.4.1. Reprocess-Job Operation
This OPTIONAL operation is a create job operation that lets a client re-process a copy of a job that was kept in the queue after processing was completed, canceled, or aborted (see [RFC2911], section 4.3.7.2) ♻️. It works the same as the Restart-Job operation (see [RFC2911], section 3.3.7), except the Printer creates a new job that's a copy of the target job, and the target job stays unchanged 👯. New values get assigned to the "job-uri" and "job-id" attributes 🆕. The new job's Job Description attributes that track progress, like "job-impressions-completed", "job-media-sheets-completed", and "job-k-octets-processed", start at 0, same as any create job operation 📈. The target job moves to the Job History after a suitable period, no matter whether one or more Reprocess-Job operations have been run on it 🕰️.
If the Set-Job-Attributes operation is supported, then the "job-hold-until" operation attribute MUST be supported with at least the 'indefinite' value 🛡️. That way a client can modify the new job before it's scheduled for processing using the Set-Job-Attributes operation ✏️. After modifying the job, the client can release it for processing using the Release-Job operation, specifying the newly assigned "job-uri" or "job-id" for the new job 🚀.
4.2. Cancel-Current-Job Operation
This OPTIONAL operation lets a client cancel the current job on the target Printer, or the specified job if it's the current job on the Printer 🛑. For what canceling a job actually means, see [RFC2911], section 3.3.3 📖. Since a Job might already be marking by the time a Cancel-Current-Job arrives, some media sheet pages might still print before the job is actually terminated 📄💀.
If the client does not supply a "job-id" operation attribute, the Printer MUST accept the request and cancel the current job, as long as there is a current job in the 'processing' or 'processing-stopped' state 🎯. Otherwise, it MUST reject the request and return the 'client-error-not-possible' status code 🙅♀️. If more than one job is in the 'processing' or 'processing-stopped' state, the one that is marking gets canceled, and the others are unaffected 🌸.
Warning: On a shared printer, there's a race condition 😱. Between the time a user issues this operation and the time it's accepted, the current job might change to a different job. If the user or operator is authenticated to cancel the new job, the wrong job gets canceled 💀. To prevent this race from canceling the wrong job, the client MAY supply the "job-id" operation attribute, which is checked against the current job's job-id 🔐. If the job identified by the "job-id" attribute is not the current job on the Printer (i.e., is not in the 'processing' or 'processing-stopped' state), the Printer MUST reject this operation and return the 'client-error-not-possible' status code. Otherwise, the Printer cancels the specified job ✅.
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must either be the job owner (as determined in the Job Creation operation) or an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5) 👑.
The Cancel-Current-Job Request and Cancel-Current-Job Response have the same attribute groups and attributes as the Resume-Printer operation (see [RFC2911], section 3.2.8), including the new "job-message-from-operator" operation attribute (see section 6). The request also gets one extra Group 1 Operation attribute 🎀:
"job-id" (integer(1:MAX)):
The client OPTIONALLY supplies this Operation attribute to verify
that the identified job is still the current job on the target
Printer object. The IPP object MUST support this operation
attribute if it supports this operation.4.3. Suspend and Resume Job Operations
This section defines the Suspend-Current-Job and Resume-Job operations ⏸️. These let an operator or user suspend a job while it's processing so other jobs can get a turn, then resume the suspended job later without losing any of the output 🦋.
If either of these operations is supported, both MUST be supported 🫶.
The Hold-Job and Release-Job operations ([RFC2911], section 3.3.5) are for holding and releasing held jobs 📥, not for suspending and resuming suspended jobs 🙅♀️. Different vibes, different operations 💅.
4.3.1. Suspend-Current-Job Operation 🛑✨
Okay bestie, this one is OPTIONAL 💅. It lets a client pause the current job on the target Printer, or a specific job if that job happens to be the current one, so other jobs can get their turn 🌸. The Printer moves the current job or the target job into processing-stopped, sets job-suspended (see section 9.1) in that job's job-state-reasons attribute, and then processes the other jobs 🔥.
If the client doesn't send a job-id operation attribute, the Printer MUST accept the request and suspend the current job, as long as there's a current job in processing or processing-stopped. If there isn't, it MUST reject the request and return client-error-not-possible 💀. And if more than one job is in those states, all of them get suspended 🙈.
Warning: On a shared printer there's a race condition 😬. Between the moment a user issues this operation and the moment it's accepted, the current job might change to a different job. If the user or operator is authenticated to suspend the new job, the wrong job gets suspended. To stop this race from pausing the wrong job, the client MAY supply thejob-idoperation attribute, which gets checked against the current job's job-id. If the job named byjob-idisn't the current job on the Printer (i.e., it isn't inprocessingorprocessing-stopped), the Printer MUST reject this operation and returnclient-error-not-possible. Otherwise, the Printer suspends the specified job and processed other jobs.
The Printer MUST reject a Suspend-Current-Job request (and return client-error-not-possible) for a job that's already been suspended, meaning a job in processing-stopped with job-suspended in its job-state-reasons attribute. Not twice, bestie 🙅♀️.
Access Rights: the authenticated user (see [RFC2911], section 8.3) performing this operation must be either the job owner (as determined in the Job Creation operation) or an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5). Main character energy only for the right people 👑.
The Suspend-Current-Job Request and Suspend-Current-Job Response have the same attribute groups and attributes as the Pause-Printer operation (see [RFC2911], section 3.2.8 ), including the new job-message-from-operator operation attribute (see section 6). The request also gets one extra Group 1 Operation attribute:
job-id (integer(1:MAX)): The client OPTIONALLY supplies this Operation attribute to verify that the identified job is still the current job on the target Printer object. The IPP object MUST support this operation attribute if it supports this operation 🧚.
4.3.2. Resume-Job Operation ▶️💖
This OPTIONAL operation lets a client resume the target job right where it was suspended 🦋. The Printer moves the target job back to pending and removes job-suspended from the job's job-state-reasons attribute.
If the target job isn't in processing-stopped with job-suspended in its job-state-reasons attribute, the Printer MUST reject the request and return client-error-not-possible, since the job was never suspended in the first place 🙃.
Access Rights: the authenticated user (see [RFC2911], section 8.3) performing this operation must be either the job owner (as determined in the Job Creation operation) or an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5). Same energy as before, bestie 💅.
The Resume-Job Request and Resume-Job Response have the same attribute groups and attributes as the Release-Job operation (see [RFC2911], section 3.3.6), including the new job-message-from-operator operation attribute (see section 6).
4.4. Job Scheduling Operations 🗓️
This section is all about the operations that let an operator control how jobs get scheduled. Operator era 👑.
4.4.1. Promote-Job Operation 🚀
This OPTIONAL operation lets a client make the pending target job get processed next, right after the current job finishes 🏃♀️. It's especially useful in a production printing environment where an operator is handling the scheduling.
If the target job is in pending, this operation doesn't change the job's state. It just makes sure the job gets processed after the current job(s) complete ✨. If the target job isn't in pending, the Printer MUST reject the request and return client-error-not-possible 😭.
If the Printer implements the job-priority Job Template attribute (see [RFC2911], section 4.2.1), the Printer sets the job's job-priority to the highest value supported, so the job prints before any other pending jobs 💅. The Printer also returns the target job immediately after the current job(s) in a Get-Jobs response (see [RFC2911], section 3.2.6) for the not-completed jobs.
When the current job is completed, canceled, suspended (see section 4.3.1), or aborted, the target of this operation gets processed next 🌈.
If a client issues this request again before the target of the original request starts processing, the target of this new request gets processed first. Double-promote is a power move 💜.
IPP is specified not to require queues for job scheduling, since there are other implementation techniques for scheduling multiple jobs, such as re-evaluating a criteria function for each job on a scheduling cycle 🧠. But if an implementation does use queues, the Promote-Job operation puts the specified job at the front of the queue. A subsequent Promote-Job operation, sent before the first job starts processing, puts that specified job at the front of the queue too, so it sits "in front" of the previously promoted job 🎀.
Access Rights: the authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5).
The Promote-Job Request and Promote-Job Response have the same attribute groups and attributes as the Cancel-Job operation (see [RFC2911], section 3.3.3), including the new job-message-from-operator operation attribute (see section 6).
4.4.2. Schedule-Job-After Operation 🫶
This OPTIONAL operation lets a client ask the Printer to schedule the target job so it gets processed immediately after a specified predecessor job, assuming all other scheduling factors are equal ⚖️. It's especially useful in a production printing environment where an operator is involved in scheduling.
If the target job is in pending, this operation doesn't change the job's state. It just makes sure the job gets processed after the predecessor job completes 🌸. The predecessor job can be in pending, processing, or processing-stopped. If the target job isn't in pending, or the predecessor job isn't in pending, processing, or processing-stopped, the Printer MUST reject the request and return client-error-not-possible, because the job can't have its position changed 🙅♀️.
If the Printer implements the job-priority Job Template attribute (see [RFC2911], section 4.2.1), the Printer sets the job's job-priority to match the predecessor job's, so the job prints right after it 💖. The Printer also returns the target job immediately after the predecessor in a Get-Jobs response (see [RFC2911], section 3.2.6) for the not-completed jobs.
When the predecessor job completes processing, or is canceled or aborted while processing, the target of this operation gets processed next 🦋.
If the client doesn't supply a predecessor job, this operation has the same semantics as Promote-Job (see section 4.4) 🚀.
IPP is specified not to require queues for job scheduling, since there are other implementation techniques for scheduling multiple jobs, such as re-evaluating a criteria function for each job on a scheduling cycle 🧠. But if an implementation does use queues, the Schedule-Job-After operation puts the specified job immediately after the specified job in the queue. A subsequent Schedule-Job-After operation that names the same job will move its target job to sit after that job, even if it's currently between the first target job and the specified job. For example, say the job queue is jobs A, B, C, D, and E, in that order. A Schedule-Job-After with job E as the target and B as the specified job gives you the queue A, B, E, C, D. A subsequent Schedule-Job-After with job D as the target and B as the specified job gives you the queue A, B, D, E, C 🍓.
In other words, the link between the two jobs in a Schedule-Job-After operation isn't kept. There's no attribute on either job that points to the other job as a result of this operation 🫠.
Access Rights: the authenticated user (see [RFC2911], section 8.3) performing this operation must be an operator or administrator of the Printer object (see [RFC2911], sections 1 and 8.5).
The Schedule-Job-After Request has the same attribute groups and attributes as the Cancel-Job operation (see [RFC2911], section 3.3.3), plus the new job-message-from-operator operation attribute (see section 6). In addition, this operation defines the following operation attribute:
predecessor-job-id: The client OPTIONALLY supplies this attribute. The Printer MUST support it, if it supports this operation. This attribute specifies the job after which the target job is to be processed. If the client omits this attribute, the Printer MUST process the target job next, i.e., after the current job, if there is one 🧚.
The Schedule-Job-After Response has the same attribute groups, attributes, and status codes as the Cancel-Job operation (see [RFC2911], section 3.3.3). These status codes have a special meaning for this operation:
client-error-not-possible: The target job wasn't inpending, or the predecessor job wasn't inpending,processing, orprocessing-stopped.client-error-not-found: Either the target job or the predecessor job wasn't found 🔍.
5. Additional Status Codes ✨
This section defines new status codes used by the operations defined in this document. New codes, new vibes 🎀.
5.1. server-error-printer-is-deactivated (0x050A) 💤
The Printer has been deactivated by the Deactivate-Printer operation. It's only accepting the Activate-Printer (see section 3.5.1), Get-Job-Attributes, Get-Jobs, Get-Printer-Attributes, and any other Get-Xxxx operations 🙈. An operator can perform the Activate-Printer operation to let the Printer accept other operations again 🌈.
6. Use of Operation Attributes That Are Messages from the Operator 💌
okay bestie, this section is all about the "printer-message-from-operator" and "job-message-from-operator" operation attributes 🧚 (defined in [RFC3380]). They're the notes operators can attach to their actions so everyone knows why something happened. The attributes set the matching Printer and Job Description attributes (see [RFC2911] for those). They show up on most of the Printer and Job operations operators actually do, so the reasons can be recorded 🫶
Here's how the Printer operations shake out, in Table 5 💅
Table 5. Operation Attribute Support for Printer Operations
Operation Attribute A B
---------------------------------------------
attributes-charset REQ REQ
attributes-natural-language REQ REQ
printer-uri REQ REQ
requesting-user-name REQ REQ
printer-message-from-operator Note OPT
Legend:
A: Get-Printer-Attributes, Set-Printer-Attributes
B: All other Printer administrative operations, including, but
not limited to, Pause-Printer, Pause-Printer-After-Current-
Job, Resume-Printer, Hold-New-Jobs, Release-Held-New-Jobs,
Purge-Jobs, Enable-Print, Disable-Printer, Restart-
Printer, Shutdown-Printer, and Startup-Printer.
REQ: REQUIRED for a Printer to support.
OPT: OPTIONAL for a Printer to support; the Printer ignores the
attribute if it is not supported.
Note: According to [RFC3380], the Client MUST NOT supply the
"printer-message-from-operator" operation attribute in a
Get-Printer-Attributes or Set-Printer-Attributes operation;
the Printer MUST ignore this operation attribute in these
two operations. Instead, when it is used by an
operator, the client MUST supply the
"printer-message-from-operator" as (one of the) explicit
attributes being set on the Printer object with the
Set-Printer-Attributes operation.And now the Job side, Table 6 🌈
Table 6. Operation Attribute Support for Job Operations
Operation Attribute A B C F
---------------------------------------------------------
attributes-charset REQ REQ REQ REQ
attributes-natural-language REQ REQ REQ REQ
printer-uri REQ REQ REQ REQ
job-uri REQ REQ REQ
job-id REQ REQ REQ REQ
requesting-user-name REQ REQ REQ REQ
job-message-from-operator OPT OPT OPT Note
message** OPT OPT OPT n/a
job-hold-until n/a n/a OPT* n/a
Legend:
A: Cancel-Job, Resume-Job, Restart-Job, Promote-Job, Schedule-Job-
After
B: Cancel-Current-Job, Suspend-Current-Job
C: Hold-Job, Release-Job, Reprocess-Job
F: Get-Job-Attributes, Set-Job-Attributes
REQ; REQUIRED for a Printer to support.
OPT: OPTIONAL for a Printer to support; the Printer ignores the
attribute if it is supplied, but not supported.
n/a: not applicable for use with the operation; the Printer ignores
the attribute.
Note: According to [RFC3380], the Client MUST NOT supply the "job-
message-from-operator" operation attribute in a Get-Job-
Attributes or Set-Job-Attributes operation; the Printer MUST
ignore this operation attribute in these two operations.
Instead, when used by an operator, the client MUST supply the
"job-message-from-operator" as (one of the) explicit attributes
being set on the Job object with the Set-Job-Attributes
operation.
*: The Printer MUST support the "job-hold-until" operation
attribute if it supports the "job-hold-until" Job Template
attribute. For the Reprocess-Job operation, the client can
hold the job and then modify the job before releasing it to
be processed.
**: In [RFC2911], the "message" operation attribute is defined to
contain a message to the operator, but [RFC2911] does not
define a Job Description attribute to store the message.7. New Printer Description Attributes 🎀
these are the brand-new Printer Description attributes 🦋 needed for the new operations in this document, plus the whole Printer Fan-Out idea (see section 10).
7.1. subordinate-printers-supported (1setOf uri)
this Printer attribute is REQUIRED if an implementation supports Subordinate Printers (see section 10). It holds the URIs of the immediate Subordinate Printer object(s) linked to this Printer object. Every Non-Leaf Printer object MUST support this attribute 🌸 A Leaf Printer object either skips the subordinate-printers-supported attribute or uses the 'no-value' out-of-band value (see [RFC2911], section 4.1), depending on the implementation. ✨
the exact format of the Subordinate Printer URIs is up to the implementation (see section 10.4) 🤷♀️
and if the Printer object has no associated Output Device, the Printer MAY automatically copy the Subordinate Printer object's "printer-name" value into the Job object's "output-device-assigned" attribute (see [RFC2911], section 4.3.13). That Job attribute tells you which Output Device the Printer object has assigned a job to. It's giving when one Printer object is handling Device Fan-Out or Printer Fan-Out 💜
7.2. parent-printers-supported (1setOf uri)
this Printer attribute is REQUIRED if an implementation supports Subordinate Printers (see section 10). It holds the URI of the Non-Leaf Printer object(s) this Printer object is the immediate Subordinate of, aka its immediate "parent" or "parents" 👑 Every Subordinate Printer object MUST support this attribute. A Printer with no parents either skips the parent-printers-supported attribute or uses the 'no-value' out-of-band value (see [RFC2911], section 4.1), depending on the implementation 🍓
8. Additional Values for the "printer-state-reasons" Printer Description Attribute 🌈
this section adds new values for the "printer-state-reasons" Printer Description attribute ✨
8.1. 'hold-new-jobs' Value
'hold-new-jobs': the operator has issued the Hold-New-Jobs operation (see section 3.3.1) or used some other means, but the output-device(s) are taking forever to stop 😭 Once all the output has stopped, the "printer-state" becomes 'stopped', and the 'paused' value replaces the 'moving-to-paused' value in the "printer-state-reasons" attribute. This value MUST be supported if the Hold-New-Jobs operation is supported and the implementation takes significant time to pause a device in certain circumstances. 💅
8.2. 'deactivated' Value
'deactivated': a client has issued a Deactivate-Printer operation for the Printer object (see section 3.4.1), and the Printer is in the middle of becoming deactivated or already has. The Printer MUST reject all requests except for Activate-Printer, queries (Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs, etc.), Send-Document, and Send-URI (so partial job submission can be finished; see section 3.1.1). After that it returns the 'server-error-service-unavailable' status code 🙈
this one's a big deal: everything else gets bounced while the printer is deactivated, so only the partial submission and query stuff still goes through 💀
9. Additional Values for the "job-state-reasons" Job Description Attribute 🦋
this section adds new values for the "job-state-reasons" Job Description attribute 🧚
9.1. 'job-suspended' Value
'job-suspended': while job processing has been suspended by the Suspend-Current-Job operation, other jobs can still get processed on the Printer 🌸 The Job can be picked back up with the Resume-Job operation, and that removes this value 🔥
10. Use of the Printer Object to Represent IPP Printer Fan-Out and IPP Printer Fan-In 🫧
this section explains how the Printer object MAY be used to represent IPP Printer Fan-Out and IPP Printer Fan-In 👑 In Fan-Out, one IPP Printer represents other IPP Printer objects. In Fan-In, several IPP Printer objects represent one other IPP Printer object. Main character energy, honestly 💖
10.1. IPP Printer Fan-Out
the IPP/1.1 Model and Semantics introduced the idea of one IPP Printer object representing more than one Output Device (see [RFC2911], section 2.1), and that's called "Output Device Fan-Out" 🍓 The catch was that with Fan-Out, there was no way to see the states of the individual Output Devices or to run operations on one specific Output Device 😤 So this document levels up the Printer object so it can represent Subordinate Fan-Out Output Devices, like IPP Printer objects. That's called "Printer object Fan-Out" ✨
a Printer object with a Subordinate Printer object is called a Non-Leaf Printer object. So a Non-Leaf Printer object supports one or more Subordinate Printer objects to show off Printer object Fan-Out 🎀 A Printer object with no Subordinate Printer objects is a Leaf Printer object 🌈
each Non-Leaf Printer object submits jobs to its immediate Subordinate Printers and otherwise controls them using IPP or other protocols 🚀 Whether pending jobs stay in the Non-Leaf Printer until a Subordinate Printer can take them, or sit in the Subordinate Printers, depends on the implementation and/or configuration policy 🤷♀️ Also, a Subordinate Printer object MAY, in turn, have Subordinate Printer objects of its own. So a Printer object can be a Non-Leaf Printer and a Subordinate Printer at the same time 🫶
a Subordinate Printer object MUST be a conforming Printer object, so it MUST support all of the REQUIRED [RFC2911] operations and attributes 💅 But with access control, the Subordinate Printer MAY be set up so end-user clients can't do anything (or can only do Get-Printer-Attributes) while one or more Non-Leaf Printer object(s) can do any operation. Bestie, that's a very specific kind of VIP list 👑
10.2. IPP Printer Fan-In
the IPP/1.1 Model and Semantics didn't rule out several IPP Printer objects representing a single Output Device (see [RFC2911], section 2.1) 🤔 But the client had no way to tell there was a Fan-In setup, and no way to run operations on the Subordinate device either 😭 This spec levels up the Printer object so several Non-Leaf IPP Printer objects can represent one Subordinate Printer object. So a Non-Leaf Printer object MAY share a Subordinate Printer object with one or more other Non-Leaf Printer objects to show off IPP Printer Fan-In 🦋
same rules as Fan-Out (see section 10.1) apply here: when a Printer object is a Non-Leaf Printer, it MUST NOT have an associated Output Device 🙅♀️ A Leaf Printer object has one or more associated Output Devices, just like with Fan-Out. The Non-Leaf Printer objects submit jobs to their Subordinate Printer objects and otherwise control the Subordinate Printer, same as Fan-Out. And whether pending jobs stay in the Non-Leaf Printers until the Subordinate Printer can accept them, or stay in the Subordinate Printer, depends on the implementation and/or configuration policy 🌸
10.3. Printer Object Attributes Used to Represent Printer Fan-Out and Printer Fan-In ✨
okay so these two attributes are how a Printer object knows who its kids and parents are 🌸
"subordinate-printers-supported" (1setOf uri): Contains the URI of the immediate Subordinate Printer object(s)."parent-printers-supported (1setOf uri): Contains the URI of the Non-Leaf printer object(s) for which this Printer object is the immediate Subordinate, i.e., this Printer's immediate "parent" or "parents" 💜
10.4. Subordinate Printer URI 🦋
every Subordinate Printer object has a URI that's the target of each operation sent to that Subordinate Printer. how you configure those URIs is up to the implementation, same as all URIs 🙈 but there are two distinct approaches, and they're both giving different vibes:
- a. When the implementation wants to make sure no operation on a Subordinate Printer object "sneaks by" the parent Printer object (or that no Subordinate Printer is fronting for a device that isn't networked), the host part of the URI is the host of the parent Printer. That way the parent Printer object can easily reflect the state of its Subordinate Printer objects in its own
printer-stateandprinter-state-reasonsas the operation passes "through" it 🎀 - b. When the Subordinate Printer is networked and the implementation lets operations go directly to it (with proper access control) without the parent Printer object knowing, the host part of the URI is different from the host part of the parent Printer object. In this case, the parent Printer object MAY keep its
"printer-state"and"printer-state-reasons"up to date, either by polling the Subordinate Printer object or by subscribing to events with the Subordinate Printer object (see [RFC3995] for means to subscribe to event notification when the Subordinate Printer object supports IPP notification). Alternatively, the parent Printer MAY wait until its"printer-state"and"printer-state-reasons"attributes are queried, and then query all its Subordinate Printers to return the correct values 🧚
10.5. Printer Object Attributes Used to Represent Output Device Fan-Out 🍓
only Leaf IPP Printer objects are allowed to have one or more associated Output Devices. Each Leaf Printer object MAY support the "output-devices-supported" (1setOf name(127)) to show the user-friendly name(s) of the Output Device(s) it represents. It is RECOMMENDED that each Leaf Printer object have only one associated Output Device, so the individual Output Devices can be fully represented and fully controlled by clients. In other words, the Leaf Printer's "output-devices-supported" attribute SHOULD have only one value ✨
Non-Leaf Printer MUST NOT have associated Output Devices. However, a Non-Leaf Printer SHOULD support an "output-devices-supported" (1setOf name(127)) Printer Description attribute that contains all the values of its immediate Subordinate Printers. Since those Subordinate Printers MAY be Leaf or Non-Leaf, the same rules apply to them. So any Non-Leaf Printer SHOULD have an "output-devices-supported" (1setOf name(127)) attribute that contains all the values of the Output Devices associated with the Leaf Printers in its whole sub-tree 🌈
When a configuration of Printers and Output Devices is added, moved, or changed, there can be moments where the tree structure isn't consistent, i.e., times when a Non-Leaf Printer's "subordinate-printers-supported" doesn't agree with the Subordinate Printer's "parent-printers-supported". So the operator SHOULD first Deactivate all Printers being configured this way, update all pointer attributes, and then reactivate them. A useful client tool would validate a tree structure before Activating the Printers involved 🛠️
10.6. Figures to Show All Possible Configurations 🌸
Figures 1, 2, and 3 are taken from [RFC2911] to show the configurations possible with IPP/1.0 and IPP/1.1 where all Printer objects are Leaf Printer objects. The remaining figures show additional configurations using Non-Leaf and Leaf Printer objects 💅
Legend:
----> indicates a network protocol with the direction of its requests
##### indicates a Printer object that is either
embedded in an Output Device, or
hosted in a server.
The Printer object might or might not be capable
of queuing/spooling.
any indicates any network protocol or direct
connect, including IPP. Output Device
+---------------+
| ########### |
O +--------+ | # (Leaf) # |
/|\ | client |------------IPP-----------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
+---------------+
Figure 1. Embedded Printer Object ########### Output Device
O +--------+ # (Leaf) # +---------------+
/|\ | client |---IPP----># Printer #---any->| |
/ \ +--------+ # object # | |
########### +---------------+
Figure 2. Hosted Printer Object +---------------+
| |
+->| Output Device |
########### any/ | |
O +--------+ # (Leaf) # / +---------------+
/|\ | client |---IPP----># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
+->| Output Device |
| |
+---------------+
Figure 3. Output Device Fan-Out ########### ###########
O +--------+ # Non-Leaf# # subord. #
/|\ | client |---IPP----># Printer #---IPP----># Printer #
/ \ +--------+ # object # # object #
########### ###########
The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
through 6, or can be a Leaf Printer, as in Figures 1 through 3.
Figure 4. Chained IPP Printer Objects +------IPP--------------------->###########
/ +---># subord. #
/ / # Printer #
/ ########### IPP # object #
O +--------+ # Non-Leaf# / ###########
/|\ | client |---IPP----># Printer #--*
/ \ +--------+ # object # \
\ ########### IPP ###########
\ \ # subord. #
\ +---># Printer #
+------IPP---------------------># object #
###########
The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
through 6, or can be a Leaf Printer, as in Figures 1 through 3.
Figure 5. IPP Printer Object Fan-Out ###########
# Non-Leaf#
+---># Printer #-+
/ # object # \
IPP ########### \ ###########
O +--------+ / +-IPP-># subord. #
/|\ | client |--+-----------IPP---------------># Printer #
/ \ +--------+ \ +-IPP-># object #
IPP ########### / ###########
\ # Non-Leaf# /
+---># Printer #-+
# object #
###########
The Subordinate Printer can be a Non-Leaf Printer, as in Figures 4
through 6, or can be a Leaf Printer, as in Figures 1 through 3.
Figure 6. IPP Printer Object Fan-In10.7. Forwarding Requests 📬
this section covers how Job and Printer requests get forwarded to Subordinate Printer objects 🦋
10.7.1. Forwarding Requests that Affect Printer Objects 💖
in Printer Fan-Out, Printer Fan-In, and Chained Printers, the Non-Leaf IPP Printer object MUST NOT forward operations that affect Printer objects to its Subordinate Printer objects. If a client wants to explicitly target a Subordinate Printer, the client MUST specify the URI of that Subordinate Printer. Clients can find the URI of any Subordinate Printers by querying the Printer's "subordinate-printers-supported (1setOf uri) attribute (see section 7.1) 🔍
Table 7 lists the operations that affect Printer objects and the forwarding behavior a Non-Leaf Printer MUST exhibit toward its immediate Subordinate Printers. Operations that affect jobs follow a different forwarding rule (see section 10.7.2 and Table 8) 🌷
Table 7. Forwarding Operations that Affect Printer Objects
Printer Operation Non-Leaf Printer Action
---------------------------------------------------------------
Printer Operations:
Enable-Printer MUST NOT forward to any of its Subordinate
Printers
Disable-Printer MUST NOT forward to any of its Subordinate
Printers
Hold-New-Jobs MUST NOT forward to any of its Subordinate
Printers
Release-Held-New- MUST NOT forward to any of its Subordinate
Jobs Printers
Deactivate-Printer MUST NOT forward to any of its Subordinate
Printers
Activate-Printer MUST NOT forward to any of its Subordinate
Printers
Restart-Printer MUST NOT forward to any of its Subordinate
Printers
Shutdown-Printer MUST NOT forward to any of its Subordinate
Printers
Startup-Printer MUST NOT forward to any of its Subordinate
Printers
IPP/1.1 Printer See [RFC2911]
Operations:
Get-Printer- MUST NOT forward to any of its Subordinate
Attributes Printers
Pause-Printer MUST NOT forward to any of its Subordinate
Printers
Resume-Printer MUST NOT forward to any of its Subordinate
Printers
Set Operations: See [RFC3380]
Set-Printer- MUST NOT forward to any of its Subordinate
Attributes Printers10.7.2. Forwarding Requests that Affect Jobs 💅
Okay so this one is a big deal 🔥 Unlike Printer Operations that only touch Printer objects (see section 10.7.1), a Non-Leaf Printer object MUST forward operations that directly affect jobs to the right Job object(s) in one or more of its immediate Subordinate Printer objects. Forwarding is REQUIRED because the whole point of this Job operation is to change the job in question, and that job may have already been forwarded itself 🦋 This forwarding MAY be immediate or queued, depending on the operation and the implementation. For example, a Non-Leaf Printer object MAY queue/spool jobs and feed them to its Subordinate Printer(s) one at a time, or MAY forward jobs immediately to one of its Subordinate Printers. Either way, the Non-Leaf Printer object forwards Job Creation operations to one of its Subordinate Printers 🧚 The only thing that changes is when that forwarding happens, depending on whether the policy is to queue/spool jobs in the Non-Leaf Printer or in the Subordinate Printer.
When a Non-Leaf Printer object creates a Job object in its Subordinate Printer, it's up to the implementation whether that Non-Leaf Printer object keeps a fully formed Job object or just keeps a mapping from the "job-ids" it assigned to the ones its Subordinate Printer assigned. That's IMPLEMENTATION-DEPENDENT 🙈 No matter which one it picks, the Non-Leaf Printer MUST be able to accept and carry out future Job operations that specify the "job-id" that the Non-Leaf Printer assigned and returned to the job submitting client. Main character energy for that ID 👑
Table 8 lists the operations that directly affect jobs, along with the forwarding behaviour that a Non-Leaf Printer MUST show to its Subordinate Printers 🎀
Table 8. Forwarding Operations that Affect Jobs Objects
Operation Non-Leaf Printer action
---------------------------------------------------------------
Job operations:
Reprocess-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Cancel-Current- MUST NOT forward
Job
Resume-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Promote-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
IPP/1.1 Printer
operations:
Print-Job MUST forward immediately or queue to the
appropriate Subordinate Printer
Print-URI MUST forward immediately or queue to the
appropriate Subordinate Printer
Validate-Job MUST forward to the appropriate Subordinate
Printer
Create-Job MUST forward immediately or queue to the
appropriate Subordinate Printer
Get-Jobs MUST forward to all its Subordinate Printers
Purge-Jobs MUST forward to all its Subordinate Printers
IPP/1.1 Job
operations:
Send-Document MUST forward immediately or queue to the
appropriate Job in one of its Subordinate
Printers
Send-URI MUST forward immediately or queue to the
appropriate Job in one of its Subordinate
Printers
Cancel-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Get-Job- MUST forward to the appropriate Job in one of
Attributes its Subordinate Printers if the Non-Leaf
Printer doesn't know the complete status of the
Job object
Hold-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Release-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
Restart-Job MUST forward to the appropriate Job in one of
its Subordinate Printers
IPP Set operations: See [RFC3380]
Set-Job- MUST forward to the appropriate Job in one of
Attributes its Subordinate PrintersWhen a Printer receives a request that REQUIRES forwarding, it does so on a "best efforts basis" and returns a response to its client without waiting for responses from any of its Subordinate Printers. Such forwarded requests could fail. 😭
10.8. Additional Attributes to Help with Fan-Out ✨
The following operation and Job Description attributes are defined to help represent Job relationships for Fan-Out and forwarding of jobs 🌈
10.8.1. output-device-assigned (name(127)) Job Description Attribute - from [RFC2911] 🎀
[RFC2911] defines "output-device-assigned" like this:
"This attribute identifies the Output Device to which the Printer object has assigned this job. If an Output Device implements an embedded Printer object, the Printer object NEED NOT set this attribute. If a print server implements a Printer object, the value MAY be empty (zero-length string) or not returned until the Printer object assigns an Output Device to the job. This attribute is particularly useful when a single Printer object supports multiple devices (so called "Device Fan-Out" see [RFC2911] section 2.1)."
See also section 10.1 in this specification 🧚
10.8.2. original-requesting-user-name (name(MAX)) Operation and Job Description Attribute 🍓
This is the operation attribute holding the user name of the original user. It matches the "requesting-user-name" operation attribute (see [RFC2911], section 3.2.1.1) that the original client sent to the first Printer object. The Printer copies the "original-requesting-user-name" operation attribute into the matching Job Description attribute 💜
10.8.3. requesting-user-name (name(MAX)) Operation Attribute - Additional Semantics 🦋
The IPP/1.1 "requesting-user-name" operation attribute (see [RFC2911] section 3.2.1.1) gets updated by each client to be itself on every hop. So the "requesting-user-name" is the client that's forwarding the request, not the original client. Passing the baton, ngl 🫶
10.8.4. job-originating-user-name (name(MAX)) Job Description Attribute - Additional Semantics 👑
The "job-originating-user-name" Job Description attribute (see [RFC2911], section 4.3.6) stays as the authenticated original user, not the parent Printer's authenticated host. Each client forwards it without changing the value, so the original user stays the star of the show ⭐
11. Conformance Requirements 💖
The Job and Printer Administrative operations defined in this document are OPTIONAL operations. However, some operations MUST be implemented if others are implemented, as shown in Table 9 🌸
Table 9. Conformance Requirement Dependencies for Operations
Operations REQUIRED If any of these operations are
supported:
--------------------------------------------------------------------
Enable-Printer Disable-Printer
Disable-Printer Enable-Printer
Pause-Printer Resume-Printer
Resume-Printer Pause-Printer,
Pause-Printer-After-Current-Job
Hold-New-Jobs Release-Held-New-Jobs
Release-Held-New-Jobs Hold-New-Jobs
Activate-Printer, Deactivate-Printer
Disable-Printer,
Pause-Printer-After-Current-Job
Deactivate-Printer, Activate-Printer
Enable-Printer,
Resume-Printer
Restart-Printer none
Shutdown-Printer none
Startup-Printer none
Reprocess-Job none
Cancel-Current-Job none
Resume-Job Suspend-Current-Job
Suspend-Current-Job Resume-Job
Promote-Job none
Schedule-Job-After Promote-JobTables 10 and 11 list the "printer-state-reasons" and "job-state-reasons" values that are REQUIRED if the indicated operations are supported 🎀
Table 10. Conformance Requirement Dependencies for
"printer-state-reasons" Values
"printer-state- Conformance If any of the following Printer
reasons" values: Requirement Operations are supported:
--------------------------------------------------------------------
'paused' REQUIRED Pause-Printer,
Pause-Printer-After-Current-Job,
or Deactivate-Printer
'hold-new-jobs' REQUIRED Hold-New-Jobs
'moving-to-paused' OPTIONAL Pause-Printer,
Pause-Printer-After-Current-Job,
Deactivate-Printer
'deactivated' REQUIRED Deactivate-PrinterTable 11. Conformance Requirement Dependencies for "job-state-
reasons" Values
"job-state-reasons" Conformance If any of the following Job
values: Requirement operations are supported:
'job-suspended' REQUIRED Suspend-Current-Job
'printer-stopped' REQUIRED Always REQUIRED12. Normative References 🔥
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 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., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
- [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.
- [RFC3380] Hastings, T., Herriot, R., Kugler, C., and H. Lewis, "Internet Printing Protocol (IPP): Job and Printer Set Operations", RFC 3380, September 2002.
13. Informative References 📚
- [RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
- [RFC2568] Zilles, S., "Rationale for the Structure of the 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.
- [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide", RFC 3196, November 2001.
- [RFC3239] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations", RFC 3239, February 2002.
- [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", RFC 3995, February 2005.
14. IANA Considerations 🦋
This section contains the registration information that IANA added to the IPP Registry according to the procedures defined in [RFC2911], section 6, to cover the definitions in this document. The resulting registrations have been published as additions to the http://www.iana.org/assignments/ipp-registrations file.
14.1. Attribute Registrations 🎀
Okay so this table lists every single attribute this document defines, bestie. 💅 They were all registered following the rules in [RFC2911], section 6.2, so they're official and not just vibes. 🦋
Name Reference Section
-------------------------------------- --------- -------
Job Description attributes:
original-requesting-user-name (name(MAX)) [RFC3998] 10.8.2
Printer Description attributes:
subordinate-printers-supported (1setOf uri) [RFC3998] 7.1
parent-printers-supported (1setOf uri) [RFC3998] 7.2
Operation attributes:
original-requesting-user-name (name(MAX)) [RFC3998] 10.8.214.2. Attribute Value Registrations 💖
This section is for the extra values this document adds to attributes that already exist. Think of it as new flavours for old favourites 🍓
Attribute
Value Reference Section
--------------------- --------- -------
job-state-reasons (1setOf type2 keyword)
job-suspended [RFC3998] 9.1
printer-state-reasons (1setOf type2 keyword)
hold-new-jobs [RFC3998] 8.1
deactivated [RFC3998] 8.214.3. Additional Enum Attribute Value Registrations ✨
Okay this one is a big list of brand new enum values, and every one of them comes from this document. 🧚 They were registered under [RFC2911], section 6.1, and the operations-supported row at the top is the one from RFC 2911 that these new values are added to. So iconic 👑
Attribute (attribute syntax)
Value Name Reference Section
------- -------------------- --------- -------
operations-supported (1setOf type2 enum) [RFC2911] 4.4.1
0x0022 Enable-Printer [RFC3998] 3
0x0023 Disable-Printer [RFC3998] 3
0x0024 Pause-Printer-After-Current-Job [RFC3998] 3
0x0025 Hold-New-Jobs [RFC3998] 3
0x0026 Release-Held-New-Jobs [RFC3998] 3
0x0027 Deactivate-Printer [RFC3998] 3
0x0028 Activate-Printer [RFC3998] 3
0x0029 Restart-Printer [RFC3998] 3
0x002A Shutdown-Printer [RFC3998] 3
0x002B Startup-Printer [RFC3998] 3
0x002C Reprocess-Job [RFC3998] 4
0x002D Cancel-Current-Job [RFC3998] 4
0x002E Suspend-Current-Job [RFC3998] 4
0x002F Resume-Job [RFC3998] 4
0x0030 Promote-Job [RFC3998] 4
0x0031 Schedule-Job-After [RFC3998] 414.4. Operation Registrations 🌈
This is the list of every operation this document defines. They were registered following [RFC2911], section 6.4. Operations are basically the verbs of IPP, so this is the whole verb list, periodt 💅
Name Reference Section
----------------------------- --------- -------
Activate-Printer [RFC3998] 3.4.2
Cancel-Current-Job [RFC3998] 4.2
Deactivate-Printer [RFC3998] 3.4.1
Disable-Printer [RFC3998] 3.1.1
Enable-Printer [RFC3998] 3.1.2
Hold-New-Jobs [RFC3998] 3.3.1
Pause-Printer-After-Current-Job [RFC3998] 3.2.1
Promote-Job [RFC3998] 4.4.1
Release-Held-New-Jobs [RFC3998] 3.3.2
Reprocess-Job [RFC3998] 4.1
Restart-Printer [RFC3998] 3.5.1
Resume-Job [RFC3998] 4.3.2
Schedule-Job-After [RFC3998] 4.4.2
Shutdown-Printer [RFC3998] 3.5.2
Startup-Printer [RFC3998] 3.5.3
Suspend-Current-Job [RFC3998] 4.3.114.5. Status Code Registrations 🔥
This table covers the status code this document defines. It was registered under [RFC2911], section 6.6. Spoiler: there's only one real status code here, and it's a sad one 💀
Value Name Reference Section
------ ------------------------ --------- -------
0x0000:0x00FF - "successful"
none at this time
0x0100:0x01FF - "informational"
none at this time
0x0300:0x03FF - "redirection" See RFC 2911 Errata
none at this time
0x0400:0x04FF - "client-error"
none at this time
0x0500:0x05FF - "server-error"
0x050A server-error-printer-is-deactivated [RFC3998] 5.115. Internationalization Considerations 🌸
Okay so this section is short and sweet. This document has the same localization considerations as [RFC2911], so if you already know those, you're basically set 🫶
16. Security Considerations 😭
Okay bestie, this is the serious part, so let's get into it. 🙈 The IPP Model and Semantics document [RFC2911] talks about the big high-level security needs: Client Authentication, Server Authentication, and Operation Privacy. Client Authentication is how the client proves who it is to the server in a secure way. Server Authentication is the reverse, so the server proves who it is to the client securely. And Operation Privacy is the mechanism for keeping operations safe from eavesdropping 👀
Printer operations defined in this specification (see section 3), along with Pause-Printer, Resume-Printer, and Purge-Job (defined in [RFC2911]), are meant for operators and/or administrators. Job operations defined in this specification (see section 4), along with Cancel-Job, Hold-Job, and Release-Job (defined in [RFC2911]), are meant for the job owner, the operator, or the administrator of the Printer object. These operator and administrator operations affect service for everyone, so this is not a drill 🚨
Using an administrative operation without authentication, as an end user, can wreck the quality of service for all users. So IPP Printer implementations MUST support both successful certificate-based TLS [RFC2246] client authentication and successful operator/administrator authorization (see [RFC2911], sections 5.2.7 and 8, and [RFC2910]) to perform the administrative operations defined in this document. [RFC2910] requires the IPP Printer to support the minimum cipher suite specified for TLS/1.0. How you authorize an operator or administrator of the Printer object is outside the scope of this specification, RFC 2910, and RFC 2911. 🔐
The use of TLS and Client Authentication solves the Denial of Service, Man in the Middle, and Masquerading security threats. 🛡️✨
17. Summary of Base IPP Documents 🧚
Okay so the base set of IPP documents is basically the IPP family tree 🌳 It includes these:
- 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: Implementer's Guide [RFC3196]
- Mapping between LPD and IPP Protocols [RFC2569]
"Design Goals for an Internet Printing Protocol" takes a broad look at distributed printing and walks through real-life scenarios to show which features a printing protocol for the Internet needs. It identifies requirements for three types of users: end users, operators, and administrators. It also calls out a subset of end user requirements that IPP/1.0 satisfies, and a few OPTIONAL operator operations were added to IPP/1.1. 🎀
"Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" gives the big-picture view of IPP. It defines a roadmap for the documents that make up the IPP specification suite, and it explains the background and reasoning behind the IETF working group's major decisions. 🗺️
"Internet Printing Protocol/1.1: Model and Semantics" describes a simplified model made of abstract objects, their attributes, and their operations, all independent of encoding and transport. It introduces a Printer object and a Job object, and the Job object can optionally support multiple documents per Job. It also covers security, internationalization, and directory issues. 💜
"Internet Printing Protocol/1.1: Encoding and Transport" is the formal mapping of the abstract operations and attributes from the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for the new Internet MIME media type "application/ipp", plus the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP. It also defines the 'ippget' scheme for identifying IPP printers and jobs. 🦋
"Internet Printing Protocol/1.1: Implementer's Guide" gives insight and advice to implementers of IPP clients and IPP objects. It's there to help you understand IPP/1.1 and the design considerations that can shape your client and/or IPP object implementations. For example, it gives a typical order for processing requests, including error checking, and it explains the motivation behind some of the specification decisions. 🧠
"Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations. 🔁
Authors' Addresses 💌
Carl Kugler
IBM Corporation, 003G
6300 Diagonal Hwy
Boulder, CO 80301
Phone: (303) 924-5060
EMail: kugler@us.ibm.com
Tom Hastings, editor
Xerox Corporation
701 S Aviation Blvd. ESAE 242
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-6342
EMail: hastings@cp10.es.xerox.com
Harry Lewis
IBM Corporation
6300 Diagonal Hwy
Boulder, CO 80301
Phone: (303) 924-5337
EMail: harryl@us.ibm.comFull Copyright Statement ⚖️
The legal text is kept exactly as written, since it's the boring-but-important bit 📜
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.Intellectual Property 💅
okay so the IETF is NOT saying it has checked whether anyone owns rights to the tech in this doc 🙈 it takes no position on whether any Intellectual Property Rights or other rights that someone might claim are valid, how far they reach, or whether a license is even available. it also hasn't made any independent effort to find out who holds those rights. if you want the rules on rights for RFC documents, check BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat, plus any assurances that licenses will be available, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔍 the same goes for the result of any attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights 🫶
the IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them 📩 send that info to the IETF at ietf-ipr@ietf.org ✨
Acknowledgement 🎀
funding for the RFC Editor function is currently provided by the Internet Society 🌸💜
📦 where this page comes from
- ietf: rfc3998 2005-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms