RFC 3380
Internet Printing Protocol (IPP): Job and Printer Set Operations
Part 1 of 12 💖
Internet Printing Protocol (IPP): Job and Printer Set Operations ✨
- Request for Comments: 3380 🎀
- Working Group: Network Working Group
- Authors: T. Hastings (Xerox Corporation), R. Herriot (Consultant), C. Kugler (IBM Corporation), H. Lewis (IBM Corporation)
- Category: Standards Track
- Date: September 2002
- Updates: 2910, 2911
- Obsoletes: none listed in the header
Status of this Memo
Okay so this doc is a standards track spec for the Internet community, and it's literally asking for discussion and suggestions 💅. If you want to know where this protocol is in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Bestie, this doc is an OPTIONAL extension to the Internet Printing Protocol (IPP/1.0 and IPP/1.1) 🖨️. It adds 3 more OPTIONAL operations that work with the Internet Printing Protocol/1.0 (IPP) and IPP/1.1 ✨. The end user, operator, and administrator Set-Job-Attributes and Set-Printer-Attributes operations are the ones that change IPP Job objects and Printer objects, respectively 💖. Then there's the admin operation Get-Printer-Supported-Values, which tells you the values the IPP Printer will accept for setting its "xxx-supported" attributes 🧚.
Table of Contents 📋
1 Introduction......................................................4
2 Terminology.......................................................5
2.1 Conformance Terminology.........................................5
2.2 Other terminology...............................................5
3 Requirements and Use Cases........................................5
4 Definition of the Set operations..................................6
4.1 Set-Printer-Attributes Operation................................7
4.1.1 Settable and READ-ONLY Printer Description attributes.........9
4.1.2 Set-Printer-Attributes Request...............................10
4.1.3 Set-Printer-Attributes Response..............................12
4.2 Set-Job-Attributes Operation...................................13
4.2.1 Settable and READ-ONLY Job Description attributes............16
4.2.2 Set-Job-Attributes Request...................................17
4.2.3 Set-Job-Attributes Response..................................18
4.3 Get-Printer-Supported-Values Operation.........................19
4.3.1 Definition of the usage of the 'admin-define' out-of-band
attribute value..............................................20
5 New Operation attributes.........................................22
5.1 printer-message-from-operator (text(127))......................22
5.2 job-message-from-operator (text(127))..........................23
6 New Printer Description Attributes...............................24
6.1 printer-settable-attributes-supported (1setOf type2 keyword)...24
6.2 job-settable-attributes-supported (1setOf type2 keyword).......25
6.3 document-format-varying-attributes (1setOf type2 keyword)......25
6.4 printer-message-time (integer(MIN:MAX))........................25
6.5 printer-message-date-time (dateTime)...........................26
6.6 printer-xri-supported (1setOf collection)......................26
6.7 xri-uri-scheme-supported (1setOf uriScheme)....................28
6.8 xri-authentication-supported (1setOf type2 keyword)............29
6.9 xri-security-supported (1setOf type2 keyword)..................29
7 Additional status codes..........................................29
7.1 client-error-attributes-not-settable (0x0413)..................29
8 Additional out-of-band values....................................30
8.1 'not-settable' out-of-band value...............................30
8.1.1 Encoding of the 'not-settable' out-of-band attribute value...30
8.2 'delete-attribute' out-of-band value...........................30
8.2.1 Encoding of the 'delete-attribute' out-of-band value.........31
8.3 'admin-define' out-of-band attribute value.....................31
8.3.1 Encoding of the 'admin-define' out-of-band attribute value...32
9 New Values for Existing Printer Description Attributes...........33
9.1 operations-supported (1setOf type2 enum).......................33
10 Conformance Requirements........................................33
11 IANA Considerations.............................................34
11.1 Operation Registrations.......................................35
11.2 Additional Enum Attribute Value Registrations for the
"operations-supported" Printer Attribute......................35
11.3 Attribute Registrations.......................................35
11.4 Status code Registrations.....................................36
11.5 Out-of-band Attribute Value Registrations.....................36
12 Internationalization Considerations.............................37
13 Security Considerations.........................................37
14 References......................................................38
14.1 Normative References..........................................38
14.2 Informative References........................................38
Appendix A: Allowed Values for Set-Printer-Attributes and Set-Job-
Attributes requests (Normative)........................39
Appendix B: Attributes returned from Get-Printer-Supported-Values
(Normative)............................................50
Appendix C: Description of the Base IPP Documents (Informative)....55
Authors' Addresses.................................................56
Full Copyright Statement...........................................58Table of Tables 🧚
Table 1 - Operation-Id assignments.................................7
Table 2 - Job State Transition Table for the Set-Job-Attributes
operation ..............................................15
Table 3 - Member attributes of "printer-xri-supported" (1setOf
collection) ............................................27
Table 4 - Operation-id assignments................................33
Table 5 - Validation rules for 'Any of "xxx-supported" '..........40
Table 6 - Validation rules for 'From Get-Printer-Supported-Values'41
Table 7 - Values allowed for Job Template Attributes in the Set-Job-
Attributes Operation ...................................42
Table 8 - Values allowed for Job Description Attributes in the Set-
Job-Attributes Operation ...............................43
Table 9 - Values allowed for Printer Job Template Attributes in the
Set-Printer-Attributes Operation .......................44
Table 10 - Values allowed for Printer Description Attributes in the
Set-Printer-Attributes Operation .......................47
Table 11 - Printer Job Template Attributes returned from Get-Printer-
Supported-Values .......................................51
Table 12 - Printer Job Template Attributes returned from Get-Printer-
Supported-Values .......................................51
Table 13 - Printer Description Attributes returned from Get-Printer-
Supported-Values .......................................51
Table 14 - Printer Job Template Attributes returned from Get-Printer-
Supported-Values .......................................52
Table 15 - Printer Job Template Attributes returned from Get-Printer-
Supported-Values .......................................52
Table 16 - Printer Description Attributes returned from Get-Printer-
Supported-Values .......................................531 Introduction
Okay so this doc is an OPTIONAL extension to IPP/1.0 [RFC2565, RFC2566] and IPP/1.1 [RFC2911, RFC2910] 🫶. If you want the base IPP docs, peek at Appendix C 📚.
The Internet Printing Protocol (IPP) is an application level protocol for distributed printing using Internet tools and technologies 🖨️✨. IPP version 1.1 [RFC2911, RFC2910] is mostly about end user stuff, with a few admin ops included. This doc defines additional OPTIONAL end user, operator, and administrator Set-Job-Attributes and Set-Printer-Attributes operations, which modify IPP Job objects and Printer objects respectively 💅. It also adds a third admin operation, Get-Printer-Supported-Values, which returns the values the IPP Printer will accept for setting its "xxx-supported" attributes. The Get-Printer-Supported-Values operation MUST be supported, if the implementation supports setting any "xxx-supported" Printer attributes using the Set-Printer-Attributes operation 🔥.
Nine Printer Description attributes are defined 🌸:
printer-settable-attributes-supported (1setOf type2 keyword)
job-settable-attributes-supported (1setOf type2 keyword)
document-format-varying-attributes (1setOf type2 keyword)
printer-message-time (integer(MIN:MAX))
printer-message-date-time (dateTime)
printer-xri-supported (1setOf collection)
xri-uri-scheme-supported (1setOf uriScheme)
xri-authentication-supported (1setOf type2 keyword)
xri-security-supported (1setOf type2 keyword)Three out-of-band values are defined for these three operations 🦋. delete-attribute is for deleting Job attributes with the Set-Job-Attributes request. not-settable is for use in either the Set-Job-Attributes or Set-Printer-Attributes responses. admin-define is for use in the Get-Printer-Supported-Values response.
Two operation attributes, printer-message-from-operator (text) and job-message-from-operator (text), are defined to set the corresponding IPP/1.1 Printer and Job Description attributes with the same names 💜. These operation attributes may be used with any operation that affects the Printer or Job object, for when an operation wants to show a message. For the Set-Job-Attributes and Set-Printer-Attributes operations, the client MUST explicitly set them, rather than using these operation attributes. No shortcuts, bestie 🙈.
A Printer implementation can make the value of some attributes depend on the document-format, e.g., resolution-supported 🍓.
2 Terminology
This section defines the terminology used throughout this document 🧚.
2.1 Conformance Terminology
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have a special conformance meaning, as defined in BCP 14, RFC 2119 [RFC2119] and [RFC2911] section 12.1 👑. If an implementation supports the extension defined in this document, then these terms apply; otherwise, they don't. These terms only define conformance to this document. They don't affect conformance to other documents, unless that's explicitly stated 💖.
2.2 Other terminology ✨
okay so this doc keeps throwing around words like Job object (or Job), IPP Printer object (or Printer), "operation", "request", response", "attributes", "keywords", and "support" 💅 these have special meanings and they're defined in the model terminology [RFC2911], section 12.2. it's giving "read the glossary first" energy 🤓 the doc also adds two new terms of its own:
READ-ONLY 🔒 used in an attribute definition doc to say the attribute MUST NOT be settable using an IPP protocol Set operation. so basically the attribute is not settable by definition. no cap, it's locked in 💀
not-settable 🙅♀️ an implementation does not support setting an attribute (whether or not the attribute's definition is READ-ONLY). this one is about what the implementation can do, not what the definition says, so keep them separate in your brain bestie 🧠
3 Requirements and Use Cases 🎀
the following requirements and usage are meant to be met by the specification in this document. the vibe here is "real problems real people have" 🥹
- The end-user and the operator need a way to modify a Job that is in the 'pending' or 'pending-held' state. 🛠️
Usage: the end-user realizes they forgot a print instruction, like "finishings" = 'staple', after submitting a job. instead of canceling the job and resubmitting it to the same IPP Printer, they can just modify the job on the IPP Printer. 🙌
the operator needs to modify a job because it's asking for a particular kind of media that's run out, but the policy is to print the job on a comparable medium. 📄
- The system administrator needs a way to re-configure or change the policy of the IPP Printer remotely. 🖥️✨
Usage: the system administrator is adding more named media to the supported media list (setting 'name' values to the "media-supported" Printer attribute). 📃
the system administrator is reducing what the IPP Printer can do by removing one of the operations from the supported operations list, such as Cancel-Job, because the policy is to run the IPP Printer like a public facsimile machine 📠 after removing Cancel-Job from the list of supported operations, an administrative client needs to be able to show an administrator that the implementation can be reconfigured to support Cancel-Job again. 🔁
the system administrator is remotely configuring the IPP Printer after installing it, so they're replacing the Printer Description attributes that have the out-of-band 'no-value' value (see [RFC2911], section 4.1) with the proper values. 🧩
the operator is changing the media loaded in the input tray, so they're replacing the "media-ready" Job Template Printer attribute value with the proper values. 🗂️
4 Definition of the Set operations 💖
the Set-Printer-Attributes operations (as are all Printer operations) are directed at Printer objects. a client MUST always supply the "printer-uri" operation attribute so the correct target of the operation gets identified 🎯 these descriptions assume all of the common semantics of the IPP/1.1 Model and Semantics document [RFC2911], section 3.1.
the Set-Job-Attributes operations (as are all Job operations) are directed at Job objects. a client MUST always supply some means of identifying the Job object so the correct target of the operation gets identified 🫶 that job identification MAY either be a single Job URI or a combination of a Printer URI with a Job ID, as defined in [RFC2911]. the IPP object implementation MUST support both forms of identification for every job. ✨ if possible, a client SHOULD use the Printer URI with a Job ID rather than a Job URI, since the 32-bit "job-id" is more easily translated to and from other print protocols that MAY be serving as gateways into or out of the IPP implementation 🌉
The Set Printer operations are summarized in Table 1 📊
Table 1 - Operation-Id assignments
Operation Name Operation Brief description
-Id
Set-Printer- 0x0013 Sets attribute values of the target
Attributes Printer object
Set-Job-Attributes 0x0014 Sets attribute values of the target
Job object
Get-Printer- 0x0015 Gets values that are valid for
Supported-Values setting "xxx-supported" attributes
using the Set-Printer-Attributes
operation4.1 Set-Printer-Attributes Operation 🖨️💅
this OPTIONAL operation lets a client set the values of the attributes of a Printer object. in the request, the client supplies the set of Printer keyword attribute names and values that are to be set. in the response, the Printer object either returns success or rejects the entire request and says which attribute or attributes could not be set. 💌
the Printer object validates the client-supplied attributes in the Set-Printer-Attributes request. for an attribute to validate, it MUST meet all of the following rules 👀
- The number of attributes supplied by the client MUST NOT exceed the maximum number that the Printer supports in a Set-Printer-Attributes request. A Printer MUST accept at least one attribute, but SHOULD accept a reasonable number in a single Set-Printer-Attributes request. 🔢
Note: there's no way for the client to find out the maximum number of attributes the Printer supports in a Set-Printer-Attributes request, except by trying a reasonable number. 🤷♀️
- The Printer MUST support the attribute. 🫡
- The attribute MUST NOT be READ-ONLY, i.e., the definition of the attribute MUST NOT indicate that the attribute is READ-ONLY (see Appendix A for an indication of which IPP/1.1 attributes are READ-ONLY). 🔒
- The attribute MUST be settable in this implementation. ⚙️
- The Printer MUST support the value, according to the rules defined in Appendix A, i.e., each value of each supplied "xxx" attribute MUST be validated against the value of a corresponding "xxx-supported" Printer attribute. One of those rules permits an administrator to set arbitrary 'name' values to those "xxx-supported" Printer attributes that include the 'name' attribute syntax, if the implementation supports the 'admin-define' out-of-band value for that "xxx-supported" attribute (see section 8.3 and Appendix A). 🧐
- The attribute's values MUST NOT conflict with the values of other Printer attributes, including ones being set in this same operation. 🚫
⚠️ all-or-nothing energy: if any of the supplied attributes are not validate, the Printer object MUST reject the entire operation. the Printer object MUST NOT partially set some of the supplied attributes. after the operation, all the supplied attributes MUST be set or none of them MUST be set, which makes Set-Printer-Attributes an atomic operation. no halfway, periodt 💯
the Printer MUST accept this operation when its READ-ONLY "printer-state" attribute (see [RFC2911], section 4.4.11) is 'idle' or 'stopped', and SHOULD accept it when the value is 'processing' 🖨️💨 the Printer MUST accept this operation for any of the values of the Printer object's READ-ONLY "printer-state-reasons" and "printer-is-accepting-jobs" attributes, unless the definition of these attributes' values explicitly says otherwise. 🌈
this operation MUST NOT change the value of attributes that aren't specified in the operation, unless the definition of the attribute explicitly specifies such side-effects. for example, this document explicitly specifies that when this operation sets "printer-message-from-operator", the Printer also MUST set the READ-ONLY "printer-message-time" and READ-ONLY "printer-message-date-time" attributes to the time of the operation as a side effect. ⏰ in particular, if this operation changes an "xxx-default" attribute, the new value MUST be in the "xxx-supported" attributes, or the request MUST contain a new value for "xxx-supported" that includes the new value for the "xxx-default". otherwise, the Printer MUST reject the operation. 🙅♀️ in general, settable Printer attribute definitions won't define side effects on other settable attributes, only side effects on READ-ONLY attributes (if any). main character energy for the attribute system 👑✨
4.1.1 Settable and READ-ONLY Printer Description attributes
okay so if the Printer supports the Set-Printer-Attributes operation, then it SHOULD support setting all of these 💅:
- all Job Template Default (
xxx-default) attributes - all Job Template Supported (
xxx-supported) attributes - all Job Template Ready (
xxx-ready) attributes
...as long as the implementation actually supports them (see [RFC2911] section 4.2 and extensions) ✨
some Printer Description attributes (see [RFC2911] section 4.4) MUST NOT be settable, aka they're defined to be READ-ONLY 🔒. any attribute marked "READ-ONLY" in the Printer Description attribute table in Appendix A is one of these. the Printer attributes that aren't marked "READ-ONLY" MAY be settable with the Set-Printer-Attributes operation, depending on the implementation 🦋
Note: From now on, every extension that defines new object attributes will say whether they're READ-ONLY, by putting the "READ-ONLY" adjective in their descriptions and/or explicitly stating whether they MAY be settable. no more guessing, bestie 🫶
the current values of each xxx-supported Printer attribute MUST reflect the current policy for support of the matching xxx attribute 🎀. if an xxx-supported Printer attribute is settable in an implementation, then its value(s) MUST affect how the implementation actually behaves 🔥. if an xxx-supported Printer attribute is defined to be READ-ONLY or is not-settable in an implementation, then its values MUST NOT be settable using the Set-Printer-Attributes operation 🙅♀️. here are some examples, because examples are everything:
For example, if the operations-supported Printer Description attribute (see [RFC2911] section 4.4.15) is settable in a particular implementation, then changing its value with a Set-Printer-Attributes operation MUST affect which operations that implementation accepts or rejects 🍓. an implementation like that needs to be able to reject values for operations it has no code support for (see section 4.3). if operations-supported is NOT settable in a particular implementation, then that implementation MUST reject an attempt to set it with a Set-Printer-Attributes operation, return the client-error-attributes-not-settable status code (see section 7.1), and return the operations-supported attribute with the out-of-band not-settable value in the Unsupported Attributes Group. rude 💀
another one: picture an implementation where media-default and media-supported are both settable. if a client sends a Set-Printer-Attributes request with a media-default value that isn't a member of the Printer's media-supported attribute, the Printer MUST reject the request and return the client-error-conflicting-attributes status code with the media-default and media-supported attributes and their values (see [RFC2911] section 3.1.7) 🧚
and a third one! if a client sends a Set-Printer-Attributes request that contains both media-default and media-supported, but the media-default value isn't a member of the supplied media-supported attribute, the Printer MUST reject the request and return the client-error-conflicting-attributes status code with the media-default and media-supported attributes and their values (see [RFC2911] section 3.1.7) 💜
Access Rights: the authenticated user (see [RFC2911] section 8.3) doing this operation must be an operator or administrator of the Printer object (see [RFC2911] Sections 1 and 8.5) 👑. most Printer attributes need administrator access rights to set, like xxx-supported, while some only need operator access rights, like media-ready and printer-message-from-operator. which attributes need which access rights depends on the implementation, and it MAY depend on site policy 🌸
4.1.2 Set-Printer-Attributes Request
the following sets of attributes make up the Set-Printer-Attributes Request 📦
Group 1: Operation Attributes 🎀
Natural Language and Character Set: the attributes-charset and attributes-natural-language attributes, as described in [RFC2911], section 3.1.4.1 🌈
Target: the printer-uri (uri) operation attribute, which is the target for this operation, as described in [RFC2911], section 3.1.5 🎯
Requesting User Name: the requesting-user-name (name(MAX)) attribute SHOULD be supplied by the client, as described in [RFC2911], section 8.3 🙋♀️
document-format (mimeMediaType): the client optionally supplies this attribute. the Printer object MUST support this attribute 💅. it's useful for picking which document-format the attribute change should apply to. a Printer implementation MAY let some attributes have different values for each document format it supports. see [RFC2911], section 3.2.5.1 "Get-Printer-Attributes Request" 🦋
if the client includes this attribute, the Printer MUST change the supplied attributes for the document format specified by it. if a supplied attribute is a member of the document-format-varying-attributes (aka the attribute varies by document format, see section 6.3), the Printer MUST change that attribute only for the document format specified, and not for other document formats 🔁. if a supplied attribute is NOT a member of document-format-varying-attributes (aka it doesn't vary by document format), the Printer MUST change the supplied attribute for all document formats 🌍
if the client omits this attribute, the Printer MUST change the supplied attributes for all document formats, whether or not they vary by document-format ✨
if the client supplies a value for the document-format Operation attribute that is either application/octet-stream or not supported by the Printer (aka not among the values of the Printer object's document-format-supported attribute), the Printer object MUST reject the operation and return the client-error-document-format-not-supported status code 🚫
Note: the document-format application/octet-stream is the union of several document-formats (see [RFC2911] section 3.2.5.1, Get-Printer-Attributes) and is NOT a true document-format. it's more of a bundle, not a real format 📦
Group 2: Printer Attributes 🌷
the client MUST supply a set of Printer attributes with one or more values (including explicitly allowed out-of-band values). these are defined in [RFC2911] section 4.2 Job Template Attributes (the xxx-default, xxx-supported, and xxx-ready attributes), section 4.4 Printer Description Attributes, and any attribute extensions the Printer supports 🧁. the value(s) of each Printer attribute supplied in Group 2 REPLACE the value(s) of the matching Printer attribute on the target Printer object. for attributes that can have multiple values (1setOf), all values the client supplies replace ALL values of the matching Printer object attribute 💥. if a Printer object attribute hadn't been configured yet, and so assumed the 'no-value' out-of-band value (see [RFC2911] section 4.1), the supplied value(s) replace that 'no-value' value 🫧
4.1.3 Set-Printer-Attributes Response
the Printer object returns the following sets of attributes as part of the Get-Printer-Attributes Response 📬
Group 1: Operation Attributes 🎀
Status Message: on top of the REQUIRED status code that comes back in every response, the response optionally includes a status-message (text(255)) and/or a detailed-status-message (text(MAX)) operation attribute, as described in [RFC2911] sections 3.1.6 and 13 💌
Natural Language and Character Set: the attributes-charset and attributes-natural-language attributes, as described in [RFC2911], section 3.1.4.2 🌏
Group 2: Unsupported Attributes 🚧
see [RFC2911], section 3.1.7, for details on returning Unsupported Attributes 🔍
if some of the attributes in the operation fail to validate, the Printer MUST reject the operation, MUST NOT change any Printer attributes, and MUST return the indicated status code below. in this group the Printer MUST also return ALL attributes that fail to validate 😭. these are the reasons an attribute fails to validate, plus what gets returned for the attribute, along with the status code and the order they're detected in:
- the number of attributes the client supplies goes over the maximum number the Printer supports in a Set-Printer-Attributes request: return the
client-error-request-entity-too-largestatus code (see [RFC2911], section 13.1.4.9) 📏 - the Printer doesn't support the attribute: return the attribute with the "out-of-band" value
unsupported(see [RFC2911] section 3.1.7 and [RFC2910]) and the `client-error-attributes-or-values-not-supported (see [RFC2911], section 13.1.4.12). 🙈 - the attribute is either READ-ONLY (in its definition) or not-settable in this implementation: return the attribute with the "out-of-band" value
not-settable(see section 8.1) and theclient-error-attributes-not-settablestatus code (see section 7.1) 🔒 - the Printer doesn't support the value: if the attribute in the operation has a single value, return it. if the attribute is multi-valued, return only the values in a 1setOf that aren't supported. return the
client-error-attributes-or-values-not-supportedstatus code (see [RFC2911], section 13.1.4.12) 🍬 - the values of some of the supplied attributes conflict with one another and/or with other Printer attribute values that aren't being set: if the conflicting attribute in the operation has a single value, return the attribute and the value. if the attribute is multi-valued, return only the attribute and those values in a 1setOf that conflict with other attributes. return the
client-error-conflicting-attributesstatus code (see [RFC2911], section 13.1.4.15) 💀🔥
4.2 Set-Job-Attributes Operation ✨
okay so this one is OPTIONAL 💅 (so implementers can skip it if they want), but when it's there it lets a client change the attributes of a Job object 🎀 The client sends along the Job keyword attribute names and values it wants to set. The IPP object then either says "success!" or rejects the whole request and tells the client which attribute or attributes couldn't be set 🙈
this operation is basically a twin of Set-Printer-Attributes and follows the same validation rules (see section 4.1) 👯 the differences are: it targets a Job object instead of a Printer object 🧚 there's no "document-format" operation attribute when you're setting a Job, the operation can add an attribute to the (Job) object 🌱 the delete-attributes out-of-band value is allowed to remove an attribute 🗑️ and validation matches the Job Creation operations (Print-Job, Print-URI, and Create-Job), so it depends on the "xxx-supported" Printer Description attributes (see [RFC2911] section 3.1) 💜
here's the lowkey tricky bit 👀 with Set-Printer-Attributes, the administrator can set arbitrary name values on those "xxx-supported" Printer attributes (including the name attribute syntax), as long as the implementation supports the admin-define out-of-band value for that "xxx-supported" attribute (see section 8.3 and Appendix A) 🔥 Set-Job-Attributes, though, can't be used to add unsupported names to the Job object 🙅♀️
If a client supplies a job attribute in a Set-Job-Attributes request that the Printer supports, and the job was originally submitted without that attribute, the Printer adds the attribute to the Job object 🌸
If the client supplies a job attribute with the "out-of-band" value delete-attribute (see section 8.2), then the Printer MUST remove the attribute and all of its values from the Job object, if they're there 🧹 the semantic effect of delete-attribute MUST be the same as if the attribute had never been supplied with the Job in the Job Creation operation 🫶 in other words, the Printer falls back to its default attribute or behavior, which has lower precedence than the PDL (see the beginning of [RFC2911] section 4.2 and [RFC2911] 3.2.1.1) 🦋 after that, any later query of the Job using Get-Job-Attributes or Get-Jobs MUST NOT return an attribute that was deleted with delete-attribute 🙈 but a client can bring a deleted Job attribute back with any supported value(s) using a later Set-Job-Attributes operation 💖
⚠️ If a client sends an attribute with thedelete-attributevalue and that attribute isn't on the Job object, the Printer ignores it. It doesn't show up in the Unsupported Attributes group, and the Printer returns thesuccessful-okstatus code, as long as nothing else is wrong with the request 💀
the Printer validates a Set-Job-Attributes request as if the job had been submitted from scratch with the new attribute values (and the deleted attributes removed), with "ipp-attribute-fidelity" set to true 🧠 that means every modified Job attribute and value MUST be supported in combination with the Job attributes that weren't modified 🧩 if that Job Creation would have been accepted, the Set-Job-Attributes MUST be accepted ✅ if it would have been rejected, the Set-Job-Attributes MUST be rejected and the Job MUST be unchanged ❌ and if any supplied attribute is unsupported, not settable, or has an unsupported value, the Printer object MUST reject the entire operation 😤 the Printer object MUST NOT partially set some of the supplied attributes 🚫 after the operation, either all the supplied attributes MUST be set or none of them MUST be set, which makes Set-Job-Attributes an atomic operation ⚛️🎀
The IPP object MUST accept or reject this operation based on the Job's READ-ONLY "job-state" attribute, and the job's current state MUST affect whether the request is accepted or rejected 🌈 for example, if the operation creates a request for unavailable resources, the Job transitions to a new state 🔄 Table 2 lays out what's allowed in each job state and the transitions between them 📋
Table 2 - Job State Transition Table for the Set-Job-Attributes
operation
Current New IPP object's response status code
"job-state" "job-state" and "action":
'pending' 'pending' 'successful-ok'
'pending' 'pending-held' 'successful-ok' - needed resources
are not ready
'pending-held' 'pending-held' 'successful-ok'
'pending-held' 'pending' 'successful-ok' - needed resources
are ready
'processing' 'processing' 'successful-ok' or 'client-error-
not-possible' depending on
implementation, including the
attributes being set, whether the
job has started marking media,
etc.
'processing- 'processing- 'successful-ok' or 'client-error-
stopped' stopped' not-possible' depending on
implementation, including the
attributes being set, whether the
job has started marking media,
etc.
'completed' 'completed' 'client-error-not-possible'
'canceled' 'canceled' 'client-error-not-possible'
'aborted' 'aborted' 'client-error-not-possible'This operation MUST NOT change the value of attributes that aren't named in the operation, unless the attribute's definition explicitly says it has such side-effects 🙅♀️ generally, settable Job attribute definitions won't define side-effects on other settable attributes, only on READ-ONLY attributes if there are any 🫧
4.2.1 Settable and READ-ONLY Job Description attributes
if the Printer supports the "job-message-from-operator" Job Description attribute (see [RFC2911] section 4.3.16) and the client explicitly supplies a new value for it in Group 2 of the Set-Job-Attributes request, then the Printer MUST set "job-message-from-operator" to that new value 💌
if the Printer supports Set-Job-Attributes, then it SHOULD support setting:
all Job Template job ("xxx") attributes
that the implementation supports (see [RFC2911] section 4.2 and extensions) 🛠️
some Job Description attributes (see [RFC2911] section 4.3) MUST NOT be settable, meaning they're defined as READ-ONLY 🔒 any attribute marked "READ-ONLY" in the Job Description attribute table in Appendix A is one of these 🙅♀️ the Job attributes that aren't marked "READ-ONLY" MAY be settable using Set-Job-Attributes, depending on the implementation 🤷♀️
📣 Note: From now on, every extension that defines new object attributes will say whether those attributes are READ-ONLY, either by using the "READ-ONLY" adjective in their descriptions or by explicitly stating whether they MAY be settable. ✨
Access Rights: the authenticated user (see [RFC2911] section 8.3) doing this operation has to 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) 👑
4.2.2 Set-Job-Attributes Request
the Set-Job-Attributes Request is made up of these sets of attributes 📦
Group 1: Operation Attributes 🎀
- Natural Language and Character Set: the "attributes-charset" and "attributes-natural-language" attributes, as described in [RFC2911], section 3.1.4.1 🌍
- Target: either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)), or (2) the "job-uri" (uri) operation attribute(s). Together they define the target of this operation, as described in [RFC2911], section 3.1.5 🎯
- Requesting User Name: the "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client, as described in [RFC2911], section 8.3 🙋♀️
Group 2: Job Attributes 🧁
- the client MUST supply a set of Job attributes with one or more values (including explicitly allowed out-of-band values), as defined in [RFC2911], section 4.2 (Job Template Attributes, the "xxx" attributes), section 4.3 (Job Description Attributes), and any attribute extensions the Printer supports 📝 the value(s) of each Job attribute supplied in Group 2 replace the value(s) of the matching Job attribute on the target Job object 🔁 for attributes that can have multiple values (1setOf), all the values the client supplies replace all the values of the matching Job object attribute 🫧
- if the client supplies an "xxx" attribute with the
delete-attributeout-of-band value (see section 8.2), the Printer MUST remove that "xxx" attribute from the Job object, if it's there 🧹💜
4.2.3. Set-Job-Attributes Response 🎀
okay so the IPP object sends back these sets of attributes as part of the Set-Job-Attributes Response 💅
Group 1: Operation Attributes 🧚
Status Message: ngl this one's simple. On top of the REQUIRED status code that shows up in every response, the response OPTIONALLY includes a status-message (text(255)) and/or a detailed-status-message (text(MAX)) operation attribute, as described in [RFC2911], sections 3.1.6 and 13. ✨
Natural Language and Character Set: the attributes-charset and attributes-natural-language attributes, as described in [RFC2911], section 3.1.4.2. 🌸
Group 2: Unsupported Attributes 💀
See [RFC2911], section 3.1.7, for details on returning Unsupported Attributes. 🫶
If some of the attributes in the operation fail to validate, the Printer MUST reject the operation, MUST NOT change any Job attributes, and MUST return the indicated status code below. 😭 In this group, the Printer MUST also return all attributes that fail to validate. Here are the reasons an attribute fails to validate, plus what gets returned for it, the status code, and the order they're checked in 🔥
- The number of attributes the client sends is more than the maximum the Printer supports in a Set-Printer-Attributes request. Return the
client-error-request-entity-too-largestatus code (see [RFC2911], section 13.1.4.9). 🍓 - The Printer doesn't support the attribute. Return the attribute with the
unsupportedout-of-band attribute value (see [RFC2911], section 3.1.7 and [RFC2910]) and the `client-error-attributes-or-values-not-supported (see [RFC2911], section 13.1.4.12). 🙈 - The attribute is READ-ONLY (in its definition) or is not-settable in this implementation. Return the attribute with the
not-settableout-of-band attribute value (see section 8.1) and theclient-error-attributes-not-settablestatus code (see section 7.1). 👑 - The Printer doesn't support the value. If the attribute in the operation has a single value, return it. If the attribute in the operation is multi-valued, return only those values in a
1setOfthat are not supported. Return theclient-error-attributes-or-values-not-supportedstatus code (see [RFC2911], section 13.1.4.12). 💜 - The values of some of the supplied attributes conflict with one another and/or with other Job attribute values that aren't being set. If the conflicting attribute in the operation has a single value, return the attribute and the value. If the attribute in the operation is multi-valued, return only the attribute and those values in a
1setOfthat conflict with other attributes. Return theclient-error-conflicting-attributesstatus code (see [RFC2911],y section 13.1.4.15). 🌈
4.3. Get-Printer-Supported-Values Operation 🧚♀️
This OPTIONAL operation lets a client ask for the values the Printer allows in the Set-Printer-Attributes operation for "xxx-supported" attributes. ✨ If the Printer supports the Set-Printer-Attributes operation AND some of its "xxx-supported" Printer attributes are settable, then the Printer MUST also support this operation. 💖
The Printer MUST return, in the Get-Printer-Supported-Values response, those "xxx-supported" Printer attributes that it supports setting with the Set-Printer-Attributes operation, and only those. 🫶 Also, if a client asks for the value of an attribute that is not settable or is not supported (as in the Get-Printer-Attributes response), the Unsupported Attributes Group of the response NEED NOT contain the requested-attributes operation attribute with any such requested (attribute keyword) values. 🙈
This operation has identical request/response attributes to the Get-Printer-Attributes operation in IPP/1.1 [RFC2911]. It also behaves identically to the Get-Printer-Attributes operation in IPP/1.1 [RFC2911], with the following exceptions: 🦋
- The Get-Printer-Supported-Values operation supports only "xxx-supported" attributes. 💅
- The Get-Printer-Attributes operation returns the few "xxx-supported" attributes defined to be single valued, such as
page-ranges-supported(boolean) orpdl-override-supported(type2 keyword), as single values. Get-Printer-Supported-Values instead returns the possible values that can be set, as a1setOfof the same attribute syntax type (See Appendix B: Attributes returned from Get-Printer-Supported-Values). 🌸 - The Get-Printer-Attributes operation returns the current values of requested attributes. The Get-Printer-Supported-Values operation returns the values that are inherently supported by the implementation code, i.e., the values an administrative client can set in a Set-Printer-Attributes request. 🧠
- The Get-Printer-Attributes operation returns the current values of requested "xxx-supported" attributes that the Printer is configured to accept in Job Creation operations, including additional values defined by the administrator. The Get-Printer-Supported-Values operation returns only the values of "xxx-supported" attributes that are inherently supported by the implementation, and does not return any additional values defined by the administrator, where the implementation supports the 'admin-define' out-of-band value. 🍓
- The Get-Printer-Attributes operation never returns the 'admin-define' out-of-band attribute value. The Get-Printer-Supported-Attributes operation does, if the implementation allows the administrator to define
namevalues by setting that "xxx-supported" attribute with anynamevalue(s). 🔥 - The Get-Printer-Attributes operation only requires end-user access rights. The Get-Printer-Supported-Values operation requires administrator access rights. 👑
Access Rights: The authenticated user (see [RFC2911], section 8.3) performing this operation must be an administrator of the Printer object (see [RFC2911], Sections 1 and 8.5). 🔐
4.3.1. Definition of the usage of the 'admin-define' out-of-band attribute value 🍓
If the Set-Printer-Attributes operation allows the System Administrator to define arbitrary 'name' values for an "xxx-supported" attribute, then the Get-Printer-Supported-Values operation MUST return the 'admin-define' out-of-band attribute value (see section 8.3) as one of the values of the "xxx-supported" attribute. 💖 In other words, the 'admin-define' out-of-band attribute value says the Printer implementation supports clients setting arbitrary 'name' attribute syntax values for that "xxx-supported" attribute using the Set-Printer-Attributes operation, as long as the attribute is defined with the 'name' attribute syntax. 🧚
For example, if the Get-Printer-Supported-Values operation returns several keywords as the value of the "media-supported" attribute, then the Set-Printer-Attributes operation MUST accept any of these keywords as values for the "media-supported" attribute. If the Get-Printer-Supported-Values operation returns an 'admin-define' out-of-band attribute value as one of the values of the "media-supported" attribute, then the Set-Printer-Attributes operation MUST accept any value whose attribute syntax is 'name' as a value for the "media-supported" attribute (provided that the user is properly authenticated to use the Set-Printer-Attributes operation, e.g., has administrative access rights). 👑
The Get-Printer-Supported-Values operation MAY return the 'admin-define' out-of-band attribute value for any IPP/1.1 or extension Job Template attribute, if the implementation supports allowing the System Administrator to add values to the "xxx-supported" attribute using the Set-Printer-Attributes operation. In this case, the Printer MUST accept any 'name' value of the correct attribute syntax in a Set-Printer-Attributes operation that is setting that attribute. 🌈 For "xxx-supported" attributes that are defined with a choice of attribute syntaxes, such as 'keyword | name', it's the 'name' attribute syntax that the System Administrator can use to add new values, not the 'keyword' attribute syntax. For IPP/1.1, this requirement includes the following Job Template attributes: 🍓
media-supported
job-hold-until-supported
job-sheets-supportedImplementations that support additional Job Template attributes that include the 'name' attribute syntax MAY use the 'admin-define' out-of-band value with them. 🦋
If the 'admin-define' out-of-band attribute value is not one of the values of an "xxx-supported" attribute returned in a Get-Printer-Supported-Values response, then the Printer MUST NOT allow the Set-Printer-Attributes operation for that attribute to contain a value that is not one of the explicit 'keyword' or 'name' values returned in a Get-Printer-Supported-Values response. 🙈
See Appendix B: Attributes returned from Get-Printer-Supported-Values for a full list of values returned by this operation. 💜
5. New Operation attributes ✨
This section defines new operation attributes for use with the IPP/1.1 operations indicated. As new operations are defined, they will also indicate explicitly whether these operation attributes are defined for use with them. 🎀
5.1 printer-message-from-operator (text(127)) 💌
The Printer SHOULD support this Operation attribute in the following operations, as long as it supports the matching printer-message-from-operator Printer Description attribute 💖
Pause-Printer
Resume-Printer
Purge-JobsThe client can optionally send this Operation attribute in the operations above 📮 Its value is a message from the operator about the Printer object they're working on. If the Printer supports this operation attribute, it copies the value into its printer-message-from-operator Printer Description attribute (see [RFC2911], section 4.4.25) 🎀. It does this even if the value is a zero-length text value or is only white space, so nothing gets quietly dropped ✨
Now, if the Printer supports this operation attribute, it MUST support both a zero-length text value and the 'no-value' out-of-band value (see [RFC2911] section 4.1) 🫶. That's how it says "the operator sent no message." In that case, the Printer sets printer-message-from-operator to the zero-length value or to 'no-value', respectively 🌸. If a client asks for printer-message-from-operator, the Printer hands back that zero-length value or the 'no-value' value, respectively 💅
On top of that, the Printer automatically copies two things:
- the value of its
printer-up-timeattribute (see [RFC2911], section 4.4.29) into itsprinter-message-timeattribute, and - the value of its
printer-current-time(dateTime) attribute (see [RFC2911], section 4.4.30) into itsprinter-message-date-timeattribute, if supported 🕰️
If the client leaves this operation attribute out, the Printer does NOT change its printer-message-from-operator, printer-message-time, or printer-message-date-time Printer Description attributes. Hands off, they stay put 🙈
Here's the big one. The printer-message-from-operator operation attribute MUST NOT be supported as an operation attribute for the Set-Printer-Attributes operation 🚫 If the operator wants to set the Printer's printer-message-from-operator Printer Description attribute during a Set-Printer-Attributes operation, the client supplies printer-message-from-operator explicitly with its new value, as one of the Printer Description attributes in Group 2 of the request 📝 The Printer also updates its printer-message-time and printer-message-date-time Printer Description attributes. If the client doesn't explicitly supply printer-message-from-operator with a new value in the Set-Printer-Attributes request, the Printer leaves that attribute unchanged 💜
5.2 job-message-from-operator (text(127)) 🧚
The Printer SHOULD support this Operation attribute in the following operations, as long as it supports the matching job-message-from-operator Job Description attribute 🌈
Cancel-Job
Hold-Job
Release-Job
Restart-JobThe client can optionally send this attribute in the operations above 📬 Its value is a message from the operator about the Job object they just operated on. If it's supported, the Printer copies the value into the Job's job-message-from-operator Job Description attribute (see [RFC2911], section 4.3.16). It does this even if the value is a zero-length text value or is only white space 🍓
If the Printer supports this operation attribute, it MUST support both a zero-length text value and the 'no-value' out-of-band value (see [RFC2911], section 4.1) 🌷 That's the "no message was sent" signal. In that case, the Printer sets job-message-from-operator to the zero-length value or to 'no-value', respectively. If a client queries the job-message-from-operator Job attribute, the IPP object returns the zero-length value or the 'no-value' value, respectively 💖
If the client leaves this attribute out, the Printer does NOT change the Job's job-message-from-operator Job Description attribute ✨
Note: There are no correspondingjob-message-timeandjob-message-date-timeJob Description attributes, since a job's usual lifetime is limited ⏳
The job-message-from-operator operation attribute MUST NOT be supported as an operation attribute for the Set-Job-Attributes operation 🛑 If the operator wants to set the Job's job-message-from-operator Job Description attribute during a Set-Job-Attributes operation, the client MUST supply job-message-from-operator with its new value, as one of the Job Description attributes in Group 2 of the request 🎀 Otherwise, the Printer leaves the Job's job-message-from-operator Job Description attribute unchanged by not explicitly setting it. And if the client doesn't explicitly supply job-message-from-operator with a new value in the Set-Job-Attributes request, the Printer leaves that attribute unchanged too 🫧
6. New Printer Description Attributes 🌟
The following new Printer Description attributes are needed to support the new operations defined in this document 🦋
6.1 printer-settable-attributes-supported (1setOf type2 keyword) 👑
This REQUIRED READ-ONLY Printer Description attribute identifies the Printer object attributes that are settable in this implementation, meaning the ones that can be set using the Set-Printer-Attributes operations (see section 4.1) 🔥 This attribute MUST be supported if the Set-Printer-Attributes operations are supported. The Printer MUST reject attempts to set any Printer attributes that aren't one of this attribute's values, and it returns the 'client-error-attributes-not-settable' status code (see section 7.1) 🙅♀️ The value of this attribute MAY depend on the value of the document-format operation attribute supplied in the Get-Printer-Attributes operation (see [RFC2911], section 3.2.5.1) 🌈
Standard keyword values are:
'none': There are no settable Printer attributes.'xxx': Where 'xxx' is any of the keyword attribute names allowed by section 4.1.1. 💅
6.2 job-settable-attributes-supported (1setOf type2 keyword) 🎀
This REQUIRED READ-ONLY Printer Description attribute identifies the Job object attributes that are settable in this implementation, meaning the ones that can be set using the Set-Job-Attributes operation (see section 4.2) 🍓 This attribute MUST be supported if the Set-Job-Attributes operations are supported. The Printer MUST reject attempts to set any Job attributes that aren't one of this attribute's values, and it returns the 'client-error-attributes-not-settable' status code (see section 7.1) 🙈
Standard keyword values are:
'none': There are no settable Job attributes.'xxx': Where 'xxx' is any of the keyword attribute names allowed by section 4.2.1. 🫶
6.3 document-format-varying-attributes (1setOf type2 keyword) 🌸
This OPTIONAL READ-ONLY Printer Description attribute holds a set of attribute name keywords 🗂️ This attribute SHOULD be supported by a Printer object if that Printer object has Printer attributes whose values vary depending on document format (see [RFC2911], Get-Printer-Attributes operation) ✨ It specifies which attribute values can vary by document-format. If an attribute's name, "xxx", is a member of this attribute, and the value of attribute "xxx" is changed with a Set-Printer-Attributes operation that included the document-format operation attribute, then the Printer MUST change the value for the specified document format and no other document formats (see section 4.1.2) 💜 If an attribute's name, "xxx", is NOT a member of this attribute, and the value of attribute "xxx" is changed with the Set-Printer-Attributes operation, then the attribute changes for all document formats, whether or not the client supplied the document-format operation attribute 🌍
6.4 printer-message-time (integer(MIN:MAX)) ⏰
This OPTIONAL READ-ONLY Printer Description attribute holds the time the Printer's printer-message-from-operator was changed by the operator. That can happen through any operation where the client supplied the printer-message-from-operator operation attribute (see section 5.1), or when it was explicitly set using the Set-Printer-Attributes operation (see section 4.1) 🕒 It lets users know when printer-message-from-operator was last set 💖
The Printer sets this attribute's value by copying the value of the Printer's printer-up-time attribute (see [RFC2911], section 4.3.14). If the Printer resets its printer-up-time attribute to 1 on power-up, then it MUST change the value of printer-message-time to 0 or to a negative number, as specified in [RFC2911], section 4.3.14 ⚡
Note: This attribute helps users understand the context for the printer-message-from-operator message 🧠
6.5 printer-message-date-time (dateTime) 📅
This OPTIONAL READ-ONLY Printer Description attribute holds the date and time the Printer's printer-message-from-operator was changed by the operator. That can happen through any operation where the client supplied the printer-message-from-operator operation attribute (see section 5.1), or when it was explicitly set using the Set-Printer-Attributes operation (see section 4.1) 🌷 It lets users know when the printer-message-from-operator Printer Description attribute was last set 🫧
This attribute MUST be supported if the Printer supports both the printer-message-time and the printer-current-time (dateTime) attributes (see [RFC2911], section 4.4.30) 🔥
Note: This attribute helps users understand the context for the printer-message-from-operator message 💌
6.6 printer-xri-supported (1setOf collection) ✨
okay bestie, this one is OPTIONAL 💅 It's a multi-valued Printer Description attribute, and each value uses the 'collection' attribute syntax (see [RFC3382]). Its member attributes mean the same things as these IPP/1.1 READ-ONLY Printer Description attributes, except for cardinality:
printer-uri-supported (1setOf uri)
- see [RFC2911], section 4.4.1
uri-authentication-supported (1setOf type2 keyword)
- see [RFC2911], section 4.4.2.
uri-security-supported (1setOf type2 keyword)
- see [RFC2911], section 4.4.3.When a Printer gets the "printer-xri-supported" attribute through a Set-Printer-Attributes request, it MUST also set those three IPP/1.1 READ-ONLY Printer Description attributes as a side effect 🔥 That's the whole point of this collection: you can set all three atomically, so they're never left half-updated and mismatched. Iconic design, honestly 😭
An IPP Printer MUST NOT give you any other way, using IPP, to set those three IPP/1.1 READ-ONLY Printer Description attributes. They're READ-ONLY, so they MUST have consistent values at all times 🫶
Note: The "printer-xri-supported" (1setOf collection) attribute can go into a directory schema that wants a single text string value, like the ones used with SLPv2 [RFC2608], [RFC2609] or LDAPv3 [RFC2251], [RFC2252], [RFC2926]. You just use suitable delimiting characters to separate the member attributes of the collection and/or to end the collection values. Clever, right? 🧚
The member attributes of "printer-xri-supported" (1setOf collection) are listed in Table 3:
Table 3 - Member attributes of "printer-xri-supported" (1setOf
collection)
Member attribute client Printer
MUST MUST
supply support
xri-uri (uri) yes yes
xri-authentication (type2 keyword) yes yes
xri-security (type2 keyword) yes yesApart from the uniqueness and cardinality requirements, these three member attributes mean what [RFC2911] sections 4.4.1, 4.4.2, and 4.4.3 say they mean, in that order 🦋
A client can check the current values with the Get-Printer-Attributes operation. It can ask in either of two ways:
- Supply the three IPP/1.1 attribute names: "printer-uri-supported", "uri-authentication-supported", "uri-security-supported", and get back the parallel values OR
- Supply the single attribute name: "printer-xri-supported", and get back the 1setOf collection, which holds the same information semantically but in a different form 💖
A client can also ask which member attribute values are settable. It does this by supplying the three attribute names "xri-uri-scheme-supported", "xri-authentication-supported", and "xri-security-supported" in a Get-Printer-Supported-Values request. It gets back the uriScheme and type2 keyword values that can be set. Since "printer-xri-supported", "uri-authentication-supported", and "uri-security-supported" are READ-ONLY, you can't query them with the Get-Printer-Supported-Values operation (see section 4.3). See Table 16 🌸
Here's an example:
"printer-xri-supported =
{ "xri-uri" = ipp://abc.com/p1
"xri-authentication" = basic
"xri-security" = tls
},
{ "xri-uri" = ipp://abc.com/p2
"xri-authentication" = digest
"xri-security" = tls
},
{ "xri-uri" = ipp://abc.com/p3
"xri-authentication" = none
"xri-security" = none
}Setting that would make the Printer set the three matching IPP/1.1 READ-ONLY attributes, each with three parallel values:
"printer-uri-supported" = { ipp://abc.com/p1, ipp://abc.com/p2,
ipp://abc.com/p3 }
"uri-authentication-supported" = { basic, digest, none }
"uri-security-supported" = { tls, tls, none }6.7 xri-uri-scheme-supported (1setOf uriScheme) 🌈
This OPTIONAL READ-ONLY Printer Description attribute lists the URI schemes the implementation supports for use in the "printer-uri-supported" (1setOf uri) Printer Description attribute (see [RFC2911] section 4.4.1). It also covers the "xri-uri" member attribute of the "printer-xri-supported" (1setOf collection) Printer Description attribute (see section 6.6) 🧚
A Printer MUST support this attribute if it supports setting "printer-xri-supported" (1setOf collection) with the Set-Printer-Attributes operation. ✨
6.8 xri-authentication-supported (1setOf type2 keyword) 🔐
This OPTIONAL READ-ONLY Printer Description attribute lists the Client Authentication mechanisms the implementation supports. They're for use in the "uri-authentication-supported" (1setOf type2 keyword) Printer Description attribute (see [RFC2911], section 4.4.2) and the "xri-authentication" member attribute of the "printer-xri-supported" (1setOf collection) Printer Description attribute (see section 6.6) 💜
A Printer MUST support this attribute if it supports setting the "printer-xri-supported" (1setOf collection) with the Set-Printer-Attributes operation. 🫶
6.9 xri-security-supported (1setOf type2 keyword) 🛡️
This OPTIONAL READ-ONLY Printer Description attribute lists the URI schemes the implementation supports for use in the "uri-security-supported" (1setOf type2 keyword) Printer Description attribute (see [RFC2911], section 4.4.3). It also covers the "xri-security" member attribute of the "printer-xri-supported" (1setOf collection) Printer Description attribute (see section 6.6) 🎀
A Printer MUST support this attribute if it supports setting the "printer-xri-supported" (1setOf collection) with the Set-Printer-Attributes operation. 💅
7 Additional status codes 🎀
This section defines new status codes for the operations in this document. 🌸
7.1 client-error-attributes-not-settable (0x0413) 🙈
The Set-Printer-Attributes or Set-Job-Attributes operation failed because one or more of the attributes in the request can't be set. Either the attribute is defined as READ-ONLY, or it isn't settable in this implementation (see sections 4.1.3 and 4.2.3). The Printer MUST return this error code, along with the attribute keyword name(s) and the 'not-settable' out-of-band value (see section 8.1), in the Unsupported Attributes Group (see [RFC2911], section 3.1.7). That goes for every attribute that couldn't be set. When the Printer returns this status, it MUST NOT change any of the attributes supplied in the operation. 😭
8 Additional out-of-band values 🧚
This section defines additional out-of-band values. Same rule as always: a client or a Printer MUST NOT use an out-of-band value unless the definition of the attribute in an operation request and/or response explicitly allows that usage. See the beginning of [RFC2911], section 4.1 💖
8.1 'not-settable' out-of-band value 🚫
The Printer uses the 'not-settable' out-of-band attribute value in the Unsupported Attributes group of a response. It means the attribute the client sent in the request is READ-ONLY by definition, or it isn't settable in this implementation 💅
The 'not-settable' out-of-band attribute value is defined only for use with Set-Job-Attributes and Set-Printer-Attributes responses. If a future "set" operation wants to allow the 'not-settable' out-of-band value, its definition document MUST say so explicitly, including which attributes it applies to. 🫶
An IPP object MUST support the 'not-settable' out-of-band value in a Set-Job-Attributes or Set-Printer-Attributes request if it supports those operations. A client MUST NOT supply the 'not-settable' out-of-band value in any request. An IPP object MUST NOT support the 'not-settable' out-of-band value in other operations, unless that operation's definition document explicitly defines such usage. If a Printer gets this out-of-band value in any operation request, it MUST either (1) reject the entire request and return the 'client-error-bad-request' status code, or (2) ignore the attribute and return it with the 'unsupported' out-of-band value. 🔥
See sections 4.1.3 and 4.2.3 in this document for an example definition of how the 'not-settable' out-of-band value is used in the Set-Printer-Attributes and Set-Job-Attributes responses 🌈
8.1.1 Encoding of the 'not-settable' out-of-band attribute value 🔢
The 'not-settable' out-of-band value is encoded as 0x15 (see [RFC2910]). The value-length MUST be 0 and the value empty. ✨
8.2 'delete-attribute' out-of-band value 🗑️
The client supplies the 'delete-attribute' out-of-band attribute value in a request to tell the Printer to remove the supplied attribute and all of its values from the target object, if they're present 🦋
The 'delete-attribute' out-of-band attribute value is defined only for use with Set-Job-Attributes requests. If a future "set" operation wants to allow the 'delete-attribute' out-of-band value, its definition document MUST say so explicitly, including which attributes it applies to. 💜
An IPP Printer MUST support the 'delete-attribute' out-of-band value if it supports the Set-Job-Attributes operation. A client MUST NOT supply the 'delete-attribute' out-of-band value, and an IPP object MUST NOT support it, in other operations, unless that operation's definition document explicitly defines such usage. For example, the 'delete-attribute' out-of-band value MUST NOT be used in the Set-Printer-Attributes operation, where an attribute being absent from an IPP object means the attribute isn't supported. If a Printer gets this out-of-band value in other operation requests, it MUST either (1) reject the entire request and return the 'client-error-bad-request' status code, or (2) ignore the attribute and return it with the 'unsupported' out-of-band value. 🙈
See section 4.2 in this document for the definition of how the 'delete-attribute' out-of-band value is used in the Set-Job-Attributes request 🍓
8.2.1 Encoding of the 'delete-attribute' out-of-band value 🔢
The 'delete-attribute' out-of-band value is encoded as 0x16 (see [RFC2910]). The value-length MUST be 0 and the value empty. 💅
8.3. 'admin-define' out-of-band attribute value ✨
okay so section 4.3 says the Get-Printer-Supported-Values response has to include the values of an "xxx-supported" attribute that the implementation already supports, before the admin adds anything custom. the 'admin-define' out-of-band value shows up there as an extra value, and it's basically the printer saying "hey, I let admins define extra arbitrary 'name' values for this attribute" 💅
for example, if "media-supported" (1setOf (type3 keyword | name)) has this value, then the Printer MUST permit an administrator to add new media names to the Printer's "media-supported" attribute. to add new values, the client sends the existing AND new values together in a Set-Printer-Attributes request for that attribute. the client MUST supply any such administratively defined values in the Set-Printer-Attributes request, using the 'name' attribute syntax 🎀
the 'admin-define' out-of-band value is only for the Get-Printer-Supported-Values response, bestie. a Printer MUST NOT return the 'admin-define' out-of-band value in a Get-Printer-Attributes response, because that response shows what an end-user client can supply in a Job Creation operation 🙈 if a future additional "get" operation ever allows it, that operation's definition document MUST indicate such use explicitly, including with which attributes 🧚
an IPP Printer MUST support the 'admin-define' out-of-band value if it lets a client set arbitrary 'name' values of an "xxx-supported" Printer attribute using the Set-Printer-Attributes operation. a client MUST NOT supply the 'admin-define' out-of-band value in any request. an IPP object MUST NOT support it in other operations, unless that operation's definition document explicitly defines such usage 💀 and if a Printer gets this out-of-band value in any operation request, the Printer MUST either (1) reject the entire request and return the 'client-error-bad-request' status code or (2) ignore the attribute and return it with the 'unsupported' out-of-band value. two options, pick your fighter 👑
this document defines that the 'admin-define' out-of-band value MUST be used only with "xxx-supported" attributes that are defined to include the 'name' attribute syntax. it's not meant for "xxx-supported" attributes with other attribute syntaxes, like 'uri', even though an admin can define arbitrary values for those too. if other documents extend the use of this value to other attribute syntaxes, such a document MUST define such use explicitly, including with which attributes 🦋
see section 4.3 in this document for an example definition of how the 'admin-define' out-of-band attribute value is used in any "xxx-supported" attribute returned in a Get-Printer-Supported-Values response that is defined to include the 'name' attribute syntax ✨
8.3.1. Encoding of the 'admin-define' out-of-band attribute value
the encoding of the 'admin-define' out-of-band attribute value is 0x17 (see [RFC2910]). the value-length MUST be 0 and the value empty 🍓
9. New Values for Existing Printer Description Attributes 🌈
this section has the attributes that get additional values added 💜
9.1. operations-supported (1setOf type2 enum)
the following "operation-id" values are added so we can support the new operations defined in this document:
Table 4 - Operation-id assignments
Value Operation Name
0x0013 Set-Printer-Attributes
0x0014 Set-Job-Attributes
0x0015 Get-Printer-Supported-Values10. Conformance Requirements 💅
this section lays out the conformance requirements for clients and IPP objects, so pay attention, it's important 🫶
both the Set-Job-Attributes and the Set-Printer-Attributes operations defined in this document are OPTIONAL for an IPP object to support. either one MAY be supported without the other, or both MAY be supported. however, if the Set-Printer-Attributes operation is supported, then the Get-Printer-Supported-Values operation MUST be supported if any "xxx-supported" attributes are settable. otherwise, the Get-Printer-Supported-Values operation is OPTIONAL for an IPP Printer to support ✨
if the Set-Printer-Attributes operation is supported, then the Printer MUST support the following additional items:
- the Get-Printer-Supported-Values operation (see section 5), if any
"xxx-supported"attributes are settable. - the
"printer-settable-attributes-supported"Printer Description attribute (see section 6.1). - the
'not-settable'out-of-band value in responses (see section 8.1). - the
'client-error-not-settable'status code (see section 7.1). - if the
"printer-message-from-operator"Printer Description attribute is supported (see [RFC2911], section 4.4.25), then it MUST be settable. - the Get-Printer-Supported-Values operation (see section 4.3), if any
"xxx-supported"attributes are settable. - If a client can set a value with the
'name'attribute syntax for one or more"xxx-supported"attributes, then the'admin-define'out-of-band attribute value (see section 8.3) MUST be supported in the Get-Printer-Supported-Values response for each such settable attribute (see section 4.3)
if the Set-Job-Attributes operation is supported, then the Printer MUST support the following additional items:
- the
"job-settable-attributes-supported"Printer Description attribute (see section 6.2). - the
'not-settable'out-of-band value in responses (see section 8.1). - the
'delete-attribute'out-of-band value in requests (see section 8.2). - the
'client-error-not-settable'status code (see section 7.1). - if the
"job-message-from-operator"Printer Description attribute is supported (see [RFC2911], 4.3.16), then it MUST be settable.
it's OPTIONAL for the Printer object to support the"printer-message-time"(integer) and"printer-message-date-time"(dateTime) Printer Description attributes. if both"printer-message-time"(integer) and"printer-current-time"(dateTime) (see [RFC2911], section 4.4.30) are supported, then"printer-message-date-time"(dateTime) MUST be supported. 🕰️
as with all out-of-band values, a client or a Printer MUST NOT use an out-of-band value unless the definition document for the attribute in an operation request and/or response explicitly allows such usage 🔥
11. IANA Considerations 🦋
this section has the registration info for IANA to add to the various IPP Registries, following the procedures defined in RFC 2911 [RFC2911], section 6. the registrations will be published in the registry at http://www.iana.org/assignments/ipp-registrations 🌸
11.1. Operation Registrations
this table lists all of the operations defined in this document. they get registered following the procedures in RFC 2911 [RFC2911], section 6.4 🎀
Operations: Ref. Section:
Set-Printer-Attributes RFC 3380 4.1
Set-Job-Attributes RFC 3380 4.2
Get-Printer-Supported-Values RFC 3380 4.311.2. Additional Enum Attribute Value Registrations for the "operations-supported" Printer Attribute
this table lists all the new enum attribute values defined in this document as additional type2 enum values for the "operations-supported" Printer Description attribute. they get registered following the procedures in RFC 2911 [RFC2911], section 6.1 🧚
Enum Attribute Values: Value Ref. Section:
Set-Printer-Attributes 0x0013 RFC 3380 4
Set-Job-Attributes 0x0014 RFC 3380 4
Get-Printer-Supported-Values 0x0015 RFC 3380 411.3. Keyword attribute value registrations
this table lists all of the attributes defined in this standard that have keyword values defined 💖
printer-settable-attributes-supported (1setOf type2 keyword)
RFC 3380 6.1
none RFC 3380 6.1
<Any other Printer attribute keyword name>
job-settable-attributes-supported (1setOf type2 keyword)
RFC 3380 6.2
none RFC 3380 6.2
<Any other Job attribute keyword name>
document-format-varying-attributes (1setOf type2 keyword)
RFC 3380 6.3
none
<Any Printer attribute keyword name>
xri-security-supported (1setOf type2 keyword) RFC 3380 6.9
none RFC 2911 4.4.3
ssl3 RFC 2911 4.4.3
tls' RFC 2911 4.4.3
xri-authentication-supported (1setOf type2 keyword)
none RFC 2911 4.4.2
requesting-user-name RFC 2911 4.4.2
basic RFC 2911 4.4.2
digest RFC 2911 4.4.2
certificate RFC 2911 4.4.211.4. Attribute Registrations
this table lists all of the attributes defined in this document. they get registered following the procedures in RFC 2911 [RFC2911], section 6.2 ⭐
Operation attributes: Ref. Section:
printer-message-from-operator (text(127)) RFC 3380 5.1
job-message-from-operator (text(127)) RFC 3380 5.2
Printer Description attributes: Ref. Section:
printer-settable-attributes-supported (1setOf type2 keyword)
RFC 3380 6.1
job-settable-attributes-supported (1setOf type2 keyword)
RFC 3380 6.2
document-format-varying-attributes (1setOf type2 keyword)
RFC 3380 6.3
printer-message-time (integer(MIN:MAX)) RFC 3380 6.4
printer-message-date-time (dateTime) RFC 3380 6.5
printer-xri-supported (1setOf collection) RFC 3380 6.6
xri-uri (uri) RFC 3380 6.6
xri-authentication (type2 keyword) RFC 3380 6.6
xri-security (type2 keyword) RFC 3380 6.6
xri-uri-scheme-supported (1setOf uriScheme) RFC 3380 6.7
xri-authentication-supported (1setOf type2 keyword) 6.8
xri-security-supported (1setOf type2 keyword) RFC 3380 6.911.5 Status code Registrations 📋
Okay bestie, this part is all about registering status codes 💅. The following table lists the status code defined in this document. This is to be registered according to the procedures in RFC 2911 [RFC2911], section 6.6.
Status codes: Ref. Section:
client-error-attributes-not-settable (0x0413) RFC 3380 7.111.6 Out-of-band Attribute Value Registrations 💜
Next up are the out-of-band attribute values 🦋. The following table lists all of the out-of-band attribute values defined in this document. These are to be registered according to the procedures in RFC 2911 [RFC2911] section 6.7.
Value: Out-of-band Attribute value name: Ref. Section:
0x15 not-settable RFC 3380 8.1
0x16 delete-attribute RFC 3380 8.2
0x17 admin-define RFC 3380 8.312 Internationalization Considerations 🌍
This document has the same localization considerations as [RFC2911].
13 Security Considerations 🔐
Okay, this section is seriously important, so pay attention 👀. The IPP Model and Semantics document ([RFC2911], section 8) discusses high level security requirements (Client Authentication, Server Authentication and Operation Privacy). Client Authentication is the mechanism by which the client proves its identity to the server in a secure manner. Server Authentication is the mechanism by which the server proves its identity to the client in a secure manner. Operation Privacy is defined as a mechanism for protecting operations from eavesdropping.
In addition, the introduction of the Set-Printer-Attributes and Set-Job-Attributes operations creates another security threat, since the client is able to modify the Printer and Job attributes stored in the Printer. Such modifications could lead to denial of service 😭.
A malicious user could alter the policy established by the system administrator and stored in the Printer attributes. Such alteration could either grant access to more resources or deny access to resources that the system administrator has established. For example, the malicious user could remove all of the document-format values from the "document-format-supported" Printer attribute so that the Printer would refuse to accept all jobs 💀.
The general remedy for such malicious user actions against Printer attributes is to have strong Client Authentication coupled with Printer access control, to limit the users who have System Administrator or Operator privileges.
A malicious user could modify the Job Template attributes of another user's Job, such as the "copies" attribute. For example, setting the number of copies to a large number 🙈.
The general remedy for such malicious user actions against another user's job is to have strong Client Authentication coupled with Printer access control to limit the users who have System Administrator or Operator privileges who can modify any job and, in addition, store the Client Authentication with each Job so that only the job owner End User can modify his/her own job.
14 References 📚
14.1 Normative References
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner, "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.0: Model and Semantics", RFC 2911, September 2000.
[RFC3382] deBry, R., Hastings, T., Herriot, R., Ocke, K. and P. Zehler, "Internet Printing Protocol (IPP): The 'collection' attribute syntax", RFC 3382, September 2002.
14.2 Informative References
[RFC2251] Wahl, M., Howes, T. abd S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 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.
Appendix A: Allowed Values for Set-Printer-Attributes and Set-Job-Attributes requests (Normative) 🎀
This appendix is a normative part of this document and contains a table of all IPP/1.1 attributes. Each row contains:
- an attribute and
- the values allowed in the Set-Printer-Attributes or Set-Job-Attributes request for the attribute.
The entry in each cell is the name (first few words) of each item below 1, 2, 3, 4a-g, and 5.
The allowed values include the following cases:
- READ-ONLY: the Set-Printer-Attributes or Set-Job-Attributes operation MUST NOT change this attribute and MUST reject the entire operation (see section 7.1).
- Any of "xxx-supported": the Set-Printer-Attributes or Set-Job-Attributes operation accepts values that are allowed according to the IPP/1.1 rules for validating the value(s) of an "xxx" Printer or Job attribute against the value(s) of the corresponding "xxx-supported" Printer attribute. Table 5 summarizes those validation rules depending on each attribute syntax and value of an "xxx" attribute supplied in the request and that of the corresponding "xxx-supported" Printer attribute. The "xxx-supported" attribute syntax type and value(s) are obtained from a Get-Printer-Supported-Values response (see the tables in this Appendix).
Table 5 - Validation rules for 'Any of "xxx-supported" '
Type of "xxx" Type of "xxx- Validates if:
value to be supported" value
set
integer rangeOfInteger each value is in one of the
"xxx-supported" ranges
uri uriScheme each uri scheme matches one
of the "xxx-supported"
schemes
any boolean if the boolean "xxx-
supported" is 'true'
any same type each value matches an "xxx-
supported" value of the same
typeFor additional non-normative explanatory information see section 3.1.2.3 of the "Internet Printing Protocol/1.1: Implementer's Guide" [RFC3196].
- From Get-Printer-Supported-Values: the Set-Printer-Attributes operation accepts values that are allowed according to the IPP/1.1 rules for validating the value(s) of an "xxx" Printer attribute against the value(s) of the corresponding "xxx-supported" Printer attribute. Table 6 summarizes those validation rules depending on each attribute syntax and value of an "xxx" attribute supplied in the request and that of the corresponding "xxx-supported" Printer attribute. The "xxx-supported" attribute syntax type and attribute value(s) are obtained from a Get-Printer-Supported-Values response (see Appendix B: Attributes returned from Get-Printer-Supported-Values below).
Table 6 - Validation rules for 'From Get-Printer-Supported-Values'
Type of -
"xxx" supported" value Validates if:
value to
be set Type of "xxx
integer rangeOfInteger each 'integer' value is in one of
the "xxx-supported" ranges
uri uriScheme the uri scheme of each value
matches one of the "xxx-supported"
schemes
any boolean if the boolean "xxx-supported" is
'true'
name 'admin-define' any 'name' value matches
out-of-band
value
any same type each value matches an "xxx-
supported" value of the same typeFor additional non-normative explanatory information see section 3.1.2.3 of the "Internet Printing Protocol/1.1: Implementer's Guide" [RFC3196].
- Any value of the proper attribute syntax: the Set-Printer-Attributes or Set-Job-Attributes operation accepts any value of the specified attribute syntax. The attribute syntaxes supported are enumerated below.
- a. Any text(127)
- b. Any name(127)
- c. Any uri
- d. Any boolean
- e. Any positive integer
- f. Any dateTime
- g. 1setOf any uri
- Combination of 'Any of "xxx-supported"' or 'Any name'. If a Printer implementation doesn't want to allow setting values indicated in this Appendix as "any xxx", it can make the value be not-settable.
Table 7 - Values allowed for Job Template Attributes in the Set-Job-Attributes Operation
Job Template Attributes Values allowed for
Set
job-priority (integer(1:100)) Any of "xxx-
supported"
job-hold-until (type3 keyword | name (MAX)) Any of "xxx-
supported"
job-sheets (type3 keyword | name(MAX)) Any of "xxx-
supported"
multiple-document-handling (type2 keyword) Any of "xxx-
supported"
copies (integer(1:MAX)) Any of "xxx-
supported"
finishings (1setOf type2 enum) Any of "xxx-
supported"
page-ranges (1setOf rangeOfInteger (1:MAX)) Any of "xxx-
supported"
sides (type2 keyword) Any of "xxx-
supported"
number-up (integer(1:MAX)) Any of "xxx-
supported"
orientation-requested (type2 enum) Any of "xxx-
supported"
media (type3 keyword | name(MAX)) Any of "xxx-
supported"
printer-resolution (resolution) Any of "xxx-
supported"
print-quality (type2 enum) Any of "xxx-
supported"Table 8 - Values allowed for Job Description Attributes in the Set-Job-Attributes Operation
Job Description Attributes Values allowed for
Setokay bestie, the job attributes table is up first and it's giving READ-ONLY everywhere 💅🎀
job-uri (uri) READ-ONLY
job-id (integer(1:MAX)) READ-ONLY
job-printer-uri (uri) READ-ONLY
job-more-info (uri) READ-ONLY
job-name (name(MAX)) Any name(MAX)
job-originating-user-name (name(MAX)) READ-ONLY
job-state (type1 enum) READ-ONLY
job-state-reasons (1setOf type2 keyword) READ-ONLY
job-state-message (text(MAX)) READ-ONLY
job-detailed-status-messages (1setOf READ-ONLY
text(MAX))
job-document-access-errors (1setOf READ-ONLY
text(MAX))
number-of-documents (integer(0:MAX)) READ-ONLY
output-device-assigned (name(127)) READ-ONLY
time-at-creation (integer(MIN:MAX)) READ-ONLY
time-at-processing (integer(MIN:MAX)) READ-ONLY
time-at-completed (integer(MIN:MAX)) READ-ONLY
job-printer-up-time (integer(1:MAX)) READ-ONLY
date-time-at-creation (dateTime) READ-ONLY
Job Description Attributes Values allowed for
Set
date-time-at-processing (dateTime) READ-ONLY
date-time-at-completed (dateTime) READ-ONLY
number-of-intervening-jobs (integer(0:MAX)) READ-ONLY
job-message-from-operator (text(127)) Any text(127)
job-k-octets (integer(0:MAX)) READ-ONLY
job-impressions (integer(0:MAX)) READ-ONLY
job-media-sheets (integer(0:MAX)) READ-ONLY
job-k-octets-processed (integer(0:MAX)) READ-ONLY
job-impressions-completed (integer(0:MAX)) READ-ONLY
job-media-sheets-completed (integer(0:MAX)) READ-ONLY
attributes-charset (charset) READ-ONLY
attributes-natural-language READ-ONLY
(naturalLanguage)Table 9 is where the job template stuff lives, and honestly it's a whole mood ✨
Table 9 - Values allowed for Printer Job Template Attributes in
the Set-Printer-Attributes Operation
Printer Job Template Attributes Values allowed
for Set
job-priority-default (integer(1:100)) Any of "xxx-
supported"
job-hold-until-default (type3 keyword | name Any of "xxx-
(MAX)) supported"
job-sheets-default (type3 keyword | name(MAX)) Any of "xxx-
supported"
multiple-document-handling-default (type2 Any of "xxx-
keyword) supported"
copies-default (integer(1:MAX)) Any of "xxx-
supported"
Printer Job Template Attributes Values allowed
for Set
finishings-default (1setOf type2 enum) Any of "xxx-
supported"
sides-default (type2 keyword) Any of "xxx-
supported"
number-up-default (integer(1:MAX)) Any of "xxx-
supported"
orientation-requested-default (type2 enum) Any of "xxx-
supported"
media-default (type3 keyword | name(MAX)) Any of "xxx-
supported"
printer-resolution-default (resolution) Any of "xxx-
supported"
print-quality-default (type2 enum) Any of "xxx-
supported"
job-priority-supported (integer(1:100)) From Get-
Printer-
Supported-Values
job-hold-until-supported (1setOf(type3 keyword From Get-
| name (MAX))) Printer-
Supported-Values
job-sheets-supported (1setOf(type3 keyword | From Get-
name(MAX))) Printer-
Supported-Values
multiple-document-handling-supported (1setOf From Get-
type2 keyword) Printer-
Supported-Values
copies-supported (rangeOfInteger(1:MAX)) From Get-
Printer-
Supported-Values
finishings-supported (1setOf type2 enum) From Get-
Printer-
Supported-Values
Printer Job Template Attributes Values allowed
for Set
page-ranges-supported (boolean) From Get-
Printer-
Supported-Values
sides-supported (1setOf type2 keyword) From Get-
Printer-
Supported-Values
number-up-supported (1setOf (integer(1:MAX) | From Get-
rangeOfInteger(1:MAX))) Printer-
Supported-Values
orientation-requested-supported (1setOf type2 From Get-
enum) Printer-
Supported-Values
media-supported (1setOf (type3 keyword | From Get-
name(MAX))) Printer-
Supported-Values
printer-resolution-supported (1setOf From Get-
resolution) Printer-
Supported-Values
print-quality-supported (1setOf type2 enum) From Get-
Printer-
Supported-Values
media-ready (type3 keyword | name(MAX)) From Get-
Printer-
Supported-ValuesTable 10 is all about the printer description attributes, and the xri stuff is giving main character energy 🦋
Table 10 - Values allowed for Printer Description Attributes in
the Set-Printer-Attributes Operation
Printer Description Attributes Values allowed for
Set
printer-uri-supported (1setOf uri) READ-ONLY
uri-authentication-supported (1setOf type2 READ-ONLY
keyword)
uri-security-supported (1setOf type2 READ-ONLY
keyword)
printer-xri-supported (1setOf collection)
member attributes:
xri-uri (uri) any uriScheme of
"xri-uri-scheme-
supported" from
Get-Printer-
Attributes
xri-authentication (type2 keyword) any keyword of
"xri-
authentication-
supported" from
Get-Printer-
Attributes
xri-security (type2 keyword) any keyword of
"xri-security-
supported" from
Get-Printer-
Attributes
xri-uri-scheme-supported (1setOf uriScheme) READ-ONLY
xri-authentication-supported (1setOf type2 READ-ONLY
keyword)
xri-security-supported (1setOf type2 READ-ONLY
keyword)
Printer Description Attributes Values allowed for
Set
printer-name (name(127)) Any name(127)
printer-location (text(127)) Any text(127)
printer-info (text(127)) Any text(127)
printer-more-info (uri) Any uri
printer-driver-installer (uri) Any uri
printer-make-and-model (text(127)) Any text(127)
printer-more-info-manufacturer (uri) Any uri
printer-state (type1 enum) READ-ONLY
printer-state-reasons (1setOf type2 READ-ONLY
keyword)
printer-state-message (text(MAX)) READ-ONLY
ipp-versions-supported (1setOf type2 From Get-Printer-
keyword) Supported-Values
operations-supported (1setOf type2 enum) From Get-Printer-
Supported-Values
multiple-document-jobs-supported (boolean) From Get-Printer-
Supported-Values
charset-configured (charset) Any of "xxx-
supported", use
"charset-supported"
charset-supported (1setOf charset) From Get-Printer-
Supported-Values
Printer Description Attributes Values allowed for
Set
natural-language-configured Any of "xxx-
(naturalLanguage) supported", use
"generated-natural-
language-supported"
generated-natural-language-supported From Get-Printer-
(1setOf naturalLanguage) Supported-Values
document-format-default (mimeMediaType) Any of "xxx-
supported"
document-format-supported (1setOf From Get-Printer-
mimeMediaType) Supported-Values
printer-is-accepting-jobs (boolean) READ-ONLY
queued-job-count (integer(0:MAX)) READ-ONLY
printer-message-from-operator (text(127)) Any text(127)
color-supported (boolean) From Get-Printer-
Supported-Values
reference-uri-schemes-supported (1setOf From Get-Printer-
uriScheme) Supported-Values
pdl-override-supported (type2 keyword) From Get-Printer-
Supported-Values
printer-up-time (integer(1:MAX)) READ-ONLY
printer-current-time (dateTime) Any dateTime **
multiple-operation-time-out any positive
(integer(1:MAX)) integer compression-supported (1setOf type3 From Get-Printer-
keyword) Supported-Values
job-k-octets-supported From Get-Printer-
(rangeOfInteger(0:MAX)) Supported-Values
Printer Description Attributes Values allowed for
Set
job-impressions-supported From-Get-Printer-
(rangeOfInteger(0:MAX)) Supported-Values
job-media-sheets-supported From Get-Printer-
(rangeOfInteger(0:MAX)) Supported-Values
pages-per-minute (integer(0:MAX)) READ-ONLY
pages-per-minute-color (integer(0:MAX)) READ-ONLY
printer-settable-attributes-supported From Get-Printer-
(1setOf type2 keyword) Supported-Values
job-settable-attributes-supported (1setOf From Get-Printer-
type2 keyword) Supported-Values
document-format-varying-attributes (1setOf READ-ONLY
type2 keyword)
printer-message-time (integer(MIN:MAX)) READ-ONLY
printer-message-date-time(dateTime) READ-ONLY** quick note: the "printer-current-time" (dateTime) attribute is settable so an admin can fix a wrong dateTime or time zone 🕰️✨
Appendix B: Attributes returned from Get-Printer-Supported-Values (Normative) 🎀
Okay so this appendix is normative, which means it totally counts 💅 It lists every attribute an implementation could possibly return in a Get-Printer-Supported-Values response. Basically, all the xxx-supported attributes that can also be sent in a Set-Printer-Attributes request. 🦋
READ-ONLY attributes MUST NOT be returned in a Get-Printer-Supported-Values response. The tables mark them as "READ-ONLY - MUST NOT be returned." so you can spot them instantly 👀
For the following attributes, the value allowed by the Set-Printer-Attributes operation MUST be a single integer value in the range returned by Get-Printer-Supported-Values. 🔢
Table 11 - Printer Job Template Attributes returned from
Get-Printer-Supported-Values
Printer Job Template Attributes Values Returned
job-priority-supported (integer(1:100)) rangeOfInteger(1:100)For the following attributes, the value allowed by the Set-Printer-Attributes operation MUST be a single rangeOfInteger value whose bounds do not exceed those of the range returned by Get-Printer-Supported-Values. 🌈
Table 12 - Printer Job Template Attributes returned from
Get-Printer-Supported-Values
Printer Job Template Attributes Values Returned
copies-supported (rangeOfInteger(1:MAX)) rangeOfInteger(1:MAX)This next table follows the same rules as the last one, but it's for Printer Description attributes 🍓
Table 13 - Printer Description Attributes returned from
Get-Printer-Supported-Values
Printer Description Attributes Values allowed for Set
job-k-octets-supported rangeOfInteger(0:MAX)
(rangeOfInteger(0:MAX))
job-impressions-supported
(rangeOfInteger(0:MAX)) rangeOfInteger(0:MAX)
job-media-sheets-supported rangeOfInteger(0:MAX)
(rangeOfInteger(0:MAX))For the following attributes, the value allowed by the Set-Printer-Attributes operation MUST be one or more integers and rangeOfInteger values. Those values have to describe the same integers as, or a subset of the integers described by, the integers and rangeOfInteger values returned by Get-Printer-Supported-Values. Think of it as "you can't ask for more than the printer said it has" 🫶
Table 14 - Printer Job Template Attributes returned from
Get-Printer-Supported-Values
Printer Job Template Attributes Values Returned
number-up-supported (1setOf (integer(1:MAX) 1setOf
| rangeOfInteger(1:MAX))) (integer(1:MAX) |
rangeOfInteger(1:MA
X))For the following attributes, the value allowed by the Set-Printer-Attributes operation MUST be one or more values, and each value has to match a value returned by Get-Printer-Supported-Values. A keyword, enum, boolean, charset, naturalLanguage, uriScheme, mimeMediaType or resolution value matches if it is equal. For Job Template attributes with the attribute syntax 'type3 keyword | name', any 'name' attribute syntax value matches the 'admin-define' out-of-band value, but only if the implementation lets the administrator set any name values for that attribute. 🧚
Table 15 - Printer Job Template Attributes returned from
Get-Printer-Supported-Values
Printer Job Template Attributes Values Returned
job-hold-until-supported (1setOf(type3 1setOf (type3
keyword | name (MAX))) keyword | 'admin-
define')
job-sheets-supported (1setOf(type3 keyword 1setOf (type3
| name(MAX))) keyword | 'admin-
define')
multiple-document-handling-supported 1setOf type2
(1setOf type2 keyword) keyword
finishings-supported (1setOf type2 enum) 1setOf type2 enum
page-ranges-supported (boolean) 1setOf boolean **
sides-supported (1setOf type2 keyword) 1setOf type2
keyword
orientation-requested-supported (1setOf 1setOf type2 enum
type2 enum)
Printer Job Template Attributes Values Returned
media-supported (1setOf (type3 keyword | 1setOf (type3
name(MAX))) keyword | 'admin-
define')
printer-resolution-supported (1setOf 1setOf resolution
resolution)
print-quality-supported (1setOf type2 enum) 1setOf type2 enum** note: Get-Printer-Supported-Values returns a 1setOf boolean so every possible value gets listed, while Get-Printer-Attributes only returns a single boolean value 🙈
The next table has the same criteria as the last one, but it's for Printer Description attributes 💖
Table 16 - Printer Description Attributes returned from
Get-Printer-Supported-Values
Printer Description Attributes Values allowed for
Set
printer-uri-supported (1setOf uri) READ-ONLY - MUST
NOT be returned
uri-authentication-supported (1setOf type2 READ-ONLY - MUST
keyword) NOT be returned
uri-security-supported (1setOf type2 READ-ONLY - MUST
keyword) NOT be returned
printer-xri-supported (1setOf collection) MUST NOT be
returned; see next
three attributes
returned with Get-
Printer-Attributes:
xri-uri-scheme-supported (1setOf uriScheme) READ-ONLY - MUST
NOT be returned
xri-authentication-supported (1setOf type2 READ-ONLY - MUST
keyword) NOT be returned
xri-security-supported (1setOf type2 READ-ONLY - MUST
keyword) NOT be returned
Printer Description Attributes Values allowed for
Set
ipp-versions-supported (1setOf type2 1setOf type2
keyword) keyword
operations-supported (1setOf type2 enum) 1setOf type2
keyword
multiple-document-jobs-supported (boolean) 1setOf boolean **
charset-supported (1setOf charset) 1setOf charset
generated-natural-language-supported 1setOf
(1setOf naturalLanguage) naturalLanguage
document-format-supported (1setOf 1setOf
mimeMediaType) mimeMediaType
color-supported (boolean) 1setOf boolean **
reference-uri-schemes-supported (1setOf 1setOf uriScheme
uriScheme)
pdl-override-supported (type2 keyword) 1setOf type2
keyword **
compression-supported (1setOf type3 1setOf type3
keyword) keyword
printer-settable-attributes-supported 1setOf type2
(1setOf type2 keyword) keyword
job-settable-attributes-supported (1setOf 1setOf type2
type2 keyword) keyword** note: Get-Printer-Supported-Values returns a 1setOf X so every possible value is indicated, while Get-Printer-Attributes returns only a single X value 🌸
Appendix C: Description of the Base IPP Documents (Informative) 📚✨
okay so bestie, this appendix is basically the reading list for the whole IPP family 🖨️💖 it's like the playlist that tells you which doc does what, and it's giving "everything has its place" energy 💅
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: Implementer's Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]The "Design Goals" doc 🎯
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it's lowkey iconic because it lists real-life scenarios to help figure out which features a printing protocol for the Internet needs 🌍. It identifies requirements for three types of users: end users, operators, and administrators 🫶. It calls out a subset of end user requirements that are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911, RFC2910] ✨.
The "Rationale" doc 🧠
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high-level view 🦋. It defines a roadmap for the various documents that form the suite of IPP specification documents, and it gives background and rationale for the IETF IPP working group's major decisions 💜. Main character energy for the "why" questions, no cap 👑.
The "Model and Semantics" doc 🧩
The "Internet Printing Protocol/1.1: Model and Semantics" document describes a simplified model with abstract objects, their attributes, and their operations 🌸. The model introduces a Printer and a Job 🖨️. The Job supports multiple documents per Job 📄. The model document also addresses how security, internationalization, and directory issues are addressed 🔐🌈.
The "Encoding and Transport" doc 🚚
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616] 🌐. It also defines the encoding rules for a new Internet MIME media type called "application/ipp" 🎀. This document also defines the rules for transporting over HTTP, a message body whose Content-Type is "application/ipp" 💌. This document defines the 'ipp' scheme for identifying IPP printers and jobs 🧚.
The "Implementer's Guide" doc 📖
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects 🛠️. It's intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations 🫧. For example, a typical order of processing requests is given, including error checking ✅. Motivation for some of the specification decisions is also included 💭.
The "LPD and IPP" doc 🔁
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations 🌉.
Authors' Addresses 💌
Carl Kugler IBM P.O. Box 1900 Boulder, CO 80301-9191
Phone: (303) 924-5060 EMail: kugler@us.ibm.com
Tom Hastings Xerox Corporation 737 Hawaii St. ESAE 231 El Segundo, CA 90245
Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com
Robert Herriot Consultant 706 Colorado Ave Palo Alto, CA 94303
Phone: 650-327-4466 Fax: 650-327-4466 EMail: bob@Herriot.com
Harry Lewis IBM 6300 Diagonal Hwy. Boulder, CO 80301-9191
Phone: (303) 924-5337 EMail: harryl@us.ibm.com IPP Web Page: http://www.pwg.org/ipp/ IPP Mailing List: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email:
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
endImplementers of this specification document are encouraged to join the IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values. In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the mailing list. 📬
Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🙏
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc3380 2002-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms