Internet Printing Protocol/1.1: Model and Semantics
RFC 8011
part of STD 92
| Document | Type |
RFC
- Internet Standard
(January 2017)
Errata
Status changed by status-change-change-ipp-to-internet-standard
Was
draft-sweet-rfc2911bis
(individual in art area)
|
|
|---|---|---|---|
| Authors | Michael Sweet , Ira McDonald | ||
| Last updated | 2021-06-23 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| IESG | Responsible AD | Alexey Melnikov | |
| Send notices to | (None) |
RFC 8011
Sweet & McDonald Standards Track [Page 119] RFC 8011 IPP/1.1: Model and Semantics January 2017 Note: The effect of this attribute on Jobs with multiple Documents is controlled by the "multiple-document-handling" Job attribute (Section 5.2.4). The relationship of this attribute and the other attributes that control Document processing is described in Appendix C.3. 5.2.9. number-up (integer(1:MAX)) This attribute specifies the number of Input Pages to impose upon a single Impression. For example, if the value is: o '1': the Printer MUST place one Input Page on a single Impression. o '2': the Printer MUST place two Input Pages on a single Impression. o '4': the Printer MUST place four Input Pages on a single Impression. In all cases, the Printer MAY add some sort of translation, scaling, or rotation of Input Pages when imposing them. Note: The effect of this attribute on Jobs with multiple Documents is controlled by the "multiple-document-handling" Job attribute (Section 5.2.4). The relationship of this attribute and the other attributes that control Document processing is described in Appendix C.3. 5.2.10. orientation-requested (type2 enum) This RECOMMENDED attribute indicates the desired orientation for printed Input Pages; it does not describe the orientation of the Client-supplied Input Pages. For some Document formats (such as 'application/postscript'), the desired orientation of the Input Pages is sometimes specified within the Document data. This information is generated by a Printer driver prior to the submission of the Print Job. Other Document formats such as 'text/plain' do not include the notion of desired orientation within the Document data. In the latter case, it is possible for the Printer to bind the desired orientation to the Document data after it has been submitted. Printers MAY only support "orientation-requested" for some Document formats (e.g., 'text/plain' or 'text/html') but not others (e.g., 'application/postscript'). This is no different than any other Job Template attribute, since Section 5.2, item 1, points out that a Printer can support or not support any Job Template attribute based on the Document format Sweet & McDonald Standards Track [Page 120] RFC 8011 IPP/1.1: Model and Semantics January 2017 supplied by the Client. However, a special mention is made here, since it is very likely that a Printer will support "orientation-requested" for only a subset of the supported Document formats. Standard enum values are listed in Table 11. Note: The effect of this attribute on Jobs with multiple Documents is controlled by the "multiple-document-handling" Job attribute (Section 5.2.4). The relationship of this attribute and the other attributes that control Document processing is described in Appendix C.3. Sweet & McDonald Standards Track [Page 121] RFC 8011 IPP/1.1: Model and Semantics January 2017 +-------+-----------------------------------------------------------+ | Value | Symbolic Name and Description | +-------+-----------------------------------------------------------+ | '3' | 'portrait': The content will be imaged across the short | | | edge of the medium. | +-------+-----------------------------------------------------------+ | '4' | 'landscape': The content will be imaged across the long | | | edge of the medium. Landscape is defined to be a | | | rotation of the Input Page to be imaged by +90 degrees | | | with respect to the medium (i.e., counterclockwise) from | | | the portrait orientation. Note: The +90 direction was | | | chosen because simple finishing on the long edge is the | | | same edge whether portrait or landscape. | +-------+-----------------------------------------------------------+ | '5' | 'reverse-landscape': The content will be imaged across | | | the long edge of the medium. Reverse-landscape is | | | defined to be a rotation of the Input Page to be imaged | | | by -90 degrees with respect to the medium (i.e., | | | clockwise) from the portrait orientation. Note: The | | | 'reverse-landscape' value was added because some | | | applications rotate landscape -90 degrees from portrait, | | | rather than +90 degrees. | +-------+-----------------------------------------------------------+ | '6' | 'reverse-portrait': The content will be imaged across the | | | short edge of the medium. Reverse-portrait is defined to | | | be a rotation of the Input Page to be imaged by 180 | | | degrees with respect to the medium from the portrait | | | orientation. Note: The 'reverse-portrait' value was | | | added for use with the "finishings" attribute in cases | | | where the opposite edge is desired for finishing a | | | portrait Document on simple finishing devices that have | | | only one finishing position. Thus, a 'text'/plain' | | | portrait Document can be stapled "on the right" by a | | | simple finishing device, as is common use with some | | | Middle Eastern languages such as Hebrew. | +-------+-----------------------------------------------------------+ Table 11: "orientation-requested" Enum Values Sweet & McDonald Standards Track [Page 122] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.2.11. media (type2 keyword | name(MAX)) This RECOMMENDED attribute identifies the medium that the Printer uses for all Impressions of the Job. The values for "media" historically have included medium names, medium sizes, input trays, and electronic forms so that one attribute specifies the media. However, the Client SHOULD only use the media attribute to specify medium sizes using PWG Media Standardized Names [PWG5101.1]. If a Printer supports a medium name as a value of this attribute, such a medium name implicitly selects an input tray that contains the specified medium. If a Printer supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input tray that contains the medium with the specified size. If a Printer supports an input tray as the value of this attribute, such an input tray implicitly selects the medium that is in that input tray at the time the Job prints. This case includes manual-feed input trays. If a Printer supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium name that in turn implicitly selects an input tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer MUST merge with the Document data as it prints each page. PWG Media Standardized Names [PWG5101.1] SHOULD be used. Legacy 'keyword' values are taken from ISO DPA [ISO10175], the Printer MIB [RFC3805], and ASME-Y14.1M [ASME-Y14.1M]. An Administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready", which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no Operator intervention required. The relationship of this attribute and the other attributes that control Document processing is described in Appendix C.3. Note: If supported by the Printer, Clients MAY use the alternative "media-col" attribute [PWG5100.3] [PWG5100.13] to specify medium requirements in greater detail. Sweet & McDonald Standards Track [Page 123] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.2.12. printer-resolution (resolution) This RECOMMENDED attribute identifies the output resolution that the Printer uses for the Job. Note: This attribute and the "print-quality" attribute (Section 5.2.13) are both used to specify the overall output quality of the Job. If a Client specifies conflicting "printer-resolution" and "print-quality" values, Printers SHOULD use the "print-quality" value. 5.2.13. print-quality (type2 enum) This RECOMMENDED attribute specifies the print quality that the Printer uses for the Job. The standard enum values are listed in Table 12. Note: This attribute and the "printer-resolution" attribute (Section 5.2.12) are both used to specify the overall output quality of the Job. If a Client specifies conflicting "printer-resolution" and "print-quality" values, Printers SHOULD use the "print-quality" value. +-------+---------------------------------------------------------+ | Value | Symbolic Name and Description | +-------+---------------------------------------------------------+ | '3' | 'draft': lowest quality available on the Printer | +-------+---------------------------------------------------------+ | '4' | 'normal': normal or intermediate quality on the Printer | +-------+---------------------------------------------------------+ | '5' | 'high': highest quality available on the Printer | +-------+---------------------------------------------------------+ Table 12: "print-quality" Enum Values 5.3. Job Description and Status Attributes The attributes in this section form the attribute group called "job-description". Tables 13 and 14 summarize these attributes. The third column of each table indicates whether the attribute is a REQUIRED attribute that MUST be supported by Printers. If it is not indicated as REQUIRED, then it is OPTIONAL. The maximum size in octets for 'text' and 'name' attributes is indicated in parentheses. Sweet & McDonald Standards Track [Page 124] RFC 8011 IPP/1.1: Model and Semantics January 2017 +------------------+----------------+-----------+ | Attribute | Syntax | REQUIRED? | +------------------+----------------+-----------+ | job-impressions | integer(0:MAX) | | +------------------+----------------+-----------+ | job-k-octets | integer(0:MAX) | | +------------------+----------------+-----------+ | job-media-sheets | integer(1:MAX) | | +------------------+----------------+-----------+ | job-name | name(MAX) | REQUIRED | +------------------+----------------+-----------+ Table 13: Job Description Attributes (READ-WRITE) +-----------------------------+-------------------------+-----------+ | Attribute | Syntax | REQUIRED? | +-----------------------------+-------------------------+-----------+ | attributes-charset | charset | REQUIRED | +-----------------------------+-------------------------+-----------+ | attributes-natural-language | naturalLanguage | REQUIRED | +-----------------------------+-------------------------+-----------+ | date-time-at-completed | dateTime|unknown|no- | | | | value | | +-----------------------------+-------------------------+-----------+ | date-time-at-creation | dateTime|unknown | | +-----------------------------+-------------------------+-----------+ | date-time-at-processing | dateTime|unknown|no- | | | | value | | +-----------------------------+-------------------------+-----------+ | job-detailed-status- | 1setOf text(MAX) | | | messages | | | +-----------------------------+-------------------------+-----------+ | job-document-access-errors | 1setOf text(MAX) | | +-----------------------------+-------------------------+-----------+ | job-id | integer(1:MAX) | REQUIRED | +-----------------------------+-------------------------+-----------+ | job-impressions-completed | integer(0:MAX) | | +-----------------------------+-------------------------+-----------+ | job-k-octets-processed | integer(0:MAX) | | +-----------------------------+-------------------------+-----------+ | job-media-sheets-completed | integer(0:MAX) | | +-----------------------------+-------------------------+-----------+ | job-message-from-operator | text(127) | | +-----------------------------+-------------------------+-----------+ | job-more-info | uri | | +-----------------------------+-------------------------+-----------+ | job-originating-user-name | name(MAX) | REQUIRED | Sweet & McDonald Standards Track [Page 125] RFC 8011 IPP/1.1: Model and Semantics January 2017 +-----------------------------+-------------------------+-----------+ | job-printer-up-time | integer(1:MAX) | REQUIRED | +-----------------------------+-------------------------+-----------+ | job-printer-uri | uri | REQUIRED | +-----------------------------+-------------------------+-----------+ | job-state | type1 enum | REQUIRED | +-----------------------------+-------------------------+-----------+ | job-state-message | text(MAX) | | +-----------------------------+-------------------------+-----------+ | job-state-reasons | 1setOf type2 keyword | REQUIRED | +-----------------------------+-------------------------+-----------+ | job-uri | uri | REQUIRED | +-----------------------------+-------------------------+-----------+ | number-of-documents | integer(0:MAX) | | +-----------------------------+-------------------------+-----------+ | number-of-intervening-jobs | integer(0:MAX) | | +-----------------------------+-------------------------+-----------+ | output-device-assigned | name(127) | | +-----------------------------+-------------------------+-----------+ | time-at-completed | integer(MIN:MAX) | REQUIRED | +-----------------------------+-------------------------+-----------+ | time-at-creation | integer(MIN:MAX) | REQUIRED | +-----------------------------+-------------------------+-----------+ | time-at-processing | integer(MIN:MAX) | REQUIRED | +-----------------------------+-------------------------+-----------+ Table 14: Job Status Attributes (READ-ONLY) 5.3.1. job-id (integer(1:MAX)) This REQUIRED attribute contains the ID of the Job. The Printer, on receipt of a new Job, generates an ID that identifies the new Job on that Printer. The Printer returns the value of the "job-id" attribute as part of the response to a Job Creation request. For a description of this attribute and its relationship to the "job-uri" and "job-printer-uri" attributes, see the discussion in Section 3.4 ("Object Identity"). 5.3.2. job-uri (uri) This REQUIRED attribute contains the URI for the Job. The Printer, on receipt of a new Job, generates a URI that identifies the new Job. The Printer returns the value of the "job-uri" attribute as part of the response to a Job Creation request. The precise format of a Job URI is implementation dependent [RFC3510] [RFC7472]. If the Printer supports more than one URI and there is some relationship between the newly formed Job URI and the Printer's URI, the Printer uses the Sweet & McDonald Standards Track [Page 126] RFC 8011 IPP/1.1: Model and Semantics January 2017 Printer URI supplied by the Client in the Job Creation request. For example, if the Job Creation request comes in over a secure channel, the new Job URI MUST use the same secure channel. This can be guaranteed because the Printer is responsible for generating the Job URI and the Printer is aware of its security configuration and policy as well as the Printer URI used in the Job Creation request. For a description of this attribute and its relationship to the "job-id" and "job-printer-uri" attributes, see the discussion in Section 3.4 ("Object Identity"). 5.3.3. job-printer-uri (uri) This REQUIRED attribute identifies the Printer that created this Job. When a Printer creates a Job, it populates this attribute with the Printer URI that was used in the Job Creation request. This attribute permits a Client to identify the Printer that created this Job when only the Job's URI is available to the Client. The Client queries the creating Printer to determine which languages, charsets, and operations are supported for this Job. For a description of this attribute and its relationship to the "job-uri" and "job-id" attributes, see the discussion in Section 3.4 ("Object Identity"). 5.3.4. job-more-info (uri) Similar to "printer-more-info", this attribute contains the URI referencing some resource with more information about this Job, perhaps an HTML page containing status information about the Job. 5.3.5. job-name (name(MAX)) This REQUIRED attribute is the name of the Job. It is a name that is more user friendly than the "job-uri" or "job-id" attribute values. It does not need to be unique between Jobs. The Job's "job-name" attribute is set to the value supplied by the Client in the "job-name" operation attribute in the Job Creation request (see Section 4.2.1.1). If, however, the "job-name" operation attribute is not supplied by the Client in the Job Creation request, the Printer, on creation of the Job, MUST generate a name. The Printer SHOULD generate the value of the Job's "job-name" attribute from the first of the following sources that produces a value: (1) the "document-name" operation attribute of the first (or only) Document, (2) the "document-URI" attribute of the first (or only) Document, or (3) any other piece of Job-specific and/or Document data. Sweet & McDonald Standards Track [Page 127] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.3.6. job-originating-user-name (name(MAX)) This REQUIRED attribute contains the name of the End User that submitted the Print Job. The Printer sets this attribute to the most authenticated printable name that it can obtain from the authentication service over which the IPP operation was received. Only if such a name is not available does the Printer use the value supplied by the Client in the "requesting-user-name" operation attribute of the Job Creation request (see Sections 5.4.2, 5.4.3, and 9). Note: The Printer needs to keep an internal originating user ID of some form, typically as a credential of a principal, with the Job. Since such an internal attribute is implementation dependent and not of interest to Clients, it is not specified as a Job attribute. This originating user ID is used for authorization checks (if any) on all subsequent operations. 5.3.7. job-state (type1 enum) This REQUIRED attribute identifies the current state of the Job. Even though IPP defines seven values for Job states (plus the out-of-band 'unknown' value -- see Section 5.1), implementations only need to support those states that are appropriate for the particular implementation. In other words, a Printer supports only those Job states implemented by the Output Device and available to the Printer implementation. Standard enum values are listed in Table 15. The final value for this attribute MUST be one of the following -- 'completed', 'canceled', or 'aborted' -- before the Printer removes the Job altogether. The length of time that Jobs remain in the 'canceled', 'aborted', and 'completed' states depends on implementation. See Section 5.3.7.2. Sweet & McDonald Standards Track [Page 128] RFC 8011 IPP/1.1: Model and Semantics January 2017 Figure 3 shows the normal Job state transitions. Normally, a Job progresses from left to right. Other state transitions are unlikely but are not forbidden. Not shown are the transitions to the 'canceled' state from the 'pending', 'pending-held', and 'processing-stopped' states. +----> canceled / +----> pending -------> processing ---------+------> completed | ^ ^ \ --->+ | | +----> aborted | v v / +----> pending-held processing-stopped ---+ Figure 3: IPP Job Life Cycle Jobs reach one of the three terminal states -- 'completed', 'canceled', or 'aborted' -- after the Jobs have completed all activity, including stacking output media, and all Job Status attributes have reached their final values for the Job. Sweet & McDonald Standards Track [Page 129] RFC 8011 IPP/1.1: Model and Semantics January 2017 +--------+----------------------------------------------------------+ | Values | Symbolic Name and Description | +--------+----------------------------------------------------------+ | '3' | 'pending': The Job is a candidate to start processing | | | but is not yet processing. | +--------+----------------------------------------------------------+ | '4' | 'pending-held': The Job is not a candidate for | | | processing for any number of reasons but will return to | | | the 'pending' state as soon as the reasons are no longer | | | present. The Job's "job-state-reasons" attribute MUST | | | indicate why the Job is no longer a candidate for | | | processing. | +--------+----------------------------------------------------------+ | '5' | 'processing': One or more of the following: (1) the Job | | | is using, or is attempting to use, one or more purely | | | software processes that are analyzing, creating, or | | | interpreting a PDL, etc.; (2) the Job is using, or is | | | attempting to use, one or more hardware devices that are | | | interpreting a PDL; making marks on a medium; and/or | | | performing finishing, such as stapling, etc.; (3) the | | | Printer has made the Job ready for printing, but the | | | Output Device is not yet printing it, either because the | | | Job hasn't reached the Output Device or because the Job | | | is queued in the Output Device or some other spooler, | | | waiting for the Output Device to print it. When the Job | | | is in the 'processing' state, the entire Job state | | | includes the detailed status represented in the | | | Printer's "printer-state", "printer-state-reasons", and | | | "printer-state-message" attributes. Implementations MAY | | | include additional values in the Job's "job-state- | | | reasons" attribute to indicate the progress of the Job, | | | such as adding the 'job-printing' value to indicate when | | | the Output Device is actually making marks on paper | | | and/or the 'processing-to-stop-point' value to indicate | | | that the Printer is in the process of canceling or | | | aborting the Job. | Sweet & McDonald Standards Track [Page 130] RFC 8011 IPP/1.1: Model and Semantics January 2017 +--------+----------------------------------------------------------+ | '6' | 'processing-stopped': The Job has stopped while | | | processing for any number of reasons and will return to | | | the 'processing' state as soon as the reasons are no | | | longer present. The Job's "job-state-reasons" attribute | | | MAY indicate why the Job has stopped processing. For | | | example, if the Output Device is stopped, the 'printer- | | | stopped' value MAY be included in the Job's "job-state- | | | reasons" attribute. Note: When an Output Device is | | | stopped, the device usually indicates its condition in | | | human-readable form locally at the device. A Client can | | | obtain more complete device status remotely by querying | | | the Printer's "printer-state", "printer-state-reasons", | | | and "printer-state-message" attributes. | +--------+----------------------------------------------------------+ | '7' | 'canceled': The Job has been canceled by a Cancel-Job | | | operation, and the Printer has completed canceling the | | | Job. All Job Status attributes have reached their final | | | values for the Job. While the Printer is canceling the | | | Job, the Job remains in its current state, but the Job's | | | "job-state-reasons" attribute SHOULD contain the | | | 'processing-to-stop-point' value and one of the | | | 'canceled-by-user', 'canceled-by-operator', or | | | 'canceled-at-device' values. When the Job moves to the | | | 'canceled' state, the 'processing-to-stop-point' value, | | | if present, MUST be removed, but 'canceled-by-xxx', if | | | present, MUST remain. | +--------+----------------------------------------------------------+ | '8' | 'aborted': The Job has been aborted by the system, | | | usually while the Job was in the 'processing' or | | | 'processing-stopped' state, and the Printer has | | | completed aborting the Job; all Job Status attributes | | | have reached their final values for the Job. While the | | | Printer is aborting the Job, the Job remains in its | | | current state, but the Job's "job-state-reasons" | | | attribute SHOULD contain the 'processing-to-stop-point' | | | and 'aborted-by-system' values. When the Job moves to | | | the 'aborted' state, the 'processing-to-stop-point' | | | value, if present, MUST be removed, but the 'aborted-by- | | | system' value, if present, MUST remain. | Sweet & McDonald Standards Track [Page 131] RFC 8011 IPP/1.1: Model and Semantics January 2017 +--------+----------------------------------------------------------+ | '9' | 'completed': The Job has completed successfully or with | | | warnings or errors after processing, all of the Job | | | Media Sheets have been successfully stacked in the | | | appropriate output bin(s), and all Job Status attributes | | | have reached their final values for the Job. The Job's | | | "job-state-reasons" attribute SHOULD contain one of the | | | 'completed-successfully', 'completed-with-warnings', or | | | 'completed-with-errors' values. | +--------+----------------------------------------------------------+ Table 15: "job-state" Enum Values 5.3.7.1. Forwarding Servers As with all other IPP attributes, if the implementation cannot determine the correct value for this attribute, it SHOULD respond with the out-of-band 'unknown' value (see Section 5.1) rather than try to guess at some possibly incorrect value and confuse the End User about the state of the Job. For example, if the implementation is just a gateway into some printing system from which it can normally get status, but temporarily is unable, then the implementation should return the 'unknown' value. However, if the implementation is a gateway to a printing system that never provides detailed status about the Print Job, the implementation MAY set the IPP Job's state to 'completed', provided that it also sets the 'queued-in-device' value in the Job's "job-state-reasons" attribute (see Section 5.3.8). 5.3.7.2. Partitioning of Job States This section describes the partitioning of the seven Job states into phases: Job Not Completed, Job Retention, Job History, and Job Removal. This section also explains the 'job-restartable' value of the "job-state-reasons" Job Status attribute for use with the Restart-Job and Resubmit-Job [PWG5100.11] operations. Job Not Completed: When a Job is in the 'pending', 'pending-held', 'processing', or 'processing-stopped' state, the Job is not completed. Job Retention: When a Job enters one of the three terminal Job states -- 'completed', 'canceled', or 'aborted' -- the IPP Printer MAY "retain" the Job in a restartable condition for an implementation- defined time period. This time period MAY be zero seconds and MAY depend on the terminal Job state. This phase is called "Job Retention". While in the Job Retention phase, the Job's Document data is retained and a Client can restart the Job using the Sweet & McDonald Standards Track [Page 132] RFC 8011 IPP/1.1: Model and Semantics January 2017 Restart-Job operation. If the Printer supports the Restart-Job or Resubmit-Job operation, then it SHOULD indicate that the Job is restartable by adding the 'job-restartable' value to the Job's "job-state-reasons" attribute (see Section 5.3.8) during the Job Retention phase. Job History: After the Job Retention phase expires for a Job, the Printer deletes the Document data for the Job and the Job becomes part of the Job History. The Printer MAY also delete any number of the Job attributes. Since the Job is no longer restartable, the Printer MUST remove the 'job-restartable' value from the Job's "job-state-reasons" attribute, if present. Printers SHOULD keep the Job in the Job History phase for at least 60 seconds to allow Clients to discover the final disposition of the Job. Job Removal: After the Job has remained in the Job History for an implementation-defined time, such as when the number of Jobs exceeds a fixed number or after a fixed time period (which MAY be zero seconds), the IPP Printer removes the Job from the system. Using the Get-Jobs operation and supplying the 'not-completed' value for the "which-jobs" operation attribute, a Client is requesting Jobs in the Job Not Completed phase. Using the Get-Jobs operation and supplying the 'completed' value for the "which-jobs" operation attribute, a Client is requesting Jobs in the Job Retention and Job History phases. Using the Get-Job-Attributes operation, a Client is requesting a Job in any phase except Job Removal. After Job Removal, the Get-Job-Attributes and Get-Jobs operations no longer are capable of returning any information about a Job. 5.3.8. job-state-reasons (1setOf type2 keyword) This REQUIRED attribute provides additional information about the Job's current state, i.e., information that augments the value of the Job's "job-state" attribute. These values MAY be used with any Job state or states for which the reason makes sense. Some of these value definitions indicate conformance requirements; the rest are OPTIONAL. Furthermore, when implemented, the Printer MUST return these values when the reason applies and MUST NOT return them when the reason no longer applies, whether the value of the Job's "job-state" attribute changed or not. When the Job does not have any reasons for being in its current state, the value of the Job's "job-state-reasons" attribute MUST be 'none'. Sweet & McDonald Standards Track [Page 133] RFC 8011 IPP/1.1: Model and Semantics January 2017 Note: While values cannot be added to the "job-state" attribute without impacting deployed Clients that take actions upon receiving "job-state" values, it is the intent that additional "job-state-reasons" values can be defined and registered without impacting such deployed Clients. In other words, the "job-state-reasons" attribute is intended to be extensible. The following standard 'keyword' values are defined. For ease of understanding, the values are presented in the order in which the reasons are likely to occur (if implemented): o 'none': There are no reasons for the Job's current state. This state reason is semantically equivalent to "job-state-reasons" without any value and MUST be used when there is no other value, since the '1setOf' attribute syntax requires at least one value. o 'job-incoming': Either (1) the Printer has accepted the Create-Job operation and is expecting additional Send-Document and/or Send-URI operations or (2) the Printer is retrieving/accepting Document data as a result of a Print-Job, Print-URI, Send-Document, or Send-URI operation. o 'job-data-insufficient': The Create-Job operation has been accepted by the Printer, but the Printer is expecting additional Document data before it can move the Job into the 'processing' state. If a Printer starts processing before it has received all data, the Printer removes the 'job-data-insufficient' reason, but the 'job-incoming' reason remains. If a Printer starts processing after it has received all data, the Printer removes the 'job-data-insufficient' reason and the 'job-incoming' reason at the same time. o 'document-access-error': After accepting a Print-URI or Send-URI request, the Printer could not access one or more Documents passed by reference. This reason is intended to cover any file access problem, including 'file does not exist' and 'access denied' because of an access control problem. The Printer MAY also indicate the Document access error using the "job-document-access-errors" Job Status attribute (see Section 5.3.11). The Printer can (1) abort the Job and move the Job to the 'aborted' Job state or (2) print all Documents that are accessible and move the Job to the 'completed' Job state with the 'completed-with-errors' value in the Job's "job-state-reasons" attribute. This value SHOULD be supported if the Print-URI or Send-URI operations are supported. Sweet & McDonald Standards Track [Page 134] RFC 8011 IPP/1.1: Model and Semantics January 2017 o 'submission-interrupted': The Job was not completely submitted for some unforeseen reason, such as (1) the Printer has crashed before the Job was closed by the Client, (2) the Printer or the Document transfer method has crashed in some non-recoverable way before the Document data was entirely transferred to the Printer, or (3) the Client crashed or failed to close the Job before the time-out period. See Section 5.4.31. o 'job-outgoing': The Printer is transmitting the Job to the Output Device. o 'job-hold-until-specified': The value of the Job's "job-hold-until" attribute was specified with a time period that is still in the future. The Job MUST NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the Job. This value SHOULD be supported if the "job-hold-until" Job Template attribute is supported. o 'resources-are-not-ready': At least one of the resources needed by the Job, such as media, fonts, resource objects, etc., is not ready on any of the physical Output Devices for which the Job is a candidate. This condition MAY be detected when the Job is accepted, or subsequently while the Job is pending or processing, depending on implementation. The Job can remain in its current state or be moved to the 'pending-held' state, depending on implementation and/or Job scheduling policy. o 'printer-stopped-partly': The value of the Printer's "printer-state-reasons" attribute contains the value 'stopped-partly'. o 'printer-stopped': The value of the Printer's "printer-state" attribute is 'stopped'. o 'job-interpreting': The Job is in the 'processing' state, but, more specifically, the Printer is interpreting the Document data. o 'job-queued': The Job is in the 'processing' state, but, more specifically, the Printer has queued the Document data. o 'job-transforming': The Job is in the 'processing' state, but, more specifically, the Printer is interpreting Document data and producing another electronic representation. o 'job-queued-for-marker': The Job is in any of the 'pending-held', 'pending', or 'processing' states, but, more specifically, the Printer has completed enough processing of the Document to be able to start marking, and the Job is waiting for the marker. Systems Sweet & McDonald Standards Track [Page 135] RFC 8011 IPP/1.1: Model and Semantics January 2017 that require human intervention to release Jobs using the Release-Job operation put the Job into the 'pending-held' Job state. Systems that automatically select a Job to use the marker put the Job into the 'pending' Job state or keep the Job in the 'processing' Job state while waiting for the marker, depending on implementation. All implementations put the Job into the 'processing' state when marking does begin. o 'job-printing': The Output Device is marking media. This value is useful for Printers that spend a great deal of time processing (1) when no marking is happening and they want to show that marking is now happening or (2) when the Job is in the process of being canceled or aborted while the Job remains in the 'processing' state, but the marking has not yet stopped so that Impression or sheet counts are still increasing for the Job. o 'job-canceled-by-user': The Job was canceled by the owner of the Job using the Cancel-Job request, i.e., by a user whose authenticated identity is the same as the value of the originating user that created the Job, or by some other authorized End User, such as a member of the Job owner's security group. This value SHOULD be supported. o 'job-canceled-by-operator': The Job was canceled by the Operator using the Cancel-Job request, i.e., by a user who has been authenticated as having Operator privileges (whether local or remote). If the security policy is to allow anyone to cancel anyone's Job, then this value can be used when the Job is canceled by other than the owner of the Job. For such a security policy, in effect, everyone is an Operator as far as canceling Jobs with IPP is concerned. This value SHOULD be supported if the implementation permits canceling by other than the owner of the Job. o 'job-canceled-at-device': The Job was canceled by an unidentified local user, i.e., a user at a console at the device. This value SHOULD be supported if the implementation supports canceling Jobs at the console. o 'aborted-by-system': The Job (1) is in the process of being aborted, (2) has been aborted by the system and placed in the 'aborted' state, or (3) has been aborted by the system and placed in the 'pending-held' state, so that a user or Operator can manually try the Job again. This value SHOULD be supported. Sweet & McDonald Standards Track [Page 136] RFC 8011 IPP/1.1: Model and Semantics January 2017 o 'unsupported-compression': The Job was aborted by the system because the Printer determined, while attempting to decompress the Document data, that the compression algorithm is actually not among those supported by the Printer. This value MUST be supported, since "compression" is a REQUIRED operation attribute. o 'compression-error': The Job was aborted by the system because the Printer encountered an error in the Document data while decompressing it. If the Printer posts this reason, the Document data has already passed any tests that would have led to the 'unsupported-compression' "job-state-reasons" value. o 'unsupported-document-format': The Job was aborted by the system because the Document data's "document-format" attribute is not among those supported by the Printer. If the Client specifies "document-format" as 'application/octet-stream', the Printer MAY abort the Job and post this reason even though the "document-format" value is among the values of the Printer's "document-format-supported" Printer attribute but not among the auto-sensed Document formats. This value MUST be supported, since "document-format" is a REQUIRED operation attribute. o 'document-format-error': The Job was aborted by the system because the Printer encountered an error in the Document data while processing it. If the Printer posts this reason, the Document data has already passed any tests that would have led to the 'unsupported-document-format' "job-state-reasons" value. o 'processing-to-stop-point': The requester has issued a Cancel-Job operation or the Printer has aborted the Job, but the Printer is still performing some actions on the Job until a specified stop point occurs or Job termination/cleanup is completed. If the implementation requires some measurable time to cancel the Job in the 'processing' or 'processing-stopped' Job state, the Printer MUST use this value to indicate that the Printer is still performing some actions on the Job while the Job remains in the 'processing' or 'processing-stopped' state. Once at the stop point, the Printer moves the Job from the 'processing' state to the 'canceled' or 'aborted' Job state. o 'service-off-line': The Printer is offline and accepting no Jobs. All 'pending' Jobs are put into the 'pending-held' state. This situation could be true if the service's or Document transform's input is impaired or broken. o 'job-completed-successfully': The Job completed successfully. This value SHOULD be supported. Sweet & McDonald Standards Track [Page 137] RFC 8011 IPP/1.1: Model and Semantics January 2017 o 'job-completed-with-warnings': The Job completed with warnings. This value SHOULD be supported if the implementation detects warnings. o 'job-completed-with-errors': The Job completed with errors (and possibly warnings too). This value SHOULD be supported if the implementation detects errors. o 'job-restartable': This Job is retained (see Section 5.3.7.2) and is currently able to be restarted using the Restart-Job (see Section 4.3.7) or Resubmit-Job [PWG5100.11] operation. If 'job-restartable' is a value of the Job's "job-state-reasons" attribute, then the Printer MUST accept a Restart-Job operation for that Job. This value SHOULD be supported if the Restart-Job operation is supported. o 'queued-in-device': The Job has been forwarded to a device or print system that is unable to send back status. The Printer sets the Job's "job-state" attribute to 'completed' and adds the 'queued-in-device' value to the Job's "job-state-reasons" attribute to indicate that the Printer has no additional information about the Job and never will have any better information. See Section 5.3.7.1. 5.3.9. job-state-message (text(MAX)) This RECOMMENDED attribute specifies information about the "job-state" and "job-state-reasons" attributes in human-readable text. If the Printer supports this attribute, the Printer MUST be able to generate this message in any of the natural languages identified by the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 4.1.4.1). The value SHOULD NOT contain additional information not contained in the values of the "job-state" and "job-state-reasons" attributes, such as interpreter error information. Otherwise, application programs might attempt to parse the (localized) text. For such additional information, such as interpreter errors for application program consumption or specific Document access errors, new attributes with 'keyword' values need to be developed and registered. Sweet & McDonald Standards Track [Page 138] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.3.10. job-detailed-status-messages (1setOf text(MAX)) This attribute specifies additional detailed and technical information about the Job. The Printer SHOULD localize the message, unless such localization would obscure the technical meaning of the message. Clients MUST NOT attempt to parse the value of this attribute. See "job-document-access-errors" (Section 5.3.11) for additional errors that a program can process. 5.3.11. job-document-access-errors (1setOf text(MAX)) This attribute provides additional information about each Document access error for this Job encountered by the Printer after it returned a response to the Print-URI or Send-URI operation and subsequently attempted to access document(s) supplied in the Print-URI or Send-URI operation. For errors in the protocol that is identified by the URI scheme in the "document-uri" operation attribute, such as 'http:' or 'ftp:', the error code is returned in parentheses, followed by the URI. For example: (404) http://www.example.com/filename.pdf Most Internet protocols use decimal error codes (unlike IPP), so the ASCII error code representation is in decimal. 5.3.12. number-of-documents (integer(0:MAX)) This attribute indicates the number of Documents in the Job, i.e., the number of Send-Document, Send-URI, Print-Job, or Print-URI operations that the Printer has accepted for this Job, regardless of whether the Document data has reached the Printer. Implementations supporting the RECOMMENDED Create-Job/Send-Document/ Send-URI operations SHOULD support this attribute so that Clients can query the number of Documents in each Job. 5.3.13. output-device-assigned (name(127)) This attribute identifies the Output Device to which the Printer has assigned this Job. If an Output Device implements an embedded Printer, the Printer SHOULD set this attribute. If a print server implements a Printer, the value MAY be empty (zero-length string) or not returned until the Printer assigns an Output Device to the Job. This attribute is particularly useful when a single Printer supports multiple devices (so-called "fan-out" -- see Section 3.1). Sweet & McDonald Standards Track [Page 139] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.3.14. Event Time Job Status Attributes This section defines the Job Status attributes that indicate the time at which certain events occur for a Job. If the Job event has not yet occurred, then the Printer MUST return the 'no-value' out-of-band value (see the beginning of Section 5.1). The "time-at-xxx (integer)" attributes represent time as an 'integer' representing the number of seconds since the device was powered up (informally called "time ticks"). The "date-time-at-xxx (dateTime)" attributes represent time as 'dateTime' representing date and time (including an offset from UTC). In order to populate these attributes, the Printer copies the value(s) of the following Printer Status attributes at the time the event occurs: 1. the value in the Printer's "printer-up-time" attribute for the "time-at-xxx (integer)" attributes. 2. the value in the Printer's "printer-current-time" attribute for the "date-time-at-xxx (dateTime)" attributes. If the Printer resets its "printer-up-time" attribute to 1 on power-up (see Section 5.4.29) and has persistent Jobs, then it MUST change all of those Jobs' "time-at-xxx (integer)" (time tick) Job attributes whose events have occurred either to: 1. 0 to indicate that the event happened before the most recent power-up, or 2. the negative of the number of seconds before the most recent power-up that the event took place, if the Printer knows the exact number of seconds. If a Client queries a "time-at-xxx (integer)" time tick Job attribute and finds the value to be 0 or negative, the Client MUST assume that the event occurred in some life other than the Printer's current life. Note: A Printer does not change the values of any "date-time-at-xxx (dateTime)" Job attributes on power-up. 5.3.14.1. time-at-creation (integer(MIN:MAX)) This REQUIRED attribute indicates the time at which the Job was created. Sweet & McDonald Standards Track [Page 140] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.3.14.2. time-at-processing (integer(MIN:MAX)) This REQUIRED attribute indicates the time at which the Job first began processing after the Job Creation request or the most recent Restart-Job operation. The out-of-band 'no-value' value is returned if the Job has not yet been in the 'processing' state (see the beginning of Section 5.1). 5.3.14.3. time-at-completed (integer(MIN:MAX)) This REQUIRED attribute indicates the time at which the Job entered a Terminating State ('completed', 'canceled', or 'aborted'). The out-of-band 'no-value' value is returned if the Job has not yet completed, been canceled, or aborted (see the beginning of Section 5.1). 5.3.14.4. job-printer-up-time (integer(1:MAX)) This REQUIRED Job Status attribute indicates the amount of time (in seconds) that the Printer implementation has been up and running. This attribute is an alias for the "printer-up-time" Printer Status attribute (see Section 5.4.29). A Client MAY request this attribute in a Get-Job-Attributes or Get-Jobs request and use the value returned in combination with other requested Event Time Job Status attributes in order to display time attributes to a user. The difference between this attribute and the 'integer' value of a "time-at-xxx" attribute is the number of seconds ago that the "time-at-xxx" event occurred. A Client can compute the wall-clock time at which the "time-at-xxx" event occurred by subtracting this difference from the Client's wall-clock time. 5.3.14.5. date-time-at-creation (dateTime|unknown) This RECOMMENDED attribute indicates the date and time at which the Job was created. 5.3.14.6. date-time-at-processing (dateTime|unknown|no-value) This RECOMMENDED attribute indicates the date and time at which the Job first began processing after the Job Creation request or the most recent Restart-Job operation. 5.3.14.7. date-time-at-completed (dateTime|unknown|no-value) This RECOMMENDED attribute indicates the date and time at which the Job entered a Terminating State ('completed', 'canceled', or 'aborted'). Sweet & McDonald Standards Track [Page 141] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.3.15. number-of-intervening-jobs (integer(0:MAX)) This attribute indicates the number of Jobs that are "ahead" of this Job in the relative chronological order of expected time to complete (i.e., the current scheduled order). For efficiency, it is only necessary to calculate this value when an operation is performed that requests this attribute. 5.3.16. job-message-from-operator (text(127)) This attribute provides a message from an Operator, Administrator, or "intelligent" process to indicate to the End User the reasons for modification or other management action taken on a Job. 5.3.17. Job Size Attributes This subsection defines Job attributes that describe the size of the Job. These attributes are not intended to be counters; they are intended to be useful routing and scheduling information if known. For these attributes, the Printer can try to compute the value if it is not supplied in the Job Creation request. Even if the Client does supply a value for these three attributes in the Job Creation request, the Printer MAY choose to change the value if the Printer is able to compute a value that is more accurate than the Client-supplied value. The Printer can determine the correct value for these attributes either right at Job submission time or at any later point in time. 5.3.17.1. job-k-octets (integer(0:MAX)) This attribute specifies the total size of the Document(s) in K octets, i.e., in units of 1024 octets requested to be processed in the Job. The value MUST be rounded up, so that a Job between 1 and 1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2, etc. This value MUST NOT include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the Job or Document data and independent of whether the output is collated or not. Thus, the value is independent of the implementation and indicates the size of the Document(s) measured in K octets independent of the number of copies. Sweet & McDonald Standards Track [Page 142] RFC 8011 IPP/1.1: Model and Semantics January 2017 This value also MUST NOT include the multiplicative factor due to a copies instruction embedded in the Document data. If the Document data actually includes replications of the Document data, this value will include such replication. In other words, this value is always the size of the source Document data, rather than a measure of the hardcopy output to be produced. 5.3.17.2. job-impressions (integer(0:MAX)) This RECOMMENDED attribute specifies the total size in number of Impressions of the Document(s) being submitted (see the definition of "Impression" in Section 2.3.4). As with "job-k-octets", this value MUST NOT include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the Job or Document data and independent of whether the output is collated or not. Thus, the value is independent of the implementation and reflects the size of the Document(s) measured in Impressions independent of the number of copies. As with "job-k-octets", this value also MUST NOT include the multiplicative factor due to a copies instruction embedded in the Document data. If the Document data actually includes replications of the Document data, this value will include such replication. In other words, this value is always the number of Impressions in the source Document data, rather than a measure of the number of Impressions to be produced by the Job. 5.3.17.3. job-media-sheets (integer(1:MAX)) This RECOMMENDED attribute specifies the total number of Media Sheets to be produced for this Job. Unlike the "job-k-octets" and the "job-impressions" attributes, this value MUST include the multiplicative factors contributed by the number of copies specified by the "copies" attribute and a 'number of copies' instruction embedded in the Document data, if any. This difference allows the Administrator to control the lower and upper bounds of both (1) the size of the Document(s) with "job-k-octets-supported" and "job-impressions-supported" and (2) the size of the Job with "job-media-sheets-supported". Sweet & McDonald Standards Track [Page 143] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.3.18. Job Progress Attributes This subsection defines Job attributes that describe the progress of the Job. These attributes are intended to be counters. That is, the values for a Job that has not started processing MUST be 0. When the Job's "job-state" is 'processing' or 'processing-stopped', this value is intended to contain the amount of the Job that has been processed to the time at which the attributes are requested. When the Job enters the 'completed', 'canceled', or 'aborted' states, these values are the final values for the Job. 5.3.18.1. job-k-octets-processed (integer(0:MAX)) This attribute specifies the total number of octets processed in K octets, i.e., in units of 1024 octets so far. The value MUST be rounded up, so that a Job between 1 and 1024 octets inclusive MUST be indicated as being 1, 1025 to 2048 inclusive MUST be 2, etc. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value MUST be equal to the value of the "job-k-octets" attribute. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value MUST be a multiple of the value of the "job-k-octets" attribute. 5.3.18.2. job-impressions-completed (integer(0:MAX)) This RECOMMENDED attribute specifies the number of Impressions completed for the Job so far. For printing devices, the Impressions completed includes interpreting, marking, and stacking the output. 5.3.18.3. job-media-sheets-completed (integer(0:MAX)) This RECOMMENDED Job attribute specifies the number of Media Sheets that have been marked and stacked for the entire Job so far, whether those sheets have been processed on one side or on both. 5.3.19. attributes-charset (charset) This REQUIRED attribute is populated using the value in the Client-supplied "attributes-charset" attribute in the Job Creation request. It identifies the charset (coded character set and encoding method) used by any Job attributes with attribute syntaxes 'text' and 'name' that were supplied by the Client in the Job Creation request. See Section 4.1.4 for a complete description of the "attributes-charset" operation attribute. Sweet & McDonald Standards Track [Page 144] RFC 8011 IPP/1.1: Model and Semantics January 2017 This attribute does not indicate the charset in which the 'text' and 'name' values are stored internally in the Job. The internal charset is implementation defined. The Printer MUST convert from whatever the internal charset is to that being requested in an operation as specified in Section 4.1.4. 5.3.20. attributes-natural-language (naturalLanguage) This REQUIRED attribute is populated using the value in the Client-supplied "attributes-natural-language" attribute in the Job Creation request. It identifies the natural language used for any Job attributes with attribute syntaxes 'text' and 'name' that were supplied by the Client in the Job Creation request. See Section 4.1.4 for a complete description of the "attributes-natural-language" operation attribute. See Sections 5.1.2.2 and 5.1.3.2 for how a Natural Language Override can be supplied explicitly for each 'text' and 'name' attribute value that differs from the value identified by the "attributes-natural-language" attribute. 5.4. Printer Description and Status Attributes These attributes form the attribute group called "printer-description". Tables 16 and 17 summarize these attributes, their syntax, and whether they are REQUIRED for a Printer to support. If they are not indicated as REQUIRED, they are OPTIONAL. The maximum size in octets for 'text' and 'name' attributes is indicated in parentheses. Note: How these attributes are set by an Administrator is outside the scope of this document. +-----------------------------+-----------------------+-------------+ | Attribute | Syntax | REQUIRED? | +-----------------------------+-----------------------+-------------+ | charset-configured | charset | REQUIRED | +-----------------------------+-----------------------+-------------+ | charset-supported | 1setOf charset | REQUIRED | +-----------------------------+-----------------------+-------------+ | color-supported | boolean | RECOMMENDED | +-----------------------------+-----------------------+-------------+ | compression-supported | 1setOf type2 keyword | REQUIRED | +-----------------------------+-----------------------+-------------+ | document-format-default | mimeMediaType | REQUIRED | +-----------------------------+-----------------------+-------------+ | document-format-supported | 1setOf mimeMediaType | REQUIRED | Sweet & McDonald Standards Track [Page 145] RFC 8011 IPP/1.1: Model and Semantics January 2017 +-----------------------------+-----------------------+-------------+ | generated-natural-language- | 1setOf | REQUIRED | | supported | naturalLanguage | | +-----------------------------+-----------------------+-------------+ | ipp-versions-supported | 1setOf type2 keyword | REQUIRED | +-----------------------------+-----------------------+-------------+ | job-impressions-supported | rangeOfInteger(0:MAX) | RECOMMENDED | +-----------------------------+-----------------------+-------------+ | job-k-octets-supported | rangeOfInteger(0:MAX) | | +-----------------------------+-----------------------+-------------+ | job-media-sheets-supported | rangeOfInteger(1:MAX) | | +-----------------------------+-----------------------+-------------+ | multiple-document-jobs- | boolean | RECOMMENDED | | supported | | | +-----------------------------+-----------------------+-------------+ | multiple-operation-time-out | integer(1:MAX) | RECOMMENDED | +-----------------------------+-----------------------+-------------+ | natural-language-configured | naturalLanguage | REQUIRED | +-----------------------------+-----------------------+-------------+ | operations-supported | 1setOf type2 enum | REQUIRED | +-----------------------------+-----------------------+-------------+ | pdl-override-supported | type2 keyword | REQUIRED | +-----------------------------+-----------------------+-------------+ | printer-driver-installer | uri | | +-----------------------------+-----------------------+-------------+ | printer-info | text(127) | RECOMMENDED | +-----------------------------+-----------------------+-------------+ | printer-location | text(127) | RECOMMENDED | +-----------------------------+-----------------------+-------------+ | printer-make-and-model | text(127) | RECOMMENDED | +-----------------------------+-----------------------+-------------+ | printer-message-from- | text(127) | | | operator | | | +-----------------------------+-----------------------+-------------+ | printer-more-info- | uri | | | manufacturer | | | +-----------------------------+-----------------------+-------------+ | printer-name | name(127) | REQUIRED | +-----------------------------+-----------------------+-------------+ | reference-uri-schemes- | 1setOf uriScheme | | | supported | | | +-----------------------------+-----------------------+-------------+ Table 16: Printer Description Attributes (READ-WRITE) Sweet & McDonald Standards Track [Page 146] RFC 8011 IPP/1.1: Model and Semantics January 2017 +------------------------------+----------------------+-------------+ | Attribute | Syntax | REQUIRED? | +------------------------------+----------------------+-------------+ | pages-per-minute-color | integer(0:MAX) | RECOMMENDED | +------------------------------+----------------------+-------------+ | pages-per-minute | integer(0:MAX) | RECOMMENDED | +------------------------------+----------------------+-------------+ | printer-current-time | dateTime|unknown | RECOMMENDED | +------------------------------+----------------------+-------------+ | printer-is-accepting-jobs | boolean | REQUIRED | +------------------------------+----------------------+-------------+ | printer-more-info | uri | RECOMMENDED | +------------------------------+----------------------+-------------+ | printer-state | type1 enum | REQUIRED | +------------------------------+----------------------+-------------+ | printer-state-message | text(MAX) | RECOMMENDED | +------------------------------+----------------------+-------------+ | printer-state-reasons | 1setOf type2 keyword | REQUIRED | +------------------------------+----------------------+-------------+ | printer-up-time | integer(1:MAX) | REQUIRED | +------------------------------+----------------------+-------------+ | printer-uri-supported | 1setOf uri | REQUIRED | +------------------------------+----------------------+-------------+ | queued-job-count | integer(0:MAX) | REQUIRED | +------------------------------+----------------------+-------------+ | uri-authentication-supported | 1setOf type2 keyword | REQUIRED | +------------------------------+----------------------+-------------+ | uri-security-supported | 1setOf type2 keyword | REQUIRED | +------------------------------+----------------------+-------------+ Table 17: Printer Status Attributes (READ-ONLY) 5.4.1. printer-uri-supported (1setOf uri) This REQUIRED Printer attribute contains one or more URIs for the Printer. It MAY contain more than one URI for the Printer. An Administrator determines a Printer's URIs and configures this attribute to contain those URIs by some means outside the scope of this IPP/1.1 document. The precise format of the URIs is implementation dependent and depends on the protocol. See Sections 5.4.2 and 5.4.3 for a description of the "uri-authentication-supported" and "uri-security-supported" attributes, both of which are the REQUIRED companion attributes to this "printer-uri-supported" attribute. See Sections 3.4 ("Object Identity") and 9.2 ("URIs in Operation, Job, and Printer Attributes") for more information. Sweet & McDonald Standards Track [Page 147] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.2. uri-authentication-supported (1setOf type2 keyword) This REQUIRED Printer attribute MUST have the same cardinality (contain the same number of values) as the "printer-uri-supported" attribute. This attribute identifies the Client Authentication mechanism associated with each URI listed in the "printer-uri-supported" attribute. The Printer uses the specified mechanism to identify the authenticated user (see Section 9.3). The "i-th" value in "uri-authentication-supported" corresponds to the "i-th" value in "printer-uri-supported", and it describes the authentication mechanisms used by the Printer when accessed via that URI. See [RFC8010] for more details on Client Authentication. The following standard 'keyword' values are defined: o 'none': There is no authentication mechanism associated with the URI. The Printer assumes that the authenticated user is 'anonymous'. o 'requesting-user-name': When a Client performs an operation whose target is the associated URI, the Printer assumes that the authenticated user is specified by the "requesting-user-name" operation attribute (see Section 9.3). If the "requesting-user-name" attribute is absent in a request, the Printer assumes that the authenticated user is 'anonymous'. o 'basic': When a Client performs an operation whose target is the associated URI, the Printer challenges the Client with HTTP Basic authentication [RFC7617]. The Printer assumes that the authenticated user is the name received via the Basic authentication mechanism. o 'digest': When a Client performs an operation whose target is the associated URI, the Printer challenges the Client with HTTP Digest authentication [RFC7616]. The Printer assumes that the authenticated user is the name received via the Digest authentication mechanism. o 'certificate': When a Client performs an operation whose target is the associated URI, the Printer expects the Client to provide an X.509 certificate. The Printer assumes that the authenticated user is one of the textual names (Common Name or Subject Alternate Names) contained within the certificate. Sweet & McDonald Standards Track [Page 148] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.3. uri-security-supported (1setOf type2 keyword) This REQUIRED Printer attribute MUST have the same cardinality (contain the same number of values) as the "printer-uri-supported" attribute. This attribute identifies the security mechanisms used for each URI listed in the "printer-uri-supported" attribute. The "i-th" value in "uri-security-supported" corresponds to the "i-th" value in "printer-uri-supported", and it describes the security mechanisms used for accessing the Printer via that URI. See [RFC8010] for more details on security mechanisms. The following standard 'keyword' values are defined: o 'none': There are no secure communication channel protocols in use for the given URI. o 'tls': TLS [RFC5246] [RFC7525] is the secure communications channel protocol in use for the given URI. This attribute is orthogonal to the definition of a Client Authentication mechanism. Specifically, 'none' does not exclude Client Authentication. See Section 5.4.2. Consider the following example. For a single Printer, an Administrator configures the "printer-uri-supported", "uri-authentication-supported", and "uri-security-supported" attributes as follows: "printer-uri-supported": 'ipp://printer.example.com/ipp/print/ open-use-printer', 'ipp://printer.example.com/ipp/print/ restricted-use-printer', 'ipps://printer.example.com/ipp/print/ private-printer' "uri-authentication-supported": 'none', 'digest', 'basic' "uri-security-supported": 'none', 'none', 'tls' In this case, one Printer has three URIs. o For the first URI, 'ipp://printer.example.com/ipp/print/ open-use-printer', the value 'none' in "uri-security-supported" indicates that there is no secure channel protocol configured to run under HTTP. The value of 'none' in "uri-authentication-supported" indicates that all users are 'anonymous'. There will be no challenge, and the Printer will ignore "requesting-user-name". Sweet & McDonald Standards Track [Page 149] RFC 8011 IPP/1.1: Model and Semantics January 2017 o For the second URI, 'ipp://printer.example.com/ipp/print/ restricted-use-printer', the value 'none' in "uri-security-supported" indicates that there is no secure channel protocol configured to run under HTTP. The value of 'digest' in "uri-authentication-supported" indicates that the Printer will issue a challenge and that the Printer will use the name supplied by the Digest mechanism to determine the authenticated user (see Section 9.3). o For the third URI, 'ipps://printer.example.com/ipp/print/ private-printer', the value 'tls' in "uri-security-supported" indicates that TLS is being used to secure the channel. The Client SHOULD be prepared to use TLS framing to negotiate an acceptable ciphersuite to use while communicating with the Printer. In this case, the name implies the use of a secure communications channel, but the fact is made explicit by the presence of the 'tls' value in "uri-security-supported". The Client does not need to resort to understanding which security mechanisms it must use by following naming conventions or by parsing the URI to determine which security mechanisms are implied. The value of 'basic' in "uri-authentication-supported" indicates that the Printer will issue a challenge and that the Printer will use the name supplied by the Basic mechanism to determine the authenticated user (see Section 9.3). Because this challenge occurs in a TLS session, the channel is secure. Some Printers will be configured to support only one channel (either configured to use TLS access or not) and only one authentication mechanism. Such Printers only have one URI listed in the "printer-uri-supported" attribute. No matter the configuration of the Printer (whether it has only one URI or more than one URI), a Client MUST supply only one URI in the target "printer-uri" operation attribute. 5.4.4. printer-name (name(127)) This REQUIRED Printer attribute contains the name of the Printer. It is a name that is more End User friendly than a URI. An Administrator determines a Printer's name and sets this attribute to that name. This name can be the last part of the Printer's URI, or it can be unrelated. In non-US-English locales, a name can contain characters that are not allowed in a URI. 5.4.5. printer-location (text(127)) This RECOMMENDED Printer attribute identifies the location of the device. This could include things like 'in Room 123A, second floor of building XYZ'. Sweet & McDonald Standards Track [Page 150] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.6. printer-info (text(127)) This RECOMMENDED Printer attribute provides descriptive information about this Printer. This could include things like 'This printer can be used for printing color transparencies for HR presentations', or 'Out of courtesy for others, please print only small (1-5 page) jobs at this printer', or even 'This printer is going away on July 1; please find a new printer'. 5.4.7. printer-more-info (uri) This RECOMMENDED Printer attribute contains a URI used to obtain more information about this specific Printer. For example, this could be an HTTP URI referencing an HTML page accessible to a web browser. The information obtained from this URI is intended for End User consumption. Features outside the scope of IPP can be accessed from this URI. The information is intended to be specific to this Printer instance and site-specific services, e.g., Job pricing, services offered, and End User assistance. The device manufacturer can initially populate this attribute. 5.4.8. printer-driver-installer (uri) This Printer attribute contains a URI to use to locate the driver installer for this Printer. This attribute is intended for consumption by automata. The mechanics of Printer driver installation are outside the scope of this document. The device manufacturer can initially populate this attribute. 5.4.9. printer-make-and-model (text(127)) This RECOMMENDED Printer attribute identifies the make and model of the device. The device manufacturer can initially populate this attribute. 5.4.10. printer-more-info-manufacturer (uri) This Printer attribute contains a URI used to obtain more information about this type of device. The information obtained from this URI is intended for End User consumption. Features outside the scope of IPP can be accessed from this URI (e.g., latest firmware, upgrades, Printer drivers, optional features available, details on color support). The information is intended to be germane to this Printer without regard to site-specific modifications or services. The device manufacturer can initially populate this attribute. Sweet & McDonald Standards Track [Page 151] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.11. printer-state (type1 enum) This REQUIRED Printer attribute identifies the current state of the device. The "printer-state reasons" attribute augments the "printer-state" attribute to give more detailed information about the Printer in the given Printer state. A Printer updates this attribute continually if asynchronous event notification [RFC3995] is supported. Standard enum values are defined in Table 18. Values of "printer-state-reasons", such as 'spool-area-full' and 'stopped-partly', MAY be used to provide further information. +-------+-----------------------------------------------------------+ | Value | Symbolic Name and Description | +-------+-----------------------------------------------------------+ | '3' | 'idle': Indicates that new Jobs can start processing | | | without waiting. | +-------+-----------------------------------------------------------+ | '4' | 'processing': Indicates that Jobs are processing; new | | | Jobs will wait before processing. | +-------+-----------------------------------------------------------+ | '5' | 'stopped': Indicates that no Jobs can be processed and | | | intervention is required. | +-------+-----------------------------------------------------------+ Table 18: "printer-state" Enum Values 5.4.12. printer-state-reasons (1setOf type2 keyword) This REQUIRED Printer attribute supplies additional detail about the device's state. Some of the value definitions indicate conformance requirements; the rest are OPTIONAL. Each 'keyword' value MAY have a suffix to indicate its level of severity. The three levels are 'report' (least severe), 'warning', and 'error' (most severe): o '-report': This suffix indicates that the reason is a "report". An implementation can choose to omit some or all reports. Some reports specify finer granularity about the Printer state; others serve as a precursor to a warning. A report MUST contain nothing that could affect the printed output. Reports correspond to the 'other' value for the prtAlertSeverityLevel property in the Printer MIB [RFC3805]. Sweet & McDonald Standards Track [Page 152] RFC 8011 IPP/1.1: Model and Semantics January 2017 o '-warning': This suffix indicates that the reason is a "warning". An implementation can choose to omit some or all warnings. Warnings serve as a precursor to an error. A warning MUST contain nothing that prevents a Job from completing, though in some cases the output can be of lower quality. Warnings correspond to the 'warning' value for the prtAlertSeverityLevel property in the Printer MIB [RFC3805]. o '-error': This suffix indicates that the reason is an "error". An implementation MUST include all errors. If this attribute contains one or more errors, the Printer MUST be in the 'stopped' state. Errors correspond to the 'critical' value for the prtAlertSeverityLevel property in the Printer MIB [RFC3805]. If the implementation does not add any one of the three suffixes and the value is not 'none', Clients can assume that the reason is an "error" if the Printer is in the 'stopped' state and a "warning" if the Printer is in any other state. If a Printer controls more than one Output Device, each value of this attribute MAY apply to one or more of the Output Devices. An error on one Output Device that does not stop the Printer as a whole MAY appear as a warning in the Printer's "printer-state-reasons" attribute. If "printer-state" for such a Printer has a value of 'stopped', then there MUST be an error reason among the values in the "printer-state-reasons" attribute. The following standard 'keyword' values are defined: o 'none': There are no reasons. This state reason is semantically equivalent to "printer-state-reasons" without any value and MUST be used, since the '1setOf' attribute syntax requires at least one value. o 'other': The device has detected a condition other than one listed in this document. o 'connecting-to-device': The Printer has scheduled a Job on the Output Device and is in the process of connecting to a shared network Output Device (and might not be able to actually start printing the Job for an arbitrarily long time, depending on the usage of the Output Device by other servers on the network). o 'cover-open': One or more covers on the device are open, equivalent to a prtCoverStatus [RFC3805] of 3 (coverOpen). o 'developer-empty: The device is out of developer. Sweet & McDonald Standards Track [Page 153] RFC 8011 IPP/1.1: Model and Semantics January 2017 o 'developer-low': The device is low on developer. o 'door-open': One or more doors on the device are open, equivalent to a prtCoverStatus [RFC3805] of 3 (coverOpen). o 'fuser-over-temp': The fuser temperature is above normal, equivalent to a prtMarkerStatus [RFC3805] of 19 (the sum of "Unavailable because Broken" (3) and "Critical Alerts" (16)). o 'fuser-under-temp': The fuser temperature is below normal, equivalent to a prtMarkerStatus [RFC3805] of 19 (the sum of "Unavailable because Broken" (3) and "Critical Alerts" (16)). o 'input-tray-missing': One or more input trays are not in the device, equivalent to a prtInputStatus [RFC3805] of 19 (the sum of "Unavailable because Broken" (3) and "Critical Alerts" (16)). o 'interlock-open': One or more interlock devices on the Printer are unlocked, equivalent to a prtCoverStatus [RFC3805] of 5 (interlockOpen). o 'interpreter-resource-unavailable': An interpreter resource is unavailable (i.e., font, form). o 'marker-supply-empty: The device is out of at least one marker supply, e.g., toner, ink, ribbon. o 'marker-supply-low': The device is low on at least one marker supply, e.g., toner, ink, ribbon. o 'marker-waste-almost-full': The device marker supply waste receptacle is almost full. o 'marker-waste-full': The device marker supply waste receptacle is full. o 'media-empty': At least one input tray is empty, equivalent to a prtInputStatus [RFC3805] of 19 (the sum of "Unavailable because Broken" (3) and "Critical Alerts" (16)). o 'media-jam': The device has a media jam, equivalent to a prtInputStatus [RFC3805] of 19 (the sum of "Unavailable because Broken" (3) and "Critical Alerts" (16)). o 'media-low': At least one input tray is low on media, equivalent to a prtInputStatus [RFC3805] of 8 (Non-Critical Alerts). Sweet & McDonald Standards Track [Page 154] RFC 8011 IPP/1.1: Model and Semantics January 2017 o 'media-needed': A tray has run out of media, equivalent to a prtInputStatus [RFC3805] value of 17 (the sum of "Unavailable and OnRequest" (1) and "Critical Alerts" (16)). o 'moving-to-paused': Someone has paused the Printer using the Pause-Printer operation (see Section 4.2.7) or other means, but the device(s) is taking an appreciable time to stop. Later, when all output has stopped, "printer-state" becomes 'stopped', and the 'paused' value replaces the 'moving-to-paused' value in the "printer-state-reasons" attribute. This value MUST be supported if the Pause-Printer operation is supported and the implementation takes significant time to pause a device in certain circumstances. o 'opc-life-over': The optical photo conductor is no longer functioning, equivalent to a prtMarkerStatus [RFC3805] of 19 (the sum of "Unavailable because Broken" (3) and "Critical Alerts" (16)). o 'opc-near-eol': The optical photo conductor is near its end of life, equivalent to a prtMarkerStatus [RFC3805] of 8 (Non-Critical Alerts). o 'output-area-almost-full': One or more output areas are almost full, e.g., tray, stacker, collator, equivalent to a prtOutputStatus [RFC3805] of 8 (Non-Critical Alerts). o 'output-area-full': One or more output areas are full, e.g., tray, stacker, collator, equivalent to a prtInputStatus [RFC3805] of 19 (the sum of "Unavailable because Broken" (3) and "Critical Alerts" (16)). o 'output-tray-missing': One or more output trays are not in the device, equivalent to a prtOutputStatus [RFC3805] of 19 (the sum of "Unavailable because Broken" (3) and "Critical Alerts" (16)). o 'paused': Someone has paused the Printer using the Pause-Printer operation (see Section 4.2.7) or other means, and the Printer's "printer-state" is 'stopped'. In this state, a Printer MUST NOT produce printed output, but it MUST perform other operations requested by a Client. If a Printer had been printing a Job when the Printer was paused, the Printer MUST resume printing that Job when the Printer is no longer paused and leave no evidence in the printed output of such a pause. This value MUST be supported if the Pause-Printer operation is supported. Sweet & McDonald Standards Track [Page 155] RFC 8011 IPP/1.1: Model and Semantics January 2017 o 'shutdown': Someone has removed a Printer from service, and the device can be powered down or physically removed. In this state, a Printer MUST NOT produce printed output, and unless the Printer is realized by a print server that is still active, the Printer MUST perform no other operations requested by a Client, including returning this value. If a Printer had been printing a Job when it was shut down, the Printer MAY resume printing that Job when the Printer is restarted. If the Printer resumes printing such a Job, it can leave evidence in the printed output of such a shutdown, e.g., the part printed before the shutdown can be printed a second time after the shutdown. o 'spool-area-full': The limit of persistent storage allocated for spooling has been reached. The Printer is temporarily unable to accept more Jobs. The Printer will remove this value when it is able to accept more Jobs. This value SHOULD be used by a non-spooling Printer that only accepts one or a small number of Jobs at a time or by a spooling Printer that has filled the spool space. o 'stopped-partly': When a Printer controls more than one Output Device, this reason indicates that one or more Output Devices are stopped. If the reason is a report, fewer than half of the Output Devices are stopped. If the reason is a warning, fewer than all of the Output Devices are stopped. o 'stopping': The Printer is in the process of stopping the device and will be stopped in a while. When the device is stopped, the Printer will change the Printer's state to 'stopped'. The 'stopping-warning' reason is never an error, even for a Printer with a single Output Device. When an Output Device ceases accepting Jobs, the Printer will have this reason while the Output Device completes printing. o 'timed-out': The server was able to connect to the Output Device (or is always connected) but was unable to get a response from the Output Device. o 'toner-empty': The device is out of toner. o 'toner-low': The device is low on toner. Sweet & McDonald Standards Track [Page 156] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.13. printer-state-message (text(MAX)) This RECOMMENDED Printer attribute specifies information about the "printer-state" and "printer-state-reasons" attributes in human- readable text. If the Printer supports this attribute, the Printer MUST be able to generate this message in any of the natural languages identified by the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 4.1.4.1). 5.4.14. ipp-versions-supported (1setOf type2 keyword) This REQUIRED attribute identifies the IPP version(s) that this Printer supports, including major and minor versions, i.e., the version numbers for which this Printer implementation meets the conformance requirements. For version number validation, the Printer matches the (2-octet binary) "version-number" parameter supplied by the Client in each request (see Sections 4.1.1 and 4.1.8) with the (US-ASCII) 'keyword' values of this attribute. The following standard 'keyword' values are defined in this document: o '1.0': Meets the conformance requirements of IPP version 1.0 as specified in RFC 2566 [RFC2566] and RFC 2565 [RFC2565], including any extensions registered according to Section 7 and any extension defined in this version or any future version of the IPP Model and Semantics document (this document) or the IPP Encoding and Transport document [RFC8010] following the rules, if any, when the "version-number" parameter is '1.0'. o '1.1': Meets the conformance requirements of IPP version 1.1 as specified in this document and [RFC8010], including any extensions registered according to Section 7 and any extension defined in any future versions of this document or [RFC8010] following the rules, if any, when the "version-number" parameter is '1.1'. Additional values are defined in "IPP Version 2.0, 2.1, and 2.2" [PWG5100.12]. 5.4.15. operations-supported (1setOf type2 enum) This REQUIRED Printer attribute specifies the set of supported operations for this Printer and contained Jobs. This attribute is encoded as any other enum attribute syntax according to [RFC8010] as 32 bits. However, all 32-bit enum values for this attribute MUST NOT exceed 0x00007fff, since these same values are also passed in two octets in the "operation-id" field (see Sweet & McDonald Standards Track [Page 157] RFC 8011 IPP/1.1: Model and Semantics January 2017 Section 4.1.1) in each Protocol request with the two high-order octets omitted in order to indicate the operation being performed [RFC8010]. Table 19 lists the "operations-supported" attribute and "operation-id" parameter (see Section 4.1.2) enum values that are defined in this document. +---------------+---------------------------------------------------+ | Value | Operation Name | +---------------+---------------------------------------------------+ | 0x0000 | reserved, not used | +---------------+---------------------------------------------------+ | 0x0001 | reserved, not used | +---------------+---------------------------------------------------+ | 0x0002 | Print-Job | +---------------+---------------------------------------------------+ | 0x0003 | Print-URI | +---------------+---------------------------------------------------+ | 0x0004 | Validate-Job | +---------------+---------------------------------------------------+ | 0x0005 | Create-Job | +---------------+---------------------------------------------------+ | 0x0006 | Send-Document | +---------------+---------------------------------------------------+ | 0x0007 | Send-URI | +---------------+---------------------------------------------------+ | 0x0008 | Cancel-Job | +---------------+---------------------------------------------------+ | 0x0009 | Get-Job-Attributes | +---------------+---------------------------------------------------+ | 0x000a | Get-Jobs | +---------------+---------------------------------------------------+ | 0x000b | Get-Printer-Attributes | +---------------+---------------------------------------------------+ | 0x000c | Hold-Job | +---------------+---------------------------------------------------+ | 0x000d | Release-Job | +---------------+---------------------------------------------------+ | 0x000e | Restart-Job | +---------------+---------------------------------------------------+ | 0x000f | reserved for a future operation | Sweet & McDonald Standards Track [Page 158] RFC 8011 IPP/1.1: Model and Semantics January 2017 +---------------+---------------------------------------------------+ | 0x0010 | Pause-Printer | +---------------+---------------------------------------------------+ | 0x0011 | Resume-Printer | +---------------+---------------------------------------------------+ | 0x0012 | Purge-Jobs | +---------------+---------------------------------------------------+ | 0x0013-0x3fff | additional registered operations (see the IANA | | | IPP registry and Section 7.8) | +---------------+---------------------------------------------------+ | 0x4000-0x7fff | reserved for vendor extensions (see Section 7.8) | +---------------+---------------------------------------------------+ Table 19: "operations-supported" Enum Values 5.4.16. multiple-document-jobs-supported (boolean) This RECOMMENDED Printer attribute indicates whether the Printer supports more than one Document per Job, i.e., more than one Send-Document operation with Document data and/or Send-URI operations. If the Printer supports the Create-Job and Send-Document operations (see Sections 4.2.4 and 4.3.1), it MUST support this attribute. 5.4.17. charset-configured (charset) This REQUIRED Printer attribute identifies the charset that the Printer has been configured to represent 'text' and 'name' Printer attributes that are set by the Operator, Administrator, or manufacturer, i.e., for "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make-and-model" (text). Therefore, the value of the Printer's "charset-configured" attribute MUST also be among the values of the Printer's "charset-supported" attribute. 5.4.18. charset-supported (1setOf charset) This REQUIRED Printer attribute identifies the set of charsets that the Printer and contained Jobs support in attributes with attribute syntaxes 'text' and 'name'. At least the value 'utf-8' MUST be present, since IPP objects MUST support the UTF-8 [RFC3629] charset. If a Printer supports a charset, it means that for all attributes of syntaxes 'text' and 'name' the Printer MUST (1) accept the charset in requests and (2) return the charset in responses as needed. If more charsets than UTF-8 are supported, the Printer MUST perform charset conversion between the charsets as described in Section 4.1.4.2. Sweet & McDonald Standards Track [Page 159] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.19. natural-language-configured (naturalLanguage) This REQUIRED Printer attribute identifies the natural language that the Printer has been configured to represent 'text' and 'name' Printer attributes that are set by the Operator, Administrator, or manufacturer, i.e., for "printer-name" (name), "printer-location" (text), "printer-info" (text), and "printer-make-and-model" (text). When returning these Printer attributes, the Printer MAY return them in the configured natural language specified by this attribute, instead of the natural language requested by the Client in the "attributes-natural-language" operation attribute. See Section 4.1.4.1 for the specification of the OPTIONAL support for multiple natural languages. Therefore, the value of the Printer's "natural-language-configured" attribute MUST also be among the values of the Printer's "generated-natural-language-supported" attribute. 5.4.20. generated-natural-language-supported (1setOf naturalLanguage) This REQUIRED Printer attribute identifies the natural language(s) that the Printer and contained Jobs support in attributes with attribute syntaxes 'text' and 'name'. The natural language(s) supported depends on implementation and/or configuration. Unlike charsets, Printers MUST accept requests with any natural language or any Natural Language Override whether the natural language is supported or not. If a Printer supports a natural language, it means that for any of the attributes for which the Printer or Job generates messages, i.e., for the "job-state-message" and "printer-state-message" attributes and operation messages (see Section 4.1.5) in operation responses, the Printer and Job MUST be able to generate messages in any of the Printer's supported natural languages. See Sections 4.1.4, 5.1.2, and 5.1.3 for the definitions of 'text' and 'name' attributes in operation requests and responses. Note: A Printer that supports multiple natural languages often has separate catalogs of messages, one for each natural language supported. 5.4.21. document-format-default (mimeMediaType) This REQUIRED Printer attribute identifies the Document format that the Printer has been configured to assume if the Client does not supply a "document-format" operation attribute in any of the operation requests that supply Document data. The standard values for this attribute are Internet media types (sometimes called "MIME media types"). For further details, see the description of the 'mimeMediaType' attribute syntax in Section 5.1.10. Sweet & McDonald Standards Track [Page 160] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.22. document-format-supported (1setOf mimeMediaType) This REQUIRED Printer attribute identifies the set of Document formats that the Printer and contained Jobs can support. For further details, see the description of the 'mimeMediaType' attribute syntax in Section 5.1.10. 5.4.23. printer-is-accepting-jobs (boolean) This REQUIRED Printer attribute indicates whether the Printer is currently able to accept Jobs, i.e., is accepting Print-Job, Print-URI, and Create-Job requests. If the value is 'true', the Printer is accepting Jobs. If the value is 'false', the Printer is currently rejecting any Jobs submitted to it. In this case, the Printer returns the 'server-error-not-accepting-jobs' status-code. This value is independent of the "printer-state" and "printer-state-reasons" attributes because its value does not affect the current Job; rather, it affects future Jobs. This attribute, when 'false', causes the Printer to reject Jobs even when "printer-state" is 'idle' or, when 'true', causes the Printer to accept Jobs even when "printer-state" is 'stopped'. 5.4.24. queued-job-count (integer(0:MAX)) This REQUIRED Printer attribute contains a count of the number of Jobs that are either 'pending', 'processing', 'pending-held', or 'processing-stopped' and is set by the Printer. 5.4.25. printer-message-from-operator (text(127)) This Printer attribute provides a message from an Operator, Administrator, or "intelligent" process to indicate to the End User information or status of the Printer, such as why it is unavailable or when it is expected to be available. 5.4.26. color-supported (boolean) This RECOMMENDED Printer attribute identifies whether the device is capable of any type of color printing at all, including highlight color. All Document instructions having to do with color are embedded within the Document PDL, although IPP attributes can affect the rendering of those colors. Note: End Users are able to determine the nature and details of the color support by querying the "printer-more-info-manufacturer" Printer attribute. Sweet & McDonald Standards Track [Page 161] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.27. reference-uri-schemes-supported (1setOf uriScheme) This Printer attribute specifies which URI schemes are supported for use in the "document-uri" operation attribute of the Print-URI or Send-URI operations. If a Printer supports these OPTIONAL operations, it MUST support the "reference-uri-schemes-supported" Printer attribute with at least the following URI scheme value: o 'ftp': The Printer will use an FTP 'get' operation as defined in [RFC959] using FTP URLs as defined by [RFC3986]. The Printer MAY support other URI schemes (see Section 5.1.7). 5.4.28. pdl-override-supported (type2 keyword) This REQUIRED Printer attribute expresses the ability of a particular Printer implementation to override Document data instructions with IPP attributes. The following 'keyword' values are defined in this document: o 'attempted': This value indicates that the Printer attempts to make the IPP attribute values take precedence over embedded instructions in the Document data; however, there is no guarantee. o 'not-attempted': This value indicates that the Printer makes no attempt to make the IPP attribute values take precedence over embedded instructions in the Document data. Appendix C contains a full description of how this attribute interacts with and affects other IPP attributes, especially the "ipp-attribute-fidelity" attribute. 5.4.29. printer-up-time (integer(1:MAX)) This REQUIRED Printer attribute indicates the amount of time (in seconds) that this Printer instance has been up and running. The value is a monotonically increasing value starting from 1 when the Printer is started up (initialized, booted, etc.). This value is used to populate the Event Time Job Status attributes "time-at-creation", "time-at-processing", and "time-at-completed" (see Section 5.3.14). Sweet & McDonald Standards Track [Page 162] RFC 8011 IPP/1.1: Model and Semantics January 2017 If the Printer goes down at some value 'n' and comes back up, the implementation MAY: 1. know how long it has been down and resume at some value greater than 'n', or 2. restart from 1. In other words, if the device or devices that the Printer is representing are restarted or power-cycled, the Printer MAY continue counting this value or MAY reset this value to 1, depending on implementation. However, if the Printer software ceases running and restarts without knowing the last value for "printer-up-time", the implementation MUST reset this value to 1. If this value is reset and the Printer has persistent Jobs, the Printer MUST reset the "time-at-xxx (integer)" Event Time Job Status attributes according to Section 5.3.14. An implementation MAY use both implementation alternatives, depending on warm versus cold start, respectively. 5.4.30. printer-current-time (dateTime|unknown) This RECOMMENDED Printer attribute indicates the current date and time. This value is used to populate the Event Time Job Status attributes "date-time-at-creation", "date-time-at-processing", and "date-time-at-completed" (see Section 5.3.14). This value is obtained on a "best effort" basis and in practice does not have to be precise in order to be useful. A Printer implementation sets the value of this attribute by obtaining the date and time via some implementation-dependent means, such as getting the value from a network time server, initialization at time of manufacture, or setting by an Administrator. See [RFC3196] and [PWG5100.19] for examples. If an implementation supports this attribute and the implementation knows that it has not yet been set, then the implementation MUST return the value of this attribute using the out-of-band 'unknown', meaning the value is not yet known. See the beginning of Section 5.1. The time zone of this attribute might not be the time zone used by people located near the Printer or device. The Client MUST NOT expect the time zone of any received 'dateTime' value to be in the time zone of the Client or in the time zone of the people located near the Printer. Sweet & McDonald Standards Track [Page 163] RFC 8011 IPP/1.1: Model and Semantics January 2017 The Client SHOULD display any dateTime attributes to the user in the Client's local time by converting the 'dateTime' value returned by the server to the time zone of the Client, rather than using the time zone returned by the Printer in attributes that use the 'dateTime' attribute syntax. Note: Prior versions of this document incorrectly specified the use of the 'no-value' out-of-band value when the current date and time had not been set. The correct out-of-band value is 'unknown', since there is always an intrinsic current date and time. 5.4.31. multiple-operation-time-out (integer(1:MAX)) This RECOMMENDED Printer attribute identifies the minimum time (in seconds) that the Printer waits for additional Send-Document or Send-URI operations to follow a still-open Job before taking any recovery actions, such as the ones indicated in Section 4.3.1. If the Printer supports the Create-Job and Send-Document operations (see Sections 4.2.4 and 4.3.1), it MUST support this attribute. Printers SHOULD use a value between '60' and '240' (seconds). An implementation MAY allow an Administrator to set this attribute by means not defined in this document. If so, the Administrator MAY be able to set values outside this range. 5.4.32. compression-supported (1setOf type2 keyword) This REQUIRED Printer attribute identifies the set of supported compression algorithms for Document data. Compression only applies to the Document data; compression does not apply to the encoding of the IPP operation itself. The supported values are used to validate the Client-supplied "compression" operation attributes in Print-Job and Send-Document requests. Standard 'keyword' values defined in this document are: o 'none': no compression is used. o 'deflate': ZIP inflate/deflate compression technology described in RFC 1951 [RFC1951]. o 'gzip': GNU zip compression technology described in RFC 1952 [RFC1952]. o 'compress': UNIX compression technology described in RFC 1977 [RFC1977]. Sweet & McDonald Standards Track [Page 164] RFC 8011 IPP/1.1: Model and Semantics January 2017 5.4.33. job-k-octets-supported (rangeOfInteger(0:MAX)) This Printer attribute specifies the upper and lower bounds of total sizes of Jobs in K octets, i.e., in units of 1024 octets. The supported values are used to validate the Client-supplied "job-k-octets" operation attribute in Job Creation requests. The corresponding Job Description attribute "job-k-octets" is defined in Section 5.3.17.1. 5.4.34. job-impressions-supported (rangeOfInteger(0:MAX)) This RECOMMENDED Printer attribute specifies the upper and lower bounds for the number of Impressions per Job. The supported values are used to validate the Client-supplied "job-impressions" operation attribute in Job Creation requests. The corresponding Job Description attribute "job-impressions" is defined in Section 5.3.17.2. 5.4.35. job-media-sheets-supported (rangeOfInteger(1:MAX)) This Printer attribute specifies the upper and lower bounds for the number of Media Sheets per Job. The supported values are used to validate the Client-supplied "job-media-sheets" operation attribute in Job Creation requests. The corresponding Job attribute "job-media-sheets" is defined in Section 5.3.17.3. 5.4.36. pages-per-minute (integer(0:MAX)) This RECOMMENDED Printer attribute specifies the nominal number of pages per minute to the nearest whole number that can be generated by this Printer (e.g., simplex, black-and-white). This attribute is informative, not a service guarantee. Generally, it is the value used in the marketing literature to describe the speed of the device. A value of 0 indicates a device that takes more than two minutes to process a page. 5.4.37. pages-per-minute-color (integer(0:MAX)) This RECOMMENDED Printer attribute specifies the nominal number of pages per minute to the nearest whole number that can be generated by this Printer when printing color (e.g., simplex, color). For purposes of this attribute, the meaning of "color" is the same as that for the "color-supported" attribute; namely, the device is capable of any type of color printing at all, including highlight color. This attribute is informative, not a service guarantee. Generally, it is the value used in the marketing literature to describe the color capabilities of this device. Sweet & McDonald Standards Track [Page 165] RFC 8011 IPP/1.1: Model and Semantics January 2017 A value of 0 indicates a device that takes more than two minutes to process a page in color. If a color device has several color modes, it MAY use the "pages-per-minute" value for this attribute that corresponds to the mode that produces the highest number. Printers that are black-and-white only MUST NOT support this attribute. If this attribute is present, then the "color-supported" Printer Description attribute MUST be present and have a 'true' value. The values of the "pages-per-minute" and "pages-per-minute-color" attributes returned by the Get-Printer-Attributes operation MAY be affected by the "document-format" attribute supplied by the Client in the Get-Printer-Attributes request. In other words, the implementation MAY have different speeds, depending on the Document format being processed. See Section 4.2.5.1 ("Get-Printer-Attributes Request"). 6. Conformance This section describes conformance issues and requirements. This document introduces model entities such as objects, operations, attributes, attribute syntaxes, and attribute values. The following sections describe the conformance requirements that apply to these model entities. 6.1. Client Conformance Requirements This section describes the conformance requirements for a Client (see Section 3.1), whether it be: 1. contained within software controlled by an End User, e.g., activated by the "Print" menu item in an application that sends IPP requests, or 2. the print server component that sends IPP requests to either an Output Device or another "downstream" print server. A conforming Client supports all REQUIRED operations as defined in this document. For each attribute included in an operation request, a conforming Client MUST supply a value whose type and value syntax conforms to the requirements specified in Sections 4 and 5 of this document. A conforming Client MAY supply any Standards Track extensions and/or vendor extensions in an operation request, as long as the extensions meet the requirements in Section 7. Sweet & McDonald Standards Track [Page 166] RFC 8011 IPP/1.1: Model and Semantics January 2017 While this document does not define conformance requirements for the user interfaces provided by IPP Clients or their applications, best practices for user interfaces are defined in [PWG5100.19]. A Client MUST be able to accept any of the attribute syntaxes defined in Section 5.1, including their full range, that can be returned to it in a response from a Printer. In particular, for each attribute that the Client supports whose attribute syntax is 'text', the Client MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. Similarly, for each attribute that the Client supports whose attribute syntax is 'name', the Client MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. For presentation purposes, truncation of long attribute values is not recommended. A recommended approach would be for the Client implementation to allow the user to scroll through long attribute values. A response MAY contain attribute groups, attributes, attribute syntaxes, values, and status-code values that the Client does not expect. Therefore, a Client implementation MUST gracefully handle such responses and not refuse to interoperate with a conforming Printer that is returning Standards Track extensions or vendor extensions, including attribute groups, attributes, attribute syntaxes, attribute values, status-code values, and out-of-band attribute values that conform to Section 7. Clients can choose to ignore any parameters, attribute groups, attributes, attribute syntaxes, or values that they do not understand. While a Client is sending data to a Printer, it SHOULD do its best to prevent a channel from being closed by a lower layer when the channel is blocked (i.e., flow-controlled off) for whatever reason, e.g., 'out of paper' or 'Job ahead hasn't freed up enough memory'. However, the layer that launched the print submission (e.g., an End User) MAY close the channel in order to cancel the Job. When a Client closes a channel, a Printer MAY print all or part of the received portion of the Document. See the Encoding and Transport document [RFC8010] for more details. A Client MUST support Client Authentication as defined in [RFC8010]. A Client SHOULD support Operation Privacy and Server Authentication as defined in [RFC8010]. See also Section 9 of this document. Sweet & McDonald Standards Track [Page 167] RFC 8011 IPP/1.1: Model and Semantics January 2017 6.2. IPP Object Conformance Requirements This section specifies the conformance requirements for conforming implementations of IPP objects (see Section 3). These requirements apply to an IPP object whether it is: 1) an (embedded) device component that accepts IPP requests and controls the device, or 2) a component of a print server that accepts IPP requests (where the print server controls one or more networked devices using IPP or other protocols). 6.2.1. Objects Conforming implementations MUST implement all of the model objects as defined in this document in the indicated sections: Section 3.1 - Printer Object Section 3.2 - Job Object 6.2.2. Operations Conforming IPP object implementations MUST implement all of the REQUIRED model operations, including REQUIRED responses, as defined in this document in the indicated sections. Table 20 lists the operations for a Printer, while Table 21 lists the operations for a Job. Sweet & McDonald Standards Track [Page 168] RFC 8011 IPP/1.1: Model and Semantics January 2017 +----------------------------------------+-------------+ | Operation | Conformance | +----------------------------------------+-------------+ | Print-Job (Section 4.2.1) | REQUIRED | +----------------------------------------+-------------+ | Print-URI (Section 4.2.2) | OPTIONAL | +----------------------------------------+-------------+ | Validate-Job (Section 4.2.3) | REQUIRED | +----------------------------------------+-------------+ | Create-Job (Section 4.2.4) | RECOMMENDED | +----------------------------------------+-------------+ | Get-Printer-Attributes (Section 4.2.5) | REQUIRED | +----------------------------------------+-------------+ | Get-Jobs (Section 4.2.6) | REQUIRED | +----------------------------------------+-------------+ | Pause-Printer (Section 4.2.7) | OPTIONAL | +----------------------------------------+-------------+ | Resume-Printer (Section 4.2.8) | OPTIONAL | +----------------------------------------+-------------+ | Purge-Jobs (Section 4.2.9) | SHOULD NOT | +----------------------------------------+-------------+ Table 20: Conformance Requirements for Printer Operations +------------------------------------+-------------+ | Operation | Conformance | +------------------------------------+-------------+ | Send-Document (Section 4.3.1) | RECOMMENDED | +------------------------------------+-------------+ | Send-URI (Section 4.3.2) | RECOMMENDED | +------------------------------------+-------------+ | Cancel-Job (Section 4.3.3) | REQUIRED | +------------------------------------+-------------+ | Get-Job-Attributes (Section 4.3.4) | REQUIRED | +------------------------------------+-------------+ | Hold-Job (Section 4.3.5) | OPTIONAL | +------------------------------------+-------------+ | Release-Job (Section 4.3.6) | OPTIONAL | +------------------------------------+-------------+ | Restart-Job (Section 4.3.7) | SHOULD NOT | +------------------------------------+-------------+ Table 21: Conformance Requirements for Job Operations Sweet & McDonald Standards Track [Page 169] RFC 8011 IPP/1.1: Model and Semantics January 2017 Conforming IPP objects MUST support all REQUIRED operation attributes and all values of such attributes if so indicated in the description. Conforming IPP objects MUST ignore all unsupported or unknown operation attributes or Operation Attributes groups received in a request but MUST reject a request that contains a supported operation attribute that contains an unsupported value. Conforming IPP objects MAY return operation responses that contain attribute groups, attribute names, attribute syntaxes, attribute values, and status-code values that are extensions to this specification. The additional attribute groups MAY occur in any order. The following section on object attributes specifies the support required for object attributes. 6.2.3. IPP Object Attributes Conforming IPP objects MUST support all of the REQUIRED object attributes, as defined in this document in the indicated sections. If an object supports an attribute, it MUST support only those values specified in this document or through the extension mechanism described in Section 6.2.5. It MAY support any non-empty subset of these values. That is, it MUST support at least one of the specified values and at most all of them. 6.2.4. Versions IPP/1.1 Clients MUST meet the conformance requirements for Clients specified in this document and [RFC8010]. IPP/1.1 Clients MUST be capable of sending requests containing a "version-number" parameter with a value of '1.1'. IPP/1.1 Printer and Job objects MUST meet the conformance requirements for IPP objects specified in this document and [RFC8010]. IPP/1.1 objects MUST accept requests containing a "version-number" parameter with a '1.1' value or reject the request if the operation is not supported. Sweet & McDonald Standards Track [Page 170] RFC 8011 IPP/1.1: Model and Semantics January 2017 It is beyond the scope of this specification to mandate conformance with other IPP versions. However, IPP was deliberately designed to make supporting different versions easy. IPP/1.1 Printer implementations MUST: o decode and process any well-formed IPP/1.1 request, and o respond appropriately with a response containing the same "version-number" parameter value used by the Client in the request. IPP/1.1 Client implementations MUST: o decode and process any well-formed IPP/1.1 response. IPP Clients SHOULD try supplying alternate version numbers if they receive a 'server-error-version-not-supported' error in a response. 6.2.5. Extensions A conforming IPP object MAY support Standards Track extensions and vendor extensions, as long as the extensions meet the requirements specified in Section 7. For each attribute included in an operation response, a conforming IPP object MUST return a value whose type and value syntax conforms to the requirements specified in Sections 4 and 5 of this document. 6.2.6. Attribute Syntaxes An IPP object MUST be able to accept any of the attribute syntaxes defined in Section 5.1, including their full range, in any operation in which a Client can supply attributes or the Administrator can configure attributes (by means outside the scope of this IPP/1.1 document). In particular, for each attribute that the IPP object supports whose attribute syntax is 'text', the IPP object MUST accept and process both the 'textWithoutLanguage' and 'textWithLanguage' forms. Similarly, for each attribute that the IPP object supports whose attribute syntax is 'name', the IPP object MUST accept and process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. Furthermore, an IPP object MUST return attributes to the Client in operation responses that conform to the syntaxes specified in Section 5.1, including their full range if supplied previously by a Client. Sweet & McDonald Standards Track [Page 171] RFC 8011 IPP/1.1: Model and Semantics January 2017 6.2.7. Security An IPP Printer implementation SHOULD contain support for Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC8010]. A Printer implementation MAY allow an Administrator to configure the Printer so that all, some, or none of the users are authenticated. See also Section 9 of this document. An IPP Printer implementation SHOULD contain support for Operation Privacy and Server Authentication as defined in [RFC8010]. A Printer implementation MAY allow an Administrator to configure the degree of support for Operation Privacy and Server Authentication. See also Section 9 of this document. Security MUST NOT be compromised when a Client supplies a lower "version-number" parameter in a request. For example, if a Printer conforming to IPP/1.1 accepts version '1.0' requests and is configured to enforce Digest Authentication, it MUST do the same for a version '1.0' request. 6.3. Charset and Natural Language Requirements All Clients and IPP objects MUST support the 'utf-8' charset as defined in Section 5.1.8. IPP objects MUST be able to accept any Client request that correctly uses the "attributes-natural-language" operation attribute or the Natural Language Override mechanism on any individual attribute whether or not the natural language is supported by the IPP object. If an IPP object supports a natural language, then it MUST be able to translate (perhaps by table lookup) all generated 'text' or 'name' attribute values into one of the supported languages (see Section 4.1.4). Sweet & McDonald Standards Track [Page 172] RFC 8011 IPP/1.1: Model and Semantics January 2017 7. IANA Considerations This section describes the procedures for defining Standards Track and vendor extensions to this document. This affects the following subregistries of the IANA IPP registry: 1. Objects 2. Attributes 3. Keyword Attribute Values 4. Enum Attribute Values 5. Attribute Group Tags 6. Out-of-Band Attribute Value Tags 7. Attribute Syntaxes 8. Operations 9. Status-Code Values Extensions registered for use with IPP are OPTIONAL for Client and IPP object conformance to the IPP/1.1 Model and Semantics document (this document). These extension procedures are aligned with the guidelines as set forth in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. Appendix A describes how to propose new registrations for consideration. IANA will reject registration proposals that leave out required information or do not follow the appropriate format described in Appendix A. The IPP/1.1 Model and Semantics document can also be extended by an appropriate Standards Track document that specifies any of the above extensions. The IANA policy (using terms defined in [RFC5226]) for all extensions is Specification Required, Expert Review, or First Come First Served as documented in the following subsections. Registrations submitted to IANA are forwarded to the IPP Designated Expert(s) who reviews the proposal on a mailing list that the Designated Expert(s) keeps for this purpose. Initially, that list is the mailing list used by the PWG IPP WG: ipp@pwg.org Sweet & McDonald Standards Track [Page 173] RFC 8011 IPP/1.1: Model and Semantics January 2017 The IPP Designated Expert(s) is appointed by the IESG Area Director responsible for IPP, according to [RFC5226]. In addition, the IANA-PRINTER-MIB [RFC3805] has been updated to reference this document; the current version is available from <http://www.iana.org>. 7.1. Object Extensions The IANA policy (using terms defined in [RFC5226]) for object extensions was formerly Expert Review; this document changes the policy to Specification Required. 7.2. Attribute Extensibility Since attribute names are type2 keywords (see Section 5.1.4), the IANA policy (using terms defined in [RFC5226]) for attribute extensions is Expert Review. For vendor attribute extensions, implementors SHOULD use keywords with a suitable distinguishing prefix such as 'smiNNN-' where NNN is an SMI Private Enterprise Number (PEN) [IANA-PEN]. For example, if the company Example Corp. had obtained the SMI PEN 32473, then a vendor attribute 'foo' would be 'smi32473-foo'. Note: Prior versions of this document recommended using a fully qualified domain name [RFC1035] as the prefix (e.g., 'example.com-foo'), and many IPP implementations have also used reversed domain names (e.g., 'com.example-foo'). Domain names have proven problematic due to the length of some domain names, parallel use of country-specific domain names (e.g., 'example.co.jp-foo'), and changes in ownership of domain names. If a new Printer attribute is defined and its values can be affected by a specific Document format, its specification needs to contain the following sentence: "The value of this attribute returned in a Get-Printer-Attributes response MAY depend on the "document-format" attribute supplied (see Section 4.2.5.1) of the IPP/1.1 Model and Semantics document." If the specification does not, then its value in the Get-Printer-Attributes response MUST NOT depend on the "document-format" attribute supplied in the request. Sweet & McDonald Standards Track [Page 174] RFC 8011 IPP/1.1: Model and Semantics January 2017 When a new Job Template attribute is registered, the value of the Printer attributes MAY vary with "document-format" supplied in the request without the specification having to indicate so. 7.3. Keyword Extensibility The IANA policy (using terms defined in [RFC5226]) for type1 keyword extensions is Specification Required. The IANA policy for type2 keyword extensions is Expert Review. The IANA policy for vendor keyword extensions is First Come First Served. Only attributes using the type1 and type2 keyword syntax can be registered in the IANA IPP registry. Note: The type1 or type2 prefix on the basic attribute syntax is provided only to communicate the IANA policy required for registration and is not represented in IPP messages. Both type1 and type2 'keyword' values are represented using the same 'keyword' value tag. For type1 and type2 keywords, the proposer includes the name of the keyword in the registration proposal, and the name is part of the technical review. For vendor keyword extensions, implementors SHOULD either: a. follow attribute-specific guidance such as the guidance defined in [PWG5101.1], or b. use keywords with a suitable distinguishing prefix, such as 'smiNNN-' where NNN is an SMI Private Enterprise Number (PEN) [IANA-PEN]. For example, if the company Example Corp. had obtained the SMI PEN 32473, then a vendor keyword 'foo' would be 'smi32473-foo'. Note: Prior versions of this document recommended using a fully qualified domain name [RFC1035] as the prefix (e.g., 'example.com-foo'), and many IPP implementations have also used reversed domain names (e.g., 'com.example-foo'). Domain names have proven problematic due to the length of some domain names, parallel use of country-specific domain names (e.g., 'example.co.jp-foo'), and changes in ownership of domain names. When a type2 keyword extension is approved, the IPP Designated Expert(s) becomes the point of contact for any future maintenance that might be required for that registration. Sweet & McDonald Standards Track [Page 175] RFC 8011 IPP/1.1: Model and Semantics January 2017 7.4. Enum Extensibility The IANA policy (using terms defined in [RFC5226]) for type1 enum extensions is Specification Required. The IANA policy for type2 enum extensions is Expert Review. The IANA policy for vendor enum extensions is First Come First Served. Only attributes using the type1 and type2 enum syntax can be registered in the IANA IPP registry. Note: The type1 or type2 prefix on the basic attribute syntax is provided only to communicate the IANA policy required for registration and is not represented in IPP messages. Both type1 and type2 enum values are represented using the same enum value tag. For vendor enum extensions, implementors MUST use values in the reserved integer range, which is 0x40000000 to 0x7fffffff. Implementors SHOULD consult with the IPP Designated Expert(s) to reserve vendor extension value(s) for their usage. When a type1 or type2 enum extension is approved, the IPP Designated Expert(s), in consultation with IANA, assigns the next available enum number for each enum value. When a type2 enum extension is approved, the IPP Designated Expert(s) becomes the point of contact for any future maintenance that might be required for that registration. 7.5. Attribute Group Extensibility The IANA policy (using terms defined in [RFC5226]) for attribute group extensions was formerly Expert Review; this document changes the policy to Specification Required. For attribute groups, the IPP Designated Expert(s), in consultation with IANA, assigns the next attribute group tag code in the appropriate range as specified in [RFC8010]. 7.6. Out-of-Band Attribute Value Extensibility The IANA policy (using terms defined in [RFC5226]) for out-of-band attribute value extensions was formerly Expert Review; this document changes the policy to Specification Required. For out-of-band attribute value tags, the IPP Designated Expert(s), in consultation with IANA, assigns the next out-of-band attribute value tag code in the appropriate range as specified in [RFC8010]. Sweet & McDonald Standards Track [Page 176] RFC 8011 IPP/1.1: Model and Semantics January 2017 7.7. Attribute Syntax Extensibility The IANA policy (using terms defined in [RFC5226]) for attribute syntax extensions was formerly Expert Review; this document changes the policy to Specification Required. The IANA policy for vendor attribute syntax extensions (tags 0x40000000 to 0x7fffffff) is First Come First Served. Only attribute syntaxes in the range of 0x00000000 to 0x3fffffff can be registered in the IANA IPP registry. For vendor attribute syntax extensions, implementors MUST use values in the reserved integer range, which is 0x40000000 to 0x7fffffff. Implementors SHOULD consult with the IPP Designated Expert(s) to reserve vendor extension value(s) for their usage. For registered attribute syntaxes, the IPP Designated Expert(s), in consultation with IANA, assigns the next attribute syntax tag in the appropriate range as specified in [RFC8010]. 7.8. Operation Extensibility The IANA policy (using terms defined in [RFC5226]) for operation extensions is Expert Review. The IANA policy for vendor operation extensions (values 0x4000 to 0x7fff) is First Come First Served. Only operation codes in the range of 0x0000 to 0x3fff can be registered in the IANA IPP registry. For vendor operation extensions, implementors MUST use values in the reserved integer range, which is 0x4000 to 0x7fff. Implementors SHOULD consult with the IPP Designated Expert(s) to reserve vendor extension value(s) for their usage. For registered operation extensions, the IPP Designated Expert(s), in consultation with IANA, assigns the next "operation-id" code as specified in Section 5.4.15. Sweet & McDonald Standards Track [Page 177] RFC 8011 IPP/1.1: Model and Semantics January 2017 7.9. Status-Code Extensibility The IANA policy (using terms defined in [RFC5226]) for status-code extensions is Expert Review. The IANA policy for vendor status-code extensions (codes 0x0n80 to 0x0nff, for n = 0 to 5) is First Come First Served. Only status-code values in the range of 0x0n00 to 0x0n7f can be registered in the IANA IPP registry. The status-code values are allocated in ranges as specified in Appendix B for each status-code class: "informational" - Request received, continuing process "successful" - The action was successfully received, understood, and accepted "redirection" - Further action is taken in order to complete the request "client-error" - The request contains bad syntax or cannot be fulfilled "server-error" - The IPP object failed to fulfill an apparently valid request For vendor operation status-code extensions, implementors MUST use the top of each range (0x0n80 to 0x0nff) as specified in Appendix B. Implementors SHOULD consult with the IPP Designated Expert(s) to reserve vendor extension value(s) for their usage. For registered operation status-code values, the IPP Designated Expert(s), in consultation with IANA, assigns the next status-code in the appropriate class range as specified in Appendix B. Sweet & McDonald Standards Track [Page 178] RFC 8011 IPP/1.1: Model and Semantics January 2017 8. Internationalization Considerations Some of the attributes have values that are text strings and names that are intended for human understanding rather than machine understanding (see the 'text' and 'name' attribute syntaxes in Sections 5.1.2 and 5.1.3). In each operation request, the Client o identifies the charset and natural language of the request that affects each supplied 'text' and 'name' attribute value, and o requests the charset and natural language for attributes returned by the IPP object in operation responses (as described in Section 4.1.4.1). In addition, the Client MAY separately and individually identify the Natural Language Override of a supplied 'text' or 'name' attribute using the 'textWithLanguage' and 'nameWithLanguage' techniques described in Sections 5.1.2.2 and 5.1.3.2, respectively. All IPP objects MUST support the UTF-8 [RFC3629] charset in all 'text' and 'name' attributes supported. If an IPP object supports more than the UTF-8 charset, the object MUST convert between them in order to return the requested charset to the Client according to Section 4.1.4.2. If an IPP object supports more than one natural language, the object SHOULD return 'text' and 'name' values in the natural language requested where those values are generated by the Printer (see Section 4.1.4.1). For Printers that support multiple charsets and/or multiple natural languages in 'text' and 'name' attributes, different Jobs might have been submitted in differing charsets and/or natural languages. All responses MUST be returned in the charset requested by the Client. However, the Get-Jobs operation uses the 'textWithLanguage' and 'nameWithLanguage' mechanisms to identify the differing natural languages with each Job attribute returned. The Printer also has configured charset and natural language attributes. The Client can query the Printer to determine the list of charsets and natural languages supported by the Printer and what the Printer's configured values are. See the "charset-configured", "charset-supported", "natural-language-configured", and "generated-natural-language-supported" Printer Description attributes for more details. Sweet & McDonald Standards Track [Page 179] RFC 8011 IPP/1.1: Model and Semantics January 2017 The "charset-supported" attribute identifies the supported charsets. If a charset is supported, the IPP object MUST be capable of converting to and from that charset into any other supported charset. In many cases, an IPP object will support only one charset, and it MUST be the UTF-8 charset. The "charset-configured" attribute identifies the one supported charset that is the native charset, given the current configuration of the IPP object (Administrator defined). The "generated-natural-language-supported" attribute identifies the set of supported natural languages for generated messages; it is not related to the set of natural languages that MUST be accepted for Client-supplied 'text' and 'name' attributes. For Client-supplied 'text' and 'name' attributes, an IPP object MUST accept ALL supplied natural languages. For example, if a Client supplies a Job name that is in 'fr-ca' but the Printer only generates 'en-us', the Printer object MUST still accept the Job name value. The "natural-language-configured" attribute identifies the one supported natural language for generated messages that is the native natural language, given the current configuration of the IPP object (Administrator defined). Attributes of types 'text' and 'name' are populated from different sources. These attributes can be categorized into the following groups (depending on the source of the attribute): 1. Some attributes are supplied by the Client (e.g., the Client-supplied "job-name", "document-name", and "requesting-user-name" operation attributes along with the corresponding Job's "job-name" and "job-originating-user-name" attributes). The IPP object MUST accept these attributes in any natural language no matter what the set of supported languages for generated messages. 2. Some attributes are supplied by the Administrator (e.g., the Printer's "printer-name" and "printer-location" attributes). These can also be in any natural language. If the natural language for these attributes is different than what a Client requests, then they MUST be reported using the Natural Language Override mechanism. Sweet & McDonald Standards Track [Page 180] RFC 8011 IPP/1.1: Model and Semantics January 2017 3. Some attributes are supplied by the device manufacturer (e.g., the Printer's "printer-make-and-model" attribute). These can also be in any natural language. If the natural language for these attributes is different than what a Client requests, then they MUST be reported using the Natural Language Override mechanism. 4. Some attributes are supplied by the Operator (e.g., the Job's "job-message-from-operator" attribute). These can also be in any natural language. If the natural language for these attributes is different than what a Client requests, then they MUST be reported using the Natural Language Override mechanism. 5. Some attributes are generated by the IPP object (e.g., the Job's "job-state-message" attribute, the Printer's "printer-state-message" attribute, and the "status-message" operation attribute). These attributes can only be in one of the "generated-natural-language-supported" natural languages. If a Client requests some natural language for these attributes other than one of the supported values, the IPP object SHOULD respond using the value of the "natural-language-configured" attribute (using the Natural Language Override mechanism if needed). The 'text' and 'name' attributes specified in this version of this document (additional ones will be registered according to the procedures in Section 7) are shown in Table 22. +-----------------------------------+-------------------------------+ | Attributes | Source | +-----------------------------------+-------------------------------+ | Operation Attributes: | | | | | | job-name (name) | Client | | document-name (name) | Client | | requesting-user-name (name) | Client | | status-message (text) | Job or Printer | | detailed-status-message (text) | Job or Printer (note 1) | | document-access-error (text) | Job or Printer (note 1) | | | | | Job Template Attributes: | | | | | | job-hold-until (keyword | name) | Client matches Administrator- | | | configured | | job-hold-until-default (keyword | | Client matches Administrator- | | name) | configured | | job-hold-until-supported (keyword | Client matches Administrator- | | | name) | configured | Sweet & McDonald Standards Track [Page 181] RFC 8011 IPP/1.1: Model and Semantics January 2017 | job-sheets (keyword | name) | Client matches Administrator- | | | configured | | job-sheets-default (keyword | | Client matches Administrator- | | name) | configured | | job-sheets-supported (keyword | | Client matches Administrator- | | name) | configured | | media (keyword | name) | Client matches Administrator- | | | configured | | media-default (keyword | name) | Client matches Administrator- | | | configured | | media-supported (keyword | name) | Client matches Administrator- | | | configured | | media-ready (keyword | name) | Client matches Administrator- | | | configured | | | | | Job Description Attributes: | | | | | | job-name (name) | Client or Printer | | job-originating-user-name (name) | Printer | | job-state-message (text) | Job or Printer | | output-device-assigned | Administrator | | (name(127)) | | | job-message-from-operator | Operator | | (text(127)) | | | job-detailed-status-messages | Job or Printer (note 1) | | (1setOf text) | | | job-document-access-errors | Job or Printer (note 1) | | (1setOf text) | | | | | | Printer Description Attributes: | | | | | | printer-name (name(127)) | Administrator | | printer-location (text(127)) | Administrator | | printer-info (text(127)) | Administrator | | printer-make-and-model | Administrator or manufacturer | | (text(127)) | | | printer-state-message (text) | Printer | | printer-message-from-operator | Operator | | (text(127)) | | +-----------------------------------+-------------------------------+ Table 22: 'text' and 'name' Attributes Note 1: Neither the Printer nor the Client localizes these message attributes, since they are intended for use by the Administrator or other experienced technical persons. Sweet & McDonald Standards Track [Page 182] RFC 8011 IPP/1.1: Model and Semantics January 2017 9. Security Considerations It is difficult to anticipate the security risks that might exist in any given IPP environment. For example, if IPP is used within a given small business over a private LAN with physical security, the risks of exposing Document data can be low enough that the business will choose not to use encryption on that data. However, if the connection between the Client and the IPP object is over a public network, the Client can protect the content of the information during transmission through the network with encryption. Furthermore, the value of the information being printed can vary from one IPP environment to the next. Printing payroll checks, for example, would have a different value than printing public information from a file. There is also the possibility of denial-of- service attacks, but denial-of-service attacks against printing resources are not well understood, and there are no published precedents regarding this scenario. Once the authenticated identity of the requester has been supplied to the IPP object, the object uses that identity to enforce any authorization policy that might be in place. For example, one site's policy might be that only the Job owner is allowed to cancel a Job. The details and mechanisms to set up a particular access control policy are not part of this document and are typically established via some other type of administrative or access control framework. However, there are operation status-code values that allow an IPP server to return information back to a Client about any potential access control violations for an IPP object. During a Job Creation request, the Client's identity is recorded in the Job object in an implementation-defined attribute. This information can be used to verify a Client's identity for subsequent operations on that Job object in order to enforce any access control policy that might be in effect. See Section 9.3 below for more details. This and other information stored in the Job object can also be considered personal or sensitive in nature and can be filtered out as part of a configured privacy policy (Section 9.4). Since the security levels or the specific threats that an Administrator can be concerned with cannot be anticipated, IPP implementations MUST be capable of operating with different security mechanisms and security policies as required by the individual installation. Security policies might vary from very strong to very weak, or to none at all, and corresponding security mechanisms will be required. Sweet & McDonald Standards Track [Page 183] RFC 8011 IPP/1.1: Model and Semantics January 2017 9.1. Security Scenarios The following sections describe specific security attacks for IPP environments. Where examples are provided, they are illustrative of the environment and not an exhaustive set. 9.1.1. Client and Server in the Same Security Domain This environment is typical of internal networks where traditional office workers print the output of personal productivity applications on shared workgroup Printers, or where batch applications print their output on large production Printers. Although the identity of the user has been authenticated and can be trusted in this environment, a user might want to protect the content of a Document against such attacks as eavesdropping, replaying, or tampering by using a secure transport such as TLS [RFC5246]. 9.1.2. Client and Server in Different Security Domains Examples of this environment include printing a Document created by the Client on a publicly available Printer, such as at a commercial print shop, or printing a Document remotely on a business associate's Printer. This latter operation is functionally equivalent to sending the Document to the business associate as a facsimile. Printing sensitive information on a Printer in a different security domain requires strong security measures. In this environment, authentication of the Printer is required as well as protection against unauthorized use of print resources. Since the Document crosses security domains, protection against eavesdropping and Document tampering is also required. It will also be important in this environment to protect Printers against "spamming" and malicious Document content -- authentication and Document data pre-scanning can be used to minimize those threats. 9.1.3. Print by Reference When the Document is not stored on the Client, printing can be done by reference. That is, the print request can contain a reference, or pointer, to the Document instead of the actual Document itself -- see Sections 4.2.2 and 4.3.2. Standard methods currently do not exist for remote entities to "assume" the credentials of a Client for forwarding requests to a third party. It is anticipated that print by reference will be used to access "public" Documents. Note that sophisticated methods for authenticating "proxies" are beyond the scope of this IPP/1.1 document. Because Printers typically process Jobs serially, print by reference is not seen as a serious denial-of- service threat to the referenced servers. Sweet & McDonald Standards Track [Page 184] RFC 8011 IPP/1.1: Model and Semantics January 2017 9.2. URIs in Operation, Job, and Printer Attributes The "printer-uri-supported" attribute contains the Printer's URI(s). Its companion attribute, "uri-security-supported", identifies the security mechanism used for each URI listed in the "printer-uri-supported" attribute. For each Printer operation request, a Client MUST supply only one URI in the "printer-uri" operation attribute. In other words, even though the Printer supports more than one URI, the Client only interacts with the Printer using one of its URIs. This duality is not needed for Job objects, since Printers will act as the "factory" for Job objects and a given Printer will, depending on the Printer's security configuration, generate the correct URI for new Job objects. 9.3. URIs for Each Authentication Mechanism Each URI has an authentication mechanism associated with it. If the URI is the "i-th" element of "printer-uri-supported", then the authentication mechanism is the "i-th" element of "uri-authentication-supported". For a list of possible authentication mechanisms, see Section 5.4.2. The Printer uses an authentication mechanism to determine the name of the user performing an operation. This user is called the "authenticated user". The credibility of authentication depends on the mechanism that the Printer uses to obtain the user's name. When the authentication mechanism is 'none', all authenticated users are 'anonymous'. During Job Creation requests, the Printer initializes the value of the "job-originating-user-name" attribute (see Section 5.3.6) to be the authenticated user. The authenticated user in this case is called the "Job owner". If an implementation can be configured to support more than one authentication mechanism (see Section 5.4.2), then it MUST implement rules for determining equality of authenticated user names that have been authenticated via different authentication mechanisms. One possible policy is that identical names that are authenticated via different mechanisms are different. For example, a user can cancel his Job only if he uses the same authentication mechanism for both Cancel-Job and Print-Job. Another policy is that identical names that are authenticated via different mechanisms are the same if the authentication mechanism for the later operation is not less strong than the authentication mechanism for the earlier Job Creation operation. For example, a user can cancel his Job only if he uses the same or stronger authentication mechanism for Cancel-Job and Print-Job. With this second policy, a Job submitted via Sweet & McDonald Standards Track [Page 185] RFC 8011 IPP/1.1: Model and Semantics January 2017 'requesting-user-name' authentication could be canceled via 'digest' authentication. With the first policy, the Job could not be canceled in this way. A Client is able to determine the authentication mechanism used to create a Job. It is the "i-th" value of the Printer's "uri-authentication-supported" attribute (see Section 5.4.2), where "i" is the index of the element of the Printer's "printer-uri-supported" attribute (see Section 5.4.1) equal to the Job's "job-printer-uri" attribute (see Section 5.3.3). 9.4. Restricted Queries In many IPP operations, a Client supplies a list of attributes to be returned in the response. For security reasons, an IPP object can be configured not to return all attributes (or all values) that a Client requests. The Job attributes returned MAY depend on whether the requesting user is the same as the user that submitted the Job. The IPP object MAY even return none of the requested attributes. In such cases, the status returned is the same as if the object had returned all requested attributes. The Client cannot tell by such a response whether the requested attribute was present or absent in the object. 9.5. Operations Performed by Operators and Administrators For the three Printer operations Pause-Printer, Resume-Printer, and Purge-Jobs (see Sections 4.2.7, 4.2.8, and 4.2.9), the requesting user is intended to be an Operator or Administrator of the Printer (see Section 1). Otherwise, the IPP Printer MUST reject the operation and return 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' as appropriate. For operations on Jobs, the requesting user is intended to be the Job owner or can be an Operator or Administrator of the Printer. The means for authorizing an Operator or Administrator of the Printer are not specified in this document. 9.6. Queries on Jobs Submitted Using Non-IPP Protocols If the device that an IPP Printer is representing is able to accept Jobs using other Job submission protocols in addition to IPP, such an implementation SHOULD at least allow such "foreign" Jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as 'unknown'. Such an implementation MAY support all of the same IPP Job attributes as for IPP Jobs. The IPP object returns the 'unknown' out-of-band value for any requested attribute of a foreign Job that is supported for IPP Jobs but not for foreign Jobs. Sweet & McDonald Standards Track [Page 186] RFC 8011 IPP/1.1: Model and Semantics January 2017 IPP Printers SHOULD also generate "job-id" and "job-uri" values for such foreign Jobs, if possible, so that they can be targets of other IPP operations, such as Get-Job-Attributes and Cancel-Job. Such an implementation also needs to deal with the problem of authentication of such foreign Jobs. One approach would be to treat all such foreign Jobs as belonging to users other than the user of the IPP Client. Another approach would be for the foreign Job to belong to 'anonymous' -- then only authenticated Operators or Administrators of the IPP Printer could query the foreign Jobs with an IPP request. Alternatively, if the security policy is to allow users to query other users' Jobs, then the foreign Jobs would also be visible to an End User IPP Client using Get-Jobs and Get-Job-Attributes. 10. Changes since RFC 2911 The following changes have been made since RFC 2911: o Errata ID 364: Fixed range of "redirection" status-code values (to 0x03xx). o Errata ID 694: Fixed range of vendor status-code values (0x0n80 to 0x0nff). o Errata ID 3072: Reworded multiple-document-handling definition, since it also applies to Jobs with a single Document and is the only interoperable way to request uncollated copies. o Errata ID 3365: Fixed bad 'nameWithLanguage' maximum length by referencing the 'nameWithoutLanguage' section (i.e., Section 5.1.3.1). o Errata ID 4173: Fixed range of vendor operation codes (0x4000 to 0x7fff). o Updated obsoleted RFC references. o Changed the IPP/1.1 Implementor's Guide reference to RFC 3196. o Updated Create-Job, Send-Document, and Send-URI to RECOMMENDED. o Incorporated 'collection' attribute content from RFC 3382. o Obsoleted all attributes and values defined in RFC 3381, as they do not interact well with the "finishings" attribute and have never been widely implemented. o Deprecated the Purge-Jobs and Restart-Job operations, which destroy accounting information. Sweet & McDonald Standards Track [Page 187] RFC 8011 IPP/1.1: Model and Semantics January 2017 o Dropped type3 registration procedures. o Changed the vendor attribute and keyword naming recommendations to use SMI Private Enterprise Numbers ("smiNNN-foo") instead of domain names. o Split READ-ONLY Job Description and Printer Description attributes into Job Status and Printer Status attributes to match the current IANA IPP registry organization. o Referenced all IETF and PWG IPP standards. o Updated OPTIONAL operations, attributes, and values to RECOMMENDED for consistency with IPP 2.0, IPP Everywhere, and the IPP Implementor's Guide v2.0. o Removed the appendix on media names. Readers are directed to "PWG Media Standardized Names 2.0 (MSN2)" [PWG5101.1]. 11. References 11.1. Normative References [ASME-Y14.1M] ASME Y14.1M-2012, "Metric Drawing Sheet Size and Format", March 2013. [ISO10175] ISO/IEC 10175, "Information technology -- Text and office systems -- Document Printing Application (DPA) -- Part 1: Abstract service definition and procedures", September 1996. [ISO10646] ISO/IEC 10646:2014, JTC1/SC2, "Information technology -- Universal Coded Character Set (UCS)", September 2014. [ISO8859-1] ISO/IEC 8859-1:1998, "Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", April 1998. [PWG5100.1] Sweet, M., "IPP Finishings 2.0 (FIN)", December 2014, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippfinishings20-20141219-5100.1.pdf>. Sweet & McDonald Standards Track [Page 188] RFC 8011 IPP/1.1: Model and Semantics January 2017 [PWG5100.11] Hastings, T. and D. Fullman, "Internet Printing Protocol (IPP): Job and Printer Extensions -- Set 2 (JPS2)", October 2010, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippjobprinterext10-20101030-5100.11.pdf>. [PWG5100.12] Sweet, M. and I. McDonald, "IPP Version 2.0, 2.1, and 2.2", October 2015, <http://ftp.pwg.org/pub/pwg/standards/ std-ipp20-20151030-5100.12.pdf>. [PWG5100.13] Sweet, M., McDonald, I., and P. Zehler, "IPP: Job and Printer Extensions -- Set 3 (JPS3)", July 2012, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippjobprinterext3v10-20120727-5100.13.pdf>. [PWG5100.14] Sweet, M., McDonald, I., Mitchell, A., and J. Hutchings, "IPP Everywhere", January 2013, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippeve10-20130128-5100.14.pdf>. [PWG5100.15] Sweet, M., "IPP FaxOut Service", June 2014, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippfaxout10-20140618-5100.15.pdf>. [PWG5100.16] Sweet, M., "IPP Transaction-Based Printing Extensions", November 2013, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ipptrans10-20131108-5100.16.pdf>. [PWG5100.17] Zehler, P. and M. Sweet, "IPP Scan Service (SCAN)", September 2014, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippscan10-20140918-5100.17.pdf>. [PWG5100.18] Sweet, M. and I. McDonald, "IPP Shared Infrastructure Extensions (INFRA)", June 2015, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippinfra10-20150619-5100.18.pdf>. [PWG5100.19] Kennedy, S., "IPP Implementor's Guide v2.0 (IG)", August 2015, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippig20-20150821-5100.19.pdf>. Sweet & McDonald Standards Track [Page 189] RFC 8011 IPP/1.1: Model and Semantics January 2017 [PWG5100.2] Hastings, T. and R. Bergman, "Internet Printing Protocol (IPP): "output-bin" attribute extension", February 2001, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippoutputbin10-20010207-5100.2.pdf>. [PWG5100.3] Ocke, K. and T. Hastings, "Internet Printing Protocol (IPP): Production Printing Attributes -- Set1", February 2001, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippprodprint10-20010212-5100.3.pdf>. [PWG5100.5] Carney, D., Hastings, T., and P. Zehler, "Standard for The Internet Printing Protocol (IPP): Document Object", October 2003, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippdocobject10-20031031-5100.5.pdf>. [PWG5100.6] Zehler, P., Herriot, R., and K. Ocke, "Standard for The Internet Printing Protocol (IPP): Page Overrides", October 2003, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ipppageoverride10-20031031-5100.6.pdf>. [PWG5100.7] Hastings, T. and P. Zehler, "Standard for The Internet Printing Protocol (IPP): Job Extensions", October 2003, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippjobext10-20031031-5100.7.pdf>. [PWG5100.8] Carney, D. and H. Lewis, "Standard for Internet Printing Protocol (IPP): "-actual" attributes", March 2003, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippactuals10-20030313-5100.8.pdf>. [PWG5100.9] McDonald, I. and C. Whittle, "Internet Printing Protocol (IPP): Printer State Extensions v1.0", July 2009, <http://ftp.pwg.org/pub/pwg/candidates/ cs-ippstate10-20090731-5100.9.pdf>. [PWG5101.1] Sweet, M., Bergman, R., and T. Hastings, "PWG Media Standardized Names 2.0 (MSN2)", March 2013, <http://ftp.pwg.org/pub/pwg/candidates/ cs-pwgmsn20-20130328-5101.1.pdf>. Sweet & McDonald Standards Track [Page 190] RFC 8011 IPP/1.1: Model and Semantics January 2017 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, <http://www.rfc-editor.org/info/rfc1951>. [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <http://www.rfc-editor.org/info/rfc1952>. [RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977, DOI 10.17487/RFC1977, August 1996, <http://www.rfc-editor.org/info/rfc1977>. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide", RFC 3196, DOI 10.17487/RFC3196, November 2001, <http://www.rfc-editor.org/info/rfc3196>. [RFC3380] Hastings, T., Herriot, R., Kugler, C., and H. Lewis, "Internet Printing Protocol (IPP): Job and Printer Set Operations", RFC 3380, DOI 10.17487/RFC3380, September 2002, <http://www.rfc-editor.org/info/rfc3380>. Sweet & McDonald Standards Track [Page 191] RFC 8011 IPP/1.1: Model and Semantics January 2017 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing Protocol/1.1: IPP URL Scheme", RFC 3510, DOI 10.17487/RFC3510, April 2003, <http://www.rfc-editor.org/info/rfc3510>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2", RFC 3805, DOI 10.17487/RFC3805, June 2004, <http://www.rfc-editor.org/info/rfc3805>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", RFC 3995, DOI 10.17487/RFC3995, March 2005, <http://www.rfc-editor.org/info/rfc3995>. [RFC3996] Herriot, R., Hastings, T., and H. Lewis, "Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications", RFC 3996, DOI 10.17487/RFC3996, March 2005, <http://www.rfc-editor.org/info/rfc3996>. [RFC3998] Kugler, C., Lewis, H., and T. Hastings, Ed., "Internet Printing Protocol (IPP): Job and Printer Administrative Operations", RFC 3998, DOI 10.17487/RFC3998, March 2005, <http://www.rfc-editor.org/info/rfc3998>. [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, DOI 10.17487/RFC5051, October 2007, <http://www.rfc-editor.org/info/rfc5051>. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. Sweet & McDonald Standards Track [Page 192] RFC 8011 IPP/1.1: Model and Semantics January 2017 [RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>. [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>. [RFC7472] McDonald, I. and M. Sweet, "Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme", RFC 7472, DOI 10.17487/RFC7472, March 2015, <http://www.rfc-editor.org/info/rfc7472>. [RFC7612] Fleming, P. and I. McDonald, "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", RFC 7612, DOI 10.17487/RFC7612, June 2015, <http://www.rfc-editor.org/info/rfc7612>. [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>. [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <http://www.rfc-editor.org/info/rfc7617>. [RFC8010] Sweet, M. and I. McDonald, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 8010, DOI 10.17487/RFC8010, January 2017, <http://www.rfc-editor.org/info/rfc8010>. Sweet & McDonald Standards Track [Page 193] RFC 8011 IPP/1.1: Model and Semantics January 2017 11.2. Informative References [HTPP] Barnett, J., Carter, K., and R. deBry, "Internet Print Protocol Proposal: HTPP -- Hypertext Print Protocol (HTPP/1.0 Initial Draft)", October 1996, <ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/ overview.ps.gz>. [IANA-CS] IANA, "Registry of Coded Character Sets", <http://www.iana.org/assignments/character-sets/>. [IANA-MT] IANA, "Media Types", <http://www.iana.org/assignments/media-types/>. [IANA-PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers/>. [ISO32000] "Document management -- Portable document format -- Part 1: PDF 1.7", July 2008, <http://www.adobe.com/ devnet/acrobat/pdfs/PDF32000_2008.pdf>. [LDPA] Isaacson, S., Taylor, D., MacKay, M., Zehler, P., Hastings, T., and C. Manros, "LDPA - Lightweight Document Printing Application", Proposed Internet-Draft, October 1996, <ftp://ftp.pwg.org/pub/pwg/ipp/ historic/ldpa/ldpa8.pdf.gz>. [P1387.4] Kirk, M., "POSIX Systems Administration - Part 4: Printing Interfaces, POSIX 1387.4 D8", 1998. [PSIS] Herriot, R., Ed., "X/Open: A Printing System Interoperability Specification (PSIS)", August 1995. [PWG-IPP-WG] IEEE-ISTO Printer Working Group, "Internet Printing Protocol Workgroup", <http://www.pwg.org/ipp>. [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <http://www.rfc-editor.org/info/rfc959>. [RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, DOI 10.17487/RFC1179, August 1990, <http://www.rfc-editor.org/info/rfc1179>. Sweet & McDonald Standards Track [Page 194] RFC 8011 IPP/1.1: Model and Semantics January 2017 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, December 1994, <http://www.rfc-editor.org/info/rfc1738>. [RFC2565] Herriot, R., Ed., Butler, S., Moore, P., and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, DOI 10.17487/RFC2565, April 1999, <http://www.rfc-editor.org/info/rfc2565>. [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, DOI 10.17487/RFC2566, April 1999, <http://www.rfc-editor.org/info/rfc2566>. [RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol", RFC 2567, DOI 10.17487/RFC2567, April 1999, <http://www.rfc-editor.org/info/rfc2567>. [RFC2568] Zilles, S., "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", RFC 2568, DOI 10.17487/RFC2568, April 1999, <http://www.rfc-editor.org/info/rfc2568>. [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, DOI 10.17487/RFC2569, April 1999, <http://www.rfc-editor.org/info/rfc2569>. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, <http://www.rfc-editor.org/info/rfc2579>. [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <http://www.rfc-editor.org/info/rfc2978>. [RFC3239] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations", RFC 3239, DOI 10.17487/RFC3239, February 2002, <http://www.rfc-editor.org/info/rfc3239>. [RFC3997] Hastings, T., Ed., deBry, R., and H. Lewis, "Internet Printing Protocol (IPP): Requirements for IPP Notifications", RFC 3997, DOI 10.17487/RFC3997, March 2005, <http://www.rfc-editor.org/info/rfc3997>. Sweet & McDonald Standards Track [Page 195] RFC 8011 IPP/1.1: Model and Semantics January 2017 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <http://www.rfc-editor.org/info/rfc6068>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>. [SWP] Moore, P. and S. Butler, "Simple Web Printing (SWP/1.0)", May 1997, <ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ swp9705.pdf>. Sweet & McDonald Standards Track [Page 196] RFC 8011 IPP/1.1: Model and Semantics January 2017 Appendix A. Formats for IPP Registration Proposals In order to propose an IPP extension for registration, the proposer must submit an application to IANA by email to "iana@iana.org" or by filling out the appropriate form on the IANA web pages (http://www.iana.org). This section specifies the required information and the formats for proposing registrations of extensions to IPP as provided in Section 7 for: 1. attributes 2. type2 'keyword' attribute values 3. type2 'enum' attribute values 4. operations 5. status-code values A.1. Attribute Registration Type of registration: attribute Proposed keyword name of this attribute: Types of attributes (Document Description, Document Status, Document Template, Event Notifications, Job Description, Job Status, Job Template, Operation, Printer Description, Printer Status, Subscription Description, Subscription Status, Subscription Template): Operations to be used if the attribute is an operation attribute: Object (Document, Job, Printer, Subscription, etc. if bound to an object): Attribute syntax(es) (include '1setOf' and range; see Section 5.2): If attribute syntax is 'keyword' or 'enum', is it type1 or type2? If this is a Printer attribute, MAY the value returned depend on "document-format"? (See Section 7.2.) If this is a Job Template attribute, how does its specification depend on the value of the "multiple-document-handling" attribute? Sweet & McDonald Standards Track [Page 197] RFC 8011 IPP/1.1: Model and Semantics January 2017 Specification of this attribute (follow the style of Section 5.2): Name of proposer: Email address of proposer: Note: For attributes, the IPP Designated Expert will be the point of contact and change controller for the approved registration specification, if any maintenance of the registration specification is needed. A.2. type2 'keyword' Attribute Value Registration Type of registration: type2 keyword attribute value Name of attribute to which this keyword specification is to be added: Proposed keyword name of this 'keyword' value: Specification of this 'keyword' value (follow the style of Section 5.1.4): Name of proposer: Email address of proposer: Note: For type2 keywords, the Designated Expert will be the point of contact and change controller for the approved registration specification, if any maintenance of the registration specification is needed. A.3. type2 'enum' Attribute Value Registration Type of registration: type2 enum attribute value Name of attribute to which this enum specification is to be added: Keyword symbolic name of this enum value: Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA): Specification of this enum value (follow the style of Section 5.1.5): Name of proposer: Email address of proposer: Sweet & McDonald Standards Track [Page 198] RFC 8011 IPP/1.1: Model and Semantics January 2017 Note: For type2 enums, the Designated Expert will be the point of contact and change controller for the approved registration specification, if any maintenance of the registration specification is needed. A.4. Operation Registration Type of registration: operation Proposed name of this operation: Numeric "operation-id" value according to Section 5.4.15 (to be assigned by the IPP Designated Expert in consultation with IANA): Object Target (Document, Job, Printer, Subscription, etc. that operation is upon): Specification of this operation (follow the style of Section 4): Name of proposer: Email address of proposer: Note: For operations, the IPP Designated Expert will be the point of contact and change controller for the approved registration specification, if any maintenance of the registration specification is needed. A.5. Status-Code Registration Type of registration: status-code Keyword symbolic name of this status-code value: Numeric value (to be assigned by the IPP Designated Expert in consultation with IANA): Operations that this status-code can be used with: Specification of this status-code (follow the style of Appendix B): Name of proposer: Email address of proposer: Sweet & McDonald Standards Track [Page 199] RFC 8011 IPP/1.1: Model and Semantics January 2017 Note: For status-code values, the Designated Expert will be the point of contact and change controller for the approved registration specification, if any maintenance of the registration specification is needed. Appendix B. Status-Code Values and Suggested Status-Code Messages This section defines status-code enum keywords and values that are used to provide semantic information on the results of an operation request. Each operation response MUST include a status-code. The response MAY also contain a status message that provides a short textual description of the status. The status-code is intended for use by automata, and the status message is intended for the human End User. The prefix of the status keyword defines the class of response as follows: "informational" - Request received, continuing process "successful" - The action was successfully received, understood, and accepted "redirection" - Further action is taken in order to complete the request "client-error" - The request contains bad syntax or cannot be fulfilled "server-error" - The IPP object failed to fulfill an apparently valid request As with type2 enums, IPP status-code values are extensible. Regardless of whether all status-code values are recognized, IPP Clients MUST understand the class of any status-code, as indicated by the prefix, and treat any unrecognized response as being equivalent to the first status-code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status-code of 'client-error-xxx-yyy' is received by the Client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 'client-error-bad-request' status-code. The name of the enum is the suggested status message for US English. See [PWG5100.19] for guidelines on presenting status messages to End Users. Sweet & McDonald Standards Track [Page 200] RFC 8011 IPP/1.1: Model and Semantics January 2017 The status-code values range from 0x0000 to 0x7fff. The value ranges for each status-code class are as follows: "successful" - 0x0000 to 0x00ff "informational" - 0x0100 to 0x01ff "redirection" - 0x0300 to 0x03ff "client-error" - 0x0400 to 0x04ff "server-error" - 0x0500 to 0x05ff The top half (128 values) of each range (0x0n80 to 0x0nff, for n = 0 to 5) is reserved for vendor use within each status-code class. Values 0x0600 to 0x7fff are reserved for future assignment by Standards Track documents and MUST NOT be used. B.1. Status-Code Values Each status-code is described below. Appendix B.2 contains a table that indicates which status-code values apply to which operations. The Implementor's Guides [RFC3196] [PWG5100.19] provide guidance for processing IPP attributes for all operations, including status-code values. B.1.1. Informational This class of status-code values indicates a provisional response and is to be used for informational purposes only. There are no values defined in this document for this class of status-code values. B.1.2. Successful Status-Code Values This class of status-code values indicates that the Client's request was successfully received, understood, and accepted. B.1.2.1. successful-ok (0x0000) The request has succeeded, and no request attributes were substituted or ignored. In the case of a response to a Job Creation request, the 'successful-ok' status-code indicates that the request was successfully received and validated, and that the Job object has been created; it does not indicate that the Job has been processed. The transition of the Job object into the 'completed' state is the only indicator that the Job has been printed. Sweet & McDonald Standards Track [Page 201] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.1.2.2. successful-ok-ignored-or-substituted-attributes (0x0001) The request has succeeded, but some supplied (1) attributes were ignored or (2) unsupported values were substituted with supported values or were ignored in order to perform the operation without rejecting it. Unsupported attributes, attribute syntaxes, or values MUST be returned in the Unsupported Attributes group of the response for all operations. There is an exception to this rule for the query operations Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes for the "requested-attributes" operation attribute only. When the supplied values of the "requested-attributes" operation attribute are requesting attributes that are not supported, the IPP object SHOULD return the "requested-attributes" operation attribute in the Unsupported Attributes group of the response (with the unsupported values only). See Sections 4.1.7 and 4.2.1.2. B.1.2.3. successful-ok-conflicting-attributes (0x0002) The request has succeeded, but some supplied attribute values conflicted with the values of other supplied attributes. Either (1) these conflicting values were substituted with (supported) values or (2) the attributes were removed in order to process the Job without rejecting it. Attributes or values that conflict with other attributes and have been substituted or ignored MUST be returned in the Unsupported Attributes group of the response for all operations as supplied by the Client. See Sections 4.1.7 and 4.2.1.2. B.1.3. Redirection Status-Code Values This class of status-code values indicates that further action needs to be taken to fulfill the request. There are no values defined in this document for this class of status-code values. B.1.4. Client Error Status-Code Values This class of status-code values is intended for cases in which the Client seems to have erred. The IPP object SHOULD return a message containing an explanation of the error situation and whether it is a temporary or permanent condition. Sweet & McDonald Standards Track [Page 202] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.1.4.1. client-error-bad-request (0x0400) The request could not be understood by the IPP object due to malformed syntax (such as the value of a fixed-length attribute whose length does not match the prescribed length for that attribute -- see the Implementor's Guides [RFC3196] [PWG5100.19]). The IPP application SHOULD NOT repeat the request without modifications. B.1.4.2. client-error-forbidden (0x0401) The IPP object understood the request but is refusing to fulfill it. Additional authentication information or authorization credentials will not help, and the request SHOULD NOT be repeated. This status-code is commonly used when the IPP object does not wish to reveal exactly why the request has been refused or when no other response is applicable. B.1.4.3. client-error-not-authenticated (0x0402) The request requires user authentication. The IPP Client can repeat the request with suitable authentication information. If the request already included authentication information, then this status-code indicates that authorization has been refused for those credentials. If this response contains the same challenge as the prior response and the user agent has already attempted authentication at least once, then the response message can contain relevant diagnostic information. This status-code reveals more information than 'client-error-forbidden'. B.1.4.4. client-error-not-authorized (0x0403) The requester is not authorized to perform the request. Additional authentication information or authorization credentials will not help, and the request SHOULD NOT be repeated. This status-code is used when the IPP object wishes to reveal that the authentication information is understandable; however, the requester is explicitly not authorized to perform the request. This status-code reveals more information than 'client-error-forbidden' and 'client-error-not-authenticated'. B.1.4.5. client-error-not-possible (0x0404) This status-code is used when the request is for something that cannot happen. For example, there might be a request to cancel a Job that has already been canceled or aborted by the system. The IPP Client SHOULD NOT repeat the request. Sweet & McDonald Standards Track [Page 203] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.1.4.6. client-error-timeout (0x0405) The Client did not produce a request within the time that the IPP object was prepared to wait. For example, a Client issued a Create-Job operation and then, after a long period of time, issued a Send-Document operation; this error status-code was returned in response to the Send-Document request (see Section 4.3.1). The IPP object might have been forced to clean up resources that had been held for the waiting additional Documents. The IPP object was forced to close the Job, since the Client took too long. The Client SHOULD NOT repeat the request without modifications. B.1.4.7. client-error-not-found (0x0406) The IPP object has not found anything matching the request URI. No indication is given of whether the condition is temporary or permanent. For example, a Client with an old reference to a Job (a URI) tries to cancel the Job; however, in the meantime the Job might have been completed and all record of it at the Printer has been deleted. This status-code, 'client-error-not-found', is returned indicating that the referenced Job cannot be found. This error status-code is also used when a Client supplies a URI as a reference to the Document data in either a Print-URI or Send-URI operation but the Document cannot be found. In practice, an IPP application should avoid a "not found" situation by first querying and presenting a list of valid Printer URIs and Job URIs to the End User. B.1.4.8. client-error-gone (0x0407) The requested object is no longer available, and no forwarding address is known. This condition should be considered permanent. Clients with link-editing capabilities should delete references to the request URI after user approval. If the IPP object does not know or has no facility to determine whether or not the condition is permanent, the status-code 'client-error-not-found' should be used instead. This response is primarily intended to assist the task of maintenance by notifying the recipient that the resource is intentionally unavailable and that the IPP object Administrator desires that remote links to that resource be removed. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the IPP object Administrator and/or Printer implementation. Sweet & McDonald Standards Track [Page 204] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.1.4.9. client-error-request-entity-too-large (0x0408) The IPP object is refusing to process a request because the request entity is larger than the IPP object is willing or able to process. An IPP Printer returns this status-code when it limits the size of Print Jobs and it receives a Print Job that exceeds that limit or when the attributes are so many that their encoding causes the request entity to exceed IPP object capacity. B.1.4.10. client-error-request-value-too-long (0x0409) The IPP object is refusing to service the request because one or more of the Client-supplied attributes have a variable-length value that is longer than the maximum length specified for that attribute. The IPP object might not have sufficient resources (memory, buffers, etc.) to process (even temporarily), interpret, and/or ignore a value larger than the maximum length. Another use of this error code is when the IPP object supports the processing of a large value that is less than the maximum length, but during the processing of the request as a whole, the object can pass the value onto some other system component that is not able to accept the large value. For more details, see the Implementor's Guides [RFC3196] [PWG5100.19]. Note: For attribute values that are URIs, this rare condition is only likely to occur when a Client has improperly submitted a request with long query information (e.g., an IPP application allows an End User to enter an invalid URI), when the Client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the IPP object is under attack by a Client attempting to exploit security holes present in some IPP objects using fixed-length buffers for reading or manipulating the request URI. B.1.4.11. client-error-document-format-not-supported (0x040a) The IPP object is refusing to service the request because the Document data is in a format, as specified in the "document-format" operation attribute, that is not supported by the Printer. This error is returned independent of the Client-supplied "ipp-attribute-fidelity" attribute. The Printer MUST return this status-code, even if there are other Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See Sections 4.1.6.1, 4.1.7, and 4.2.1.1. Sweet & McDonald Standards Track [Page 205] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.1.4.12. client-error-attributes-or-values-not-supported (0x040b) In a Job Creation request, if the Printer does not support one or more attributes, attribute syntaxes, or attribute values supplied in the request and the Client supplied the "ipp-attribute-fidelity" operation attribute with the 'true' value, the Printer MUST return this status-code. The Printer MUST also return in the Unsupported Attributes group all the attributes and/or values supplied by the Client that are not supported. See Section 4.1.7. Examples would be if the request indicates 'iso-a4' media but that media type is not supported by the Printer, or if the Client supplies a Job Template attribute and the attribute itself is not even supported by the Printer. If the "ipp-attribute-fidelity" attribute is 'false', the Printer MUST ignore or substitute values for unsupported Job Template attributes and values rather than reject the request and return this status-code. For any operation where a Client requests attributes (such as a Get-Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if the IPP object does not support one or more of the requested attributes, the IPP object simply ignores the unsupported requested attributes and processes the request as if they had not been supplied, rather than returning this status-code. In this case, the IPP object MUST return the 'successful-ok-ignored-or-substituted-attributes' status-code and SHOULD return the unsupported attributes as values of the "requested-attributes" operation attribute in the Unsupported Attributes group (see Appendix B.1.2.2). B.1.4.13. client-error-uri-scheme-not-supported (0x040c) The scheme of the Client-supplied URI in a Print-URI or a Send-URI operation is not supported. See Sections 4.1.6.1 and 4.1.7. B.1.4.14. client-error-charset-not-supported (0x040d) For any operation, if the IPP Printer does not support the charset supplied by the Client in the "attributes-charset" operation attribute, the Printer MUST reject the operation and return this status-code, and any 'text' or 'name' attributes using the 'utf-8' charset (Section 4.1.4.1). See Sections 4.1.6.1 and 4.1.7. Sweet & McDonald Standards Track [Page 206] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.1.4.15. client-error-conflicting-attributes (0x040e) The request is rejected because some attribute values conflicted with the values of other attributes that this document does not permit to be substituted or ignored. The Printer MUST also return in the Unsupported Attributes group the conflicting attributes supplied by the Client. See Sections 4.1.7 and 4.2.1.2. B.1.4.16. client-error-compression-not-supported (0x040f) The IPP object is refusing to service the request because the Document data, as specified in the "compression" operation attribute, is compressed in a way that is not supported by the Printer. This error is returned independent of the Client-supplied "ipp-attribute-fidelity" attribute. The Printer MUST return this status-code, even if there are other Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See Sections 4.1.6.1, 4.1.7, and 4.2.1.1. B.1.4.17. client-error-compression-error (0x0410) The IPP object is refusing to service the request because the Document data cannot be decompressed when using the algorithm specified by the "compression" operation attribute. This error is returned independent of the Client-supplied "ipp-attribute-fidelity" attribute. The Printer MUST return this status-code, even if there are Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See Sections 4.1.7 and 4.2.1.1. B.1.4.18. client-error-document-format-error (0x0411) The IPP object is refusing to service the request because the Printer encountered an error in the Document data while interpreting it. This error is returned independent of the Client-supplied "ipp-attribute-fidelity" attribute. The Printer MUST return this status-code, even if there are Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See Sections 4.1.7 and 4.2.1.1. B.1.4.19. client-error-document-access-error (0x0412) The IPP object is refusing to service the Print-URI or Send-URI request because the Printer encountered an access error while attempting to validate the accessibility of, or access to, the Document data specified in the "document-uri" operation attribute. The Printer MAY also return a specific Document access error code using the "document-access-error" operation attribute (see Sweet & McDonald Standards Track [Page 207] RFC 8011 IPP/1.1: Model and Semantics January 2017 Section 4.1.6.4). This error is returned independent of the Client-supplied "ipp-attribute-fidelity" attribute. The Printer MUST return this status-code, even if there are Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See Sections 4.1.6.1 and 4.1.7. B.1.5. Server Error Status-Code Values This class of status-code values indicates cases in which the IPP object is aware that it has erred or is incapable of performing the request. The IPP object SHOULD include a message containing an explanation of the error situation, and whether it is a temporary or permanent condition. B.1.5.1. server-error-internal-error (0x0500) The IPP object encountered an unexpected condition that prevented it from fulfilling the request. This error status-code differs from 'server-error-temporary-error' in that it implies a more permanent type of internal error. It also differs from 'server-error-device-error' in that it implies an unexpected condition (unlike a paper-jam or out-of-toner problem, which is undesirable but expected). This error status-code indicates that intervention by a knowledgeable human is probably required. B.1.5.2. server-error-operation-not-supported (0x0501) The IPP object does not support the functionality required to fulfill the request. This is the appropriate response when the IPP object does not recognize an operation or is not capable of supporting it. See Sections 4.1.6.1 and 4.1.7. B.1.5.3. server-error-service-unavailable (0x0502) The IPP object is currently unable to handle the request due to temporary overloading or due to maintenance of the IPP object. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay can be indicated in the message. If no delay is given, the IPP application should handle the response as it would for a 'server-error-temporary-error' response. If the condition is more permanent, the 'client-error-gone' or 'client-error-not-found' error status-code could be used. Sweet & McDonald Standards Track [Page 208] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.1.5.4. server-error-version-not-supported (0x0503) The IPP object does not support or refuses to support the IPP version that was supplied as the value of the "version-number" operation parameter in the request. The IPP object is indicating that it is unable or unwilling to complete the request using the same major and minor version number as supplied in the request, other than with this error message. The error response SHOULD contain a "status-message" attribute (see Section 4.1.6.2) describing why that version is not supported and what other versions are supported by that IPP object. See Sections 4.1.6.1, 4.1.7, and 4.1.8. The error response MUST identify in the "version-number" operation parameter the closest version number that the IPP object does support. For example, if a Client supplies version '1.0' and an IPP/1.1 object supports version '1.0', then it responds with version '1.0' in all responses to such a request. If the IPP/1.1 object does not support version '1.0', then it should accept the request and respond with version '1.1' or can reject the request and respond with this error code and version '1.1'. If a Client supplies version '1.2', the IPP/1.1 object should accept the request and return version '1.1' or can reject the request and respond with this error code and version '1.1'. See Sections 4.1.8 and 5.3.14. B.1.5.5. server-error-device-error (0x0504) A Printer error, such as a paper jam, occurs while the IPP object processes a Print or send operation. The response contains the true Job status (the values of the "job-state" and "job-state-reasons" attributes). Additional information can be returned in the OPTIONAL "job-state-message" attribute value or in the OPTIONAL status message that describes the error in more detail. This error status-code is only returned in situations where the Printer is unable to accept the Job Creation request because of such a device error. For example, if the Printer is unable to spool and can only accept one Job at a time, the reason it might reject a Job Creation request is that the Printer currently has a paper jam. In many cases, however, where the Printer can accept the request even though the Printer has some error condition, the 'successful-ok' status-code will be returned. In such a case, the Client would look at the returned Job object attributes or later query the Printer to determine its state and state reasons. Sweet & McDonald Standards Track [Page 209] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.1.5.6. server-error-temporary-error (0x0505) A temporary error such as a buffer-full write error, a memory overflow (i.e., the Document data exceeds the memory of the Printer), or a disk-full condition, occurs while the IPP Printer processes an operation. The Client MAY try the unmodified request again at some later point in time with an expectation that the temporary internal error condition has been cleared. Alternatively, as an implementation option, a Printer MAY delay the response until the temporary condition is cleared so that no error is returned. B.1.5.7. server-error-not-accepting-jobs (0x0506) This is a temporary error indicating that the Printer is not currently accepting Jobs because the Administrator has set the value of the Printer's "printer-is-accepting-jobs" attribute to 'false' (by means outside the scope of this IPP/1.1 document). B.1.5.8. server-error-busy (0x0507) This is a temporary error indicating that the Printer is too busy processing Jobs and/or other requests. The Client SHOULD try the unmodified request again at some later point in time with an expectation that the temporary busy condition will have been cleared. B.1.5.9. server-error-job-canceled (0x0508) This is an error indicating that the Job has been canceled by an Operator or the system while the Client was transmitting the data to the IPP Printer. If a "job-id" attribute and a "job-uri" attribute had been created, then they are returned in the Print-Job, Send-Document, or Send-URI response as usual; otherwise, no "job-id" and "job-uri" attributes are returned in the response. B.1.5.10. server-error-multiple-document-jobs-not-supported (0x0509) The IPP object does not support multiple Documents per Job, and a Client attempted to supply Document data with a second Send-Document or Send-URI operation. Sweet & McDonald Standards Track [Page 210] RFC 8011 IPP/1.1: Model and Semantics January 2017 B.2. Status-Code Values for IPP Operations PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document, SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job IPP Operations IPP Status Keyword PJ PU CJ SD SU V GA GJ C ------------------ -- -- -- -- -- - -- -- - successful-ok x x x x x x x x x successful-ok-ignored-or-substituted- x x x x x x x x x attributes successful-ok-conflicting-attributes x x x x x x x x x client-error-bad-request x x x x x x x x x client-error-forbidden x x x x x x x x x client-error-not-authenticated x x x x x x x x x client-error-not-authorized x x x x x x x x x client-error-not-possible x x x x x x x x x client-error-timeout x x client-error-not-found x x x x x x x x x client-error-gone x x x x x x x x x client-error-request-entity-too-large x x x x x x x x x client-error-request-value-too-long x x x x x x x x x client-error-document-format-not- x x x x x x supported client-error-attributes-or-values-not- x x x x x x x x x supported client-error-uri-scheme-not-supported x x client-error-charset-not-supported x x x x x x x x x client-error-conflicting-attributes x x x x x x x x x client-error-compression-not-supported x x x x x client-error-compression-error x x x x client-error-document-format-error x x x x client-error-document-access-error x x server-error-internal-error x x x x x x x x x server-error-operation-not-supported x x x x server-error-service-unavailable x x x x x x x x x server-error-version-not-supported x x x x x x x x x server-error-device-error x x x x x server-error-temporary-error x x x x x server-error-not-accepting-jobs x x x x server-error-busy x x x x x x x x x server-error-job-canceled x x x server-error-multiple-document-jobs- x x not-supported Sweet & McDonald Standards Track [Page 211] RFC 8011 IPP/1.1: Model and Semantics January 2017 HJ = Hold-Job, RJ = Release-Job, RS = Restart-Job, PP = Pause-Printer, RP = Resume-Printer, PJ = Purge-Jobs IPP Operations (cont.) IPP Status Keyword HJ RJ RS PP RP PJ ------------------ -- -- -- -- -- -- successful-ok x x x x x x successful-ok-ignored-or-substituted- x x x x x x attributes successful-ok-conflicting-attributes x x x x x x client-error-bad-request x x x x x x client-error-forbidden x x x x x x client-error-not-authenticated x x x x x x client-error-not-authorized x x x x x x client-error-not-possible x x x x x x client-error-timeout client-error-not-found x x x x x x client-error-gone x x x x x x client-error-request-entity-too-large x x x x x x client-error-request-value-too-long x x x x x x client-error-document-format-not- supported client-error-attributes-or-values-not- x x x x x x supported client-error-uri-scheme-not-supported client-error-charset-not-supported x x x x x x client-error-conflicting-attributes x x x x x x client-error-compression-not-supported client-error-compression-error client-error-document-format-error client-error-document-access-error server-error-internal-error x x x x x x server-error-operation-not-supported x x x x x x server-error-service-unavailable x x x x x x server-error-version-not-supported x x x x x x server-error-device-error server-error-temporary-error x x x x x x server-error-not-accepting-jobs server-error-busy x x x x x x server-error-job-canceled server-error-multiple-document-jobs- not-supported Sweet & McDonald Standards Track [Page 212] RFC 8011 IPP/1.1: Model and Semantics January 2017 Appendix C. Processing IPP Attributes When submitting a Print Job to a Printer, the IPP Model allows a Client to supply operation and Job Template attributes along with the Document data. These Job Template attributes in the Job Creation request affect the rendering, production, and finishing of the Documents in the Job. Similar types of instructions can also be contained in the Document data itself. In addition, the Printer has a set of attributes that describe what rendering and finishing processes are supported by that Printer. This model, which allows for flexibility and power, also introduces the potential that Client-supplied attributes can conflict with either: o what the implementation is capable of realizing (i.e., what the Printer supports), or o the instructions embedded within the Document data itself. The following sections describe how these two types of conflicts are handled in the IPP Model. C.1. Fidelity If there is a conflict between what the Client requests and what a Printer supports, the Client can request one of two possible conflict-handling mechanisms: 1) either reject the Job, since the Job cannot be processed exactly as specified, or 2) allow the Printer to make any changes necessary to proceed with processing the Job the best it can. In the first case, the Client is indicating the following to the Printer: "Print the Job exactly as specified with no exceptions, and if that can't be done, don't even bother printing the Job at all." In the second case, the Client is indicating the following to the Printer: "It is more important to make sure the Job is printed rather than be processed exactly as specified; just make sure the Job is printed even if some Client-supplied attributes need to be changed or ignored." The IPP Model accounts for this situation by introducing an "ipp-attribute-fidelity" attribute. Sweet & McDonald Standards Track [Page 213] RFC 8011 IPP/1.1: Model and Semantics January 2017 In a Job Creation request, "ipp-attribute-fidelity" is a boolean operation attribute that MAY be supplied by the Client. The value 'true' indicates that total fidelity to Client-supplied Job Template attributes and values is required. The Client is requesting that the Job be printed exactly as specified, and if that is not possible, then the Job MUST be rejected rather than processed incorrectly. The value 'false' indicates that a reasonable attempt to print the Job is acceptable. If a Printer does not support some of the Client-supplied Job Template attributes or values, the Printer MUST ignore or replace them with supported values. The Printer can choose to substitute the default value associated with that attribute or use some other supported value that is similar to the unsupported requested value. For example, if a Client supplies a "media" value of 'na_letter_8.5x11in', the Printer can choose to substitute 'iso_a4_210x297mm' rather than a default value of 'na_personal_3.625x6.5in'. If the Client does not supply the "ipp-attribute-fidelity" attribute, the Printer assumes a value of 'false'. Each Printer implementation MUST support both types of "fidelity" printing (that is, whether the Client supplies a value of 'true' or 'false'): o If the Client supplies 'false' or does not supply the attribute, the Printer MUST always accept the request by ignoring unsupported Job Template attributes and by substituting unsupported values of supported Job Template attributes with supported values. o If the Client supplies 'true', the Printer MUST reject the request if the Client supplies unsupported Job Template attributes. Since a Client can always query a Printer to find out exactly what is and is not supported, "ipp-attribute-fidelity" set to 'false' is useful when: 1) The End User uses a command line interface to request attributes that might not be supported. 2) In a GUI context, if the End User expects the Job might be moved to another Printer and prefers a suboptimal result to nothing at all. 3) The End User just wants something reasonable in lieu of nothing at all. Sweet & McDonald Standards Track [Page 214] RFC 8011 IPP/1.1: Model and Semantics January 2017 C.2. Page Description Language (PDL) Override If there is a conflict between the value of an IPP Job Template attribute and a corresponding instruction in the Document data, the value of the IPP attribute SHOULD take precedence over the Document instruction. Consider the case where a previously formatted file of Document data is sent to an IPP Printer. In this case, if the Client supplies any attributes at Job submission time, the Client desires that those attributes override the embedded instructions. Consider the case where a previously formatted Document has embedded in it commands to load 'iso-a4' media. However, the Document is passed to an End User that only has access to a Printer with 'na-letter' media loaded. That End User most likely wants to submit that Document to an IPP Printer with the "media" Job Template attribute set to 'na-letter'. Attributes supplied at Job submission time should take precedence over the embedded PDL instructions. However, until companies that supply Document data interpreters allow a way for external IPP attributes to take precedence over embedded Job production instructions, a Printer might not be able to support the semantics that IPP attributes override the embedded instructions. The IPP Model accounts for this situation by introducing a "pdl-override-supported" attribute that describes the Printer's capabilities to override instructions embedded in the PDL data stream. The value of the "pdl-override-supported" attribute is configured by means outside the scope of this IPP/1.1 document. This REQUIRED Printer attribute takes on the following values: o 'attempted': This value indicates that the Printer attempts to make the IPP attribute values take precedence over embedded instructions in the Document data; however, there is no guarantee. o 'not-attempted': This value indicates that the Printer makes no attempt to make the IPP attribute values take precedence over embedded instructions in the Document data. At Job processing time, an implementation that supports the value of 'attempted' might do one of several different actions: 1) Generate an Output-Device-specific command sequence to realize the feature represented by the IPP attribute value. 2) Parse the Document data itself and replace the conflicting embedded instruction with a new embedded instruction that matches the intent of the IPP attribute value. Sweet & McDonald Standards Track [Page 215] RFC 8011 IPP/1.1: Model and Semantics January 2017 3) Indicate to the Printer that external supplied attributes take precedence over embedded instructions and then pass the external IPP attribute values to the Document data interpreter. 4) Anything else that allows for the semantics that IPP attributes override embedded Document data instructions. Since 'attempted' does not offer any type of guarantee, even though a given Printer might not do a very "good" job of attempting to ensure that IPP attributes take a higher precedence over instructions embedded in the Document data, it would still be a conforming implementation. At Job processing time, an implementation that supports the value of 'not-attempted' might do one of the following actions: 1) Simply prepend the Document data with the PDL instruction that corresponds to the Client-supplied PDL attribute, such that if the Document data also has the same PDL instruction it will override what the Printer prepended. In other words, this implementation is using the same implementation semantics for the Client-supplied IPP attributes as for the Printer defaults. 2) Parse the Document data and replace the conflicting embedded instruction with a new embedded instruction that approximates, but does not match, the semantic intent of the IPP attribute value. Note: The "ipp-attribute-fidelity" attribute applies to the Printer's ability to either accept or reject other unsupported Job Template attributes. In other words, if "ipp-attribute-fidelity" is set to 'true', a Job is accepted if and only if the Client-supplied Job Template attributes and values are supported by the Printer. Whether these attributes actually affect the processing of the Job when the Document data contains embedded instructions depends on the ability of the Printer to override the instructions embedded in the Document data with the semantics of the IPP attributes. If the Document data attributes can be overridden ("pdl-override-supported" set to 'attempted'), the Printer makes an attempt to use the IPP attributes when processing the Job. If the Document data attributes cannot be overridden ("pdl-override-supported" set to 'not-attempted'), the Printer makes no attempt to override the embedded Document data instructions with the IPP attributes when processing the Job, and hence, the IPP attributes can fail to affect the Job processing and output when the corresponding instruction is embedded in the Document data. Sweet & McDonald Standards Track [Page 216] RFC 8011 IPP/1.1: Model and Semantics January 2017 C.3. Using Job Template Attributes during Document Processing The Printer uses some of the Job's Job Template attributes during the processing of the Document data associated with that Job. These include, but are not limited to, "orientation-requested", "number-up", "sides", "media", and "copies". The processing of each Document in a Job object MUST follow the steps below. These steps are intended only to identify when and how attributes are to be used in processing Document data; any alternative steps that accomplish the same effect can be used to implement this specification document. 1. Using the Client-supplied "document-format" attribute or some form of Document format detection algorithm (if the value of "document-format" is not specific enough), determine whether the Document data has already been formatted for printing. If the Document data has been formatted, then go to step 2. Otherwise, the Document data MUST be formatted. The formatting detection algorithm is implementation defined and is not specified by this document. The formatting of the Document data uses the "orientation-requested" attribute to determine how the formatted print data should be placed on an Input Page; see Section 5.2.10 for details. 2. The Document data is a set of Input Pages in a known media type. The "page-ranges" attribute is used to select, as specified in Section 5.2.7, a sub-sequence of the pages in the print-stream that are to be processed and imaged. 3. The input for this step is a sequence of Input Pages. This step is controlled by the "number-up" attribute. If the value of "number-up" is N, then during the processing of the Input Pages each N Input Pages are positioned, as specified in Section 5.2.9, to create a single Impression. If a given Document does not have N more Input Pages, then the completion of the Impression is controlled by the "multiple-document-handling" attribute as described in Section 5.2.4; when the value of this attribute is 'single-document' or 'single-document-new-sheet', the Input Pages of Document data from subsequent Documents are used to complete the Impression. The size (scaling), position (translation), and rotation of the Input Pages on the Impression are implementation defined. Note that during this process the Input Pages can be rendered to a form suitable for placing on the Impression; this rendering is controlled by the values of the "printer-resolution" and "print-quality" attributes as described in Sections 5.2.12 and 5.2.13. In the case where N = 1, the Impression is nearly the same as the Input Page; the differences Sweet & McDonald Standards Track [Page 217] RFC 8011 IPP/1.1: Model and Semantics January 2017 would only be in the size, position, and rotation of the Input Page and/or any decoration, such as a frame for the page, that is added by the implementation. 1. The collection of Impressions is placed, in sequence, onto sides of the Media Sheets. This placement is controlled by the "sides" attribute and the orientation of the Input Page, as described in Section 5.2.8. The orientation of the Input Pages affects the orientation of the Impression; for example, if "number-up" equals 2, then, typically, two portrait Input Pages become one landscape Impression. Note that the placement of Impressions onto Media Sheets is also controlled by the "multiple-document-handling" attribute as described in Section 5.2.4. 2. The "copies" and "multiple-document-handling" attributes are used to determine how many copies of each Media Sheet are printed and in what order. See Sections 5.2.4 and 5.2.5 for details. 3. When the correct number of copies are created, the Media Sheets are finished according to the values of the "finishings" attribute as described in Section 5.2.6. Note that sometimes finishing processes can require manual intervention to perform the finishing processes on the copies, especially uncollated copies. This document allows any or all of the processing steps to be performed automatically or manually, at the discretion of the Printer. Appendix D. Generic Directory Schema This section defines a generic schema for an entry in a directory service. Implementations of this schema are defined by "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services" [RFC7612] and "IPP Everywhere" [PWG5100.14]. A directory service is a means by which service users can locate service providers. In IPP environments, this means that IPP Printers can be registered (either automatically or with the help of an Administrator) as entries of type Printer in the directory using an implementation-specific mechanism such as entry attributes, entry type fields, specific branches, etc. Directory Clients can search or browse for entries of type Printer. Clients use the directory service to find entries based on naming, organizational contexts, or filtered searches on attribute values of entries. For example, a Client can find all Printers in the "Local Department" context. Authentication and authorization are also often part of a directory service so that an Administrator can place limits on End Users so that they are only allowed to find entries to which they have certain access rights. IPP itself does not require any specific directory service protocol or provider. Sweet & McDonald Standards Track [Page 218] RFC 8011 IPP/1.1: Model and Semantics January 2017 Note: Some directory implementations allow for the notion of "aliasing". That is, one directory entry object can appear as multiple directory entry objects with different names for each object. In each case, each alias refers to the same directory entry object, which refers to a single IPP Printer. The generic schema is a subset of IPP Printer Job Template and Printer Description attributes (Sections 5.2 and 5.4). These attributes are identified as either RECOMMENDED or OPTIONAL for the directory entry itself. This conformance labeling is NOT the same conformance labeling applied to the attributes of IPP Printer objects. The conformance labeling in this appendix is intended to apply to directory templates and to IPP Printer implementations that subscribe by adding one or more entries to a directory. RECOMMENDED attributes SHOULD be associated with each directory entry. OPTIONAL attributes MAY be associated with the directory entry (if known or supported). In addition, all directory entry attributes SHOULD reflect the current attribute values for the corresponding Printer. As much as possible, the names of attributes in directory schema and entries SHOULD be the same as the IPP Printer attribute names as shown. In order to bridge between the directory service and the IPP Printer, one of the RECOMMENDED directory entry attributes is the Printer's "printer-uri-supported" attribute. The directory Client queries the "printer-uri-supported" attribute (or its equivalent) in the directory entry, and then the IPP Client addresses the IPP Printer using one of its URIs. The "uri-security-supported" attribute identifies the protocol (if any) used to secure a channel. The attributes in Table 23 define the generic schema for directory entries of type Printer. +------------------------------------+-------------+----------------+ | Attribute | Conformance | Section | +------------------------------------+-------------+----------------+ | charset-supported | OPTIONAL | Section 5.4.18 | +------------------------------------+-------------+----------------+ | color-supported | RECOMMENDED | Section 5.4.26 | +------------------------------------+-------------+----------------+ | compression-supported | RECOMMENDED | Section 5.4.32 | +------------------------------------+-------------+----------------+ | document-format-supported | RECOMMENDED | Section 5.4.22 | +------------------------------------+-------------+----------------+ | finishings-supported | OPTIONAL | Section 5.2.6 | Sweet & McDonald Standards Track [Page 219] RFC 8011 IPP/1.1: Model and Semantics January 2017 +------------------------------------+-------------+----------------+ | generated-natural-language- | OPTIONAL | Section 5.4.20 | | supported | | | +------------------------------------+-------------+----------------+ | ipp-versions-supported | RECOMMENDED | Section 5.4.14 | +------------------------------------+-------------+----------------+ | media-supported | RECOMMENDED | Section 5.2.11 | +------------------------------------+-------------+----------------+ | multiple-document-jobs-supported | OPTIONAL | Section 5.4.16 | +------------------------------------+-------------+----------------+ | number-up-supported | OPTIONAL | Section 5.2.9 | +------------------------------------+-------------+----------------+ | pages-per-minute-color | OPTIONAL | Section 5.4.37 | +------------------------------------+-------------+----------------+ | pages-per-minute | OPTIONAL | Section 5.4.36 | +------------------------------------+-------------+----------------+ | print-quality-supported | OPTIONAL | Section 5.2.13 | +------------------------------------+-------------+----------------+ | printer-info | OPTIONAL | Section 5.4.6 | +------------------------------------+-------------+----------------+ | printer-location | RECOMMENDED | Section 5.4.5 | +------------------------------------+-------------+----------------+ | printer-make-and-model | RECOMMENDED | Section 5.4.9 | +------------------------------------+-------------+----------------+ | printer-more-info | OPTIONAL | Section 5.4.7 | +------------------------------------+-------------+----------------+ | printer-name | RECOMMENDED | Section 5.4.4 | +------------------------------------+-------------+----------------+ | printer-resolution-supported | OPTIONAL | Section 5.2.12 | +------------------------------------+-------------+----------------+ | printer-uri-supported | RECOMMENDED | Section 5.4.1 | +------------------------------------+-------------+----------------+ | sides-supported | RECOMMENDED | Section 5.2.8 | +------------------------------------+-------------+----------------+ | uri-authentication-supported | RECOMMENDED | Section 5.4.2 | +------------------------------------+-------------+----------------+ | uri-security-supported | RECOMMENDED | Section 5.4.3 | +------------------------------------+-------------+----------------+ Table 23: Attributes in Directory Entries Sweet & McDonald Standards Track [Page 220] RFC 8011 IPP/1.1: Model and Semantics January 2017 Acknowledgements The authors would like to acknowledge the following individuals for their contributions to the original IPP/1.1 specifications: Roger deBry, Tom Hastings (original RFC 2911 editor), Robert Herriot, Scott A. Isaacson, Kirk Ocke, Patrick Powell, and Peter Zehler Authors' Addresses Michael Sweet Apple Inc. 1 Infinite Loop MS 111-HOMC Cupertino, CA 95014 United States of America Email: msweet@apple.com Ira McDonald High North, Inc. PO Box 221 Grand Marais, MI 49839 United States of America Phone: +1 906-494-2434 Email: blueroofmusic@gmail.com Sweet & McDonald Standards Track [Page 221]