RFC 8011
Internet Printing Protocol/1.1: Model and Semantics
Pages: 221
Internet Standard: 92
→ Errata
Obsoletes: 2911 3381 3382
Internet Standard: 92
→ Errata
Obsoletes: 2911 3381 3382
Part 12 of 12 – Pages 200 to 221
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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
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.
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.
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.
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.
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
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.
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 |
+------------------------------------+-------------+----------------+ | 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
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 ZehlerAuthors' 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