2.2.2 Suggested Additional Processing Steps for Operations that Create/Validate Jobs and Add Documents This section in combination with the previous section recommends the processing steps for the Print-Job, Validate-Job, Print-URI, Create- Job, Send-Document, and Send-URI operations that IPP objects SHOULD use. These are the operations that create jobs, validate a Print-Job request, and add documents to a job. 2.2.2.1 Default "ipp-attribute-fidelity" if not supplied The Printer object checks to see if the client supplied an "ipp- attribute-fidelity" Operation attribute. If the attribute is not supplied by the client, the IPP object assumes that the value is 'false'. 2.2.2.2 Check that the Printer object is accepting jobs If the value of the Printer object's "printer-is-accepting-jobs" is 'false', the Printer object REJECTS the request and RETURNS the 'server-error-not-accepting-jobs' status code. 2.2.2.3 Validate the values of the Job Template attributes An IPP object validates the values of all Job Template attribute supplied by the client. The IPP object performs the analogous syntactic validation checks of each Job Template attribute value that it performs for Operation attributes (see Section 2.2.1.5.): a)that the length of each value is correct for the attribute syntax tag supplied by the client according to [RFC2566] Section 4.1. b)that the attribute syntax tag is correct for that attribute according to [RFC2566] Sections 4.2 to 4.4.
c)that multiple values are supplied only for multi-valued
attributes, i.e., that are 1setOf X according to [RFC2566]
Sections 4.2 to 4.4.
As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP
object REJECTS the request and RETURNS the 'client-error-bad-request'
or 'client-error-request-value-too-long' status code as appropriate,
independent of the value of the "ipp-attribute-fidelity". Since such
an error is most likely to be an error detected by a client
developer, rather than by an end-user, the IPP object NEED NOT return
an indication of which attribute had the error in either the
Unsupported Attributes Group or the Status Message. The description
for each of these syntactic checks is explicitly expressed in the
first IF statement in the following table.
Each Job Template attribute MUST occur no more than once. If an IPP
Printer receives a create request with multiple occurrences of a Job
Template attribute, it MAY:
1.reject the operation and return the 'client-error-bad syntax'
error status code
2.accept the operation and use the first occurrence of the
attribute
3.accept the operation and use the last occurrence of the
attribute
depending on implementation. Therefore, clients MUST NOT supply
multiple occurrences of the same Job Template attribute in the Job
Attributes group in the request.
2.2.3 Algorithm for job validation
The process of validating a Job-Template attribute "xxx" against a
Printer attribute "xxx-supported" can use the following validation
algorithm (see section 3.2.1.2 in [RFC2566]).
To validate the value U of Job-Template attribute "xxx" against the
value V of Printer "xxx-supported", perform the following algorithm:
1.If U is multi-valued, validate each value X of U by performing
the algorithm in Table 3 with each value X. Each validation is
separate from the standpoint of returning unsupported values.
Example: If U is "finishings" that the client supplies with
'staple', 'bind' values, then X takes on the successive values:
'staple', then 'bind'
2.If V is multi-valued, validate X against each Z of V by
performing the algorithm in Table 3 with each value Z. If a
value Z validates, the validation for the attribute value X
succeeds. If it fails, the algorithm is applied to the next
value Z of V. If there are no more values Z of V, validation
fails.
Example: If V is "sides-supported" with values: 'one-sided',
'two-sided-long', and 'two-sided-short', then Z takes on the
successive values: 'one-sided', 'two-sided-long', and
'two-sided-short'. If the client supplies "sides" with 'two-
sided-long', the first comparison fails ('one-sided' is not
equal to 'two-sided-long'), the second comparison succeeds
('two-sided-long' is equal to 'two-sided-long"), and the third
comparison ('two-sided-short' with 'two-sided-long') is not even
performed.
3.If both U and V are single-valued, let X be U and Z be V and use
the validation rules in Table 3.
Table 3 - Rules for validating single values X against Z
attribute attribute validated if:
syntax of X syntax of Z
integer rangeOfInteger X is within the range of
Z
uri uriScheme the uri scheme in X is
equal to Z
any boolean the value of Z is TRUE
any any X and Z are of the same
type and are equal.
If the value of the Printer object's "xxx-supported" attribute is '
no-value' (because the system administrator hasn't configured a
value), the check always fails. If the check fails, the IPP object
copies the attribute to the Unsupported Attributes response group
with its unsupported value. If the attribute contains more than one
value, each value is checked and each unsupported value is separately
copied, while supported values are not copied. If an IPP object
doesn't recognize/support a Job Template attribute, i.e., there is no
corresponding Printer object "xxx-supported" attribute, the IPP
object treats the attribute as an unknown or unsupported attribute
(see the last row in the table below).
If some Job Template attributes are supported for some document formats and not for others or the values are different for different document formats, the IPP object SHOULD take that into account in this validation using the value of the "document-format" supplied by the client (or defaulted to the value of the Printer's "document- format-default" attribute, if not supplied by the client). For example, if "number-up" is supported for the 'text/plain' document format, but not for the 'application/postscript' document format, the check SHOULD (though it NEED NOT) depend on the value of the "document-format" operation attribute. See "document-format" in [RFC2566] section 3.2.1.1 and 3.2.5.1. Note: whether the request is accepted or rejected is determined by the value of the "ipp-attribute-fidelity" attribute in a subsequent step, so that all Job Template attribute supplied are examined and all unsupported attributes and/or values are copied to the Unsupported Attributes response group. job-priority (integer(1:100)) IF NOT a single 'integer' value with a length equal to 4 octets, REJECT/RETURN 'client-error-bad-request'. IF NOT supplied by the client, use the value of the Printer object's "job-priority-default" attribute at job submission time. IF NOT in the range 1 to 100, inclusive, copy the attribute and the unsupported value to the Unsupported Attributes response group. Map the value to the nearest supported value in the range 1:100 as specified by the number of discrete values indicated by the value of the Printer's "job-priority-supported" attribute. See the formula in [RFC2566] Section 4.2.1. job-hold-until (type3 keyword | name) IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- error-bad-request'. IF the value length is greater than 255 octets, REJECT/RETURN 'client-error-request-value-too-long'. IF NOT supplied by the client, use the value of the Printer object's "job-hold-until" attribute at job submission time. IF NOT in the Printer object's "job-hold-until-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group.
job-sheets (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "job-sheets-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
multiple-document-handling (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "multiple-document-handling-
supported" attribute, copy the attribute and the unsupported
value to the Unsupported Attributes response group.
copies (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in range of the Printer object's "copies-supported"
attribute copy the attribute and the unsupported value to the
Unsupported
Attributes response group.
finishings (1setOf type2 enum)
IF NOT an 'enum' value(s) each with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "finishings-supported" attribute,
copy the attribute and the unsupported value(s), but not any
supported values, to the Unsupported Attributes response group.
page-ranges (1setOf rangeOfInteger(1:MAX))
IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
octets, REJECT/RETURN 'client-error-bad-request'.
IF first value is greater than second value in any range, the
ranges are not in ascending order, or ranges overlap,
REJECT/RETURN 'client-error-bad-request'.
IF the value of the Printer object's "page-ranges-supported"
attribute is 'false', copy the attribute to the Unsupported
Attributes response group and set the value to the "out-of-
band" 'unsupported' value.
sides (type2 keyword)
IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "sides-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
number-up (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT a value or in the range of one of the values of the Printer
object's "number-up-supported" attribute, copy the attribute
and value to the Unsupported Attribute response group.
orientation-requested (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "orientation-requested-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
media (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF NOT in the Printer object's "media-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
printer-resolution (resolution)
IF NOT a single 'resolution' value with a length equal to 9
octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "printer-resolution-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
print-quality (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "print-quality-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
unknown or unsupported attribute (i.e., there is no corresponding
Printer object "xxx-supported" attribute)
IF the attribute syntax supplied by the client is supported but
the length is not legal for that attribute syntax,
REJECT/RETURN 'client-error-bad-request' if the length of the
attribute syntax is fixed or 'client-error-request-value-too-
long' if the length of the attribute syntax is variable.
ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of-
band" 'unsupported' value. Any remaining Job Template
Attributes are either unknown or unsupported Job Template
attributes and are validated algorithmically according to their
attribute syntax for proper length (see below).
If the attribute syntax is supported AND the length check
fails, the IPP object REJECTS the request and RETURNS the '
client-error-bad-request' if the length of the attribute syntax
is fixed or the 'client-error-request-value-too-long' status
code if the length of the attribute syntax is variable.
Otherwise, the IPP object copies the unsupported Job Template
attribute to the Unsupported Attributes response group and
changes the attribute value to the "out-of-band" 'unsupported'
value. The following table shows the length checks for all
attribute syntaxes. In the following table: "<=" means less
than or equal, "=" means equal to:
Name Octet length check for read-write attributes
----------- --------------------------------------------
'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
'textWithoutLanguage' <= 1023
'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63
'nameWithoutLanguage' <= 255
'keyword' <= 255
'enum' = 4
'uri' <= 1023
'uriScheme' <= 63
'charset' <= 63
'naturalLanguage' <= 63
'mimeMediaType' <= 255
'octetString' <= 1023 'boolean' = 1 'integer' = 4 'rangeOfInteger' = 8 'dateTime' = 11 'resolution' = 9 '1setOf X' 2.2.3.1 Check for conflicting Job Template attributes values Once all the Operation and Job Template attributes have been checked individually, the Printer object SHOULD check for any conflicting values among all the supported values supplied by the client. For example, a Printer object might be able to staple and to print on transparencies, however due to physical stapling constraints, the Printer object might not be able to staple transparencies. The IPP object copies the supported attributes and their conflicting attribute values to the Unsupported Attributes response group. The Printer object only copies over those attributes that the Printer object either ignores or substitutes in order to resolve the conflict, and it returns the original values which were supplied by the client. For example suppose the client supplies "finishings" equals 'staple' and "media" equals 'transparency', but the Printer object does not support stapling transparencies. If the Printer chooses to ignore the stapling request in order to resolve the conflict, the Printer objects returns "finishings" equal to 'staple' in the Unsupported Attributes response group. If any attributes are multi-valued, only the conflicting values of the attributes are copied. Note: The decisions made to resolve the conflict (if there is a choice) is implementation dependent. 2.2.3.2 Decide whether to REJECT the request If there were any unsupported Job Template attributes or unsupported/conflicting Job Template attribute values and the client supplied the "ipp-attribute-fidelity" attribute with the 'true' value, the Printer object REJECTS the request and return the status code: (1) 'client-error-conflicting-attributes' status code, if there were any conflicts between attributes supplied by the client. (2) 'client-error-attributes-or-values-not-supported' status code, otherwise.
Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors. 2.2.3.3 For the Validate-Job operation, RETURN one of the success status codes If the requested operation is the Validate-Job operation, the Printer object returns: (1) the "successful-ok" status code, if there are no unsupported or conflicting Job Template attributes or values. (2) the "successful-ok-conflicting-attributes, if there are any conflicting Job Template attribute or values. (3) the "successful-ok-ignored-or-substituted-attributes, if there are only unsupported Job Template attributes or values. Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors. 2.2.3.4 Create the Job object with attributes to support If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied by the client), the Printer object: (1) creates a Job object, assigns a unique value to the job's "job-uri" and "job-id" attributes, and initializes all of the job's other supported Job Description attributes. (2) removes all unsupported attributes from the Job object. (3) for each unsupported value, removes either the unsupported value or substitutes the unsupported attribute value with some supported value. If an attribute has no values after removing unsupported values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute). (4) for each conflicting value, removes either the conflicting value or substitutes the conflicting attribute value with some other supported value. If an attribute has no values after removing conflicting values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute).
If there were no attributes or values flagged as unsupported, or the value of 'ipp-attribute-fidelity" was 'false', the Printer object is able to accept the create request and create a new Job object. If the "ipp-attribute-fidelity" attribute is set to 'true', the Job Template attributes that populate the new Job object are necessarily all the Job Template attributes supplied in the create request. If the "ipp-attribute-fidelity" attribute is set to 'false', the Job Template attributes that populate the new Job object are all the client supplied Job Template attributes that are supported or that have value substitution. Thus, some of the requested Job Template attributes may not appear in the Job object because the Printer object did not support those attributes. The attributes that populate the Job object are persistently stored with the Job object for that Job. A Get-Job-Attributes operation on that Job object will return only those attributes that are persistently stored with the Job object. Note: All Job Template attributes that are persistently stored with the Job object are intended to be "override values"; that is, they that take precedence over whatever other embedded instructions might be in the document data itself. However, it is not possible for all Printer objects to realize the semantics of "override". End users may query the Printer's "pdl-override-supported" attribute to determine if the Printer either attempts or does not attempt to override document data instructions with IPP attributes. There are some cases, where a Printer supports a Job Template attribute and has an associated default value set for that attribute. In the case where a client does not supply the corresponding attribute, the Printer does not use its default values to populate Job attributes when creating the new Job object; only Job Template attributes actually in the create request are used to populate the Job object. The Printer's default values are only used later at Job processing time if no other IPP attribute or instruction embedded in the document data is present. Note: If the default values associated with Job Template attributes that the client did not supply were to be used to populate the Job object, then these values would become "override values" rather than defaults. If the Printer supports the 'attempted' value of the "pdl-override-supported" attribute, then these override values could replace values specified within the document data. This is not the intent of the default value mechanism. A default value for an attribute is used only if the create request did not specify that attribute (or it was ignored when allowed by "ipp-attribute-fidelity" being 'false') and no value was provided within the content of the document data.
If the client does not supply a value for some Job Template attribute, and the Printer does not support that attribute, as far as IPP is concerned, the result of processing that Job (with respect to the missing attribute) is undefined. 2.2.3.5 Return one of the success status codes Once the Job object has been created, the Printer object accepts the request and returns to the client: (1) the 'successful-ok' status code, if there are no unsupported or conflicting Job Template attributes or values. (2) the 'successful-ok-conflicting-attributes' status code, if there are any conflicting Job Template attribute or values. (3) the 'successful-ok-ignored-or-substituted-attributes' status code, if there are only unsupported Job Template attributes or values. Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the above already rejected the request in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors. The Printer object also returns Job status attributes that indicate the initial state of the Job ('pending', 'pending-held', ' processing', etc.), etc. See Print-Job Response, [RFC2566] section 3.2.1.2. 2.2.3.6 Accept appended Document Content The Printer object accepts the appended Document Content data and either starts it printing, or spools it for later processing. 2.2.3.7 Scheduling and Starting to Process the Job The Printer object uses its own configuration and implementation specific algorithms for scheduling the Job in the correct processing order. Once the Printer object begins processing the Job, the Printer changes the Job's state to 'processing'. If the Printer object supports PDL override (the "pdl-override-supported" attribute set to 'attempted'), the implementation does its best to see that IPP attributes take precedence over embedded instructions in the document data.
2.2.3.8 Completing the Job The Printer object continues to process the Job until it can move the Job into the 'completed' state. If an Cancel-Job operation is received, the implementation eventually moves the Job into the ' canceled' state. If the system encounters errors during processing that do not allow it to progress the Job into a completed state, the implementation halts all processing, cleans up any resources, and moves the Job into the 'aborted' state. 2.2.3.9 Destroying the Job after completion Once the Job moves to the 'completed', 'aborted', or 'canceled' state, it is an implementation decision as to when to destroy the Job object and release all associated resources. Once the Job has been destroyed, the Printer would return either the "client-error-not- found" or "client-error-gone" status codes for operations directed at that Job. Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" value for a sufficiently long time after a job has been destroyed, so that stale references kept by clients are less likely to access the wrong (newer) job. 2.2.3.10 Interaction with "ipp-attribute-fidelity" Some Printer object implementations may support "ipp-attribute- fidelity" set to 'true' and "pdl-override-supported" set to ' attempted' and yet still not be able to realize exactly what the client specifies in the create request. This is due to legacy decisions and assumptions that have been made about the role of job instructions embedded within the document data and external job instructions that accompany the document data and how to handle conflicts between such instructions. The inability to be 100% precise about how a given implementation will behave is also compounded by the fact that the two special attributes, "ipp- attribute-fidelity" and "pdl-override-supported", apply to the whole job rather than specific values for each attribute. For example, some implementations may be able to override almost all Job Template attributes except for "number-up". 2.3 Status codes returned by operation This section lists all status codes once in the first operation (Print-Job). Then it lists the status codes that are different or specialized for subsequent operations under each operation.
2.3.1 Printer Operations 2.3.1.1 Print-Job The Printer object MUST return one of the following "status-code" values for the indicated reason. Whether all of the document data has been accepted or not before returning the success or error response depends on implementation. See Section 14 for a more complete description of each status code. For the following success status codes, the Job object has been created and the "job-id", and "job-uri" assigned and returned in the response: successful-ok: no request attributes were substituted or ignored. successful-ok-ignored-or-substituted-attributes: some supplied (1) attributes were ignored or (2) unsupported attribute syntaxes or values were substituted with supported values or were ignored. Unsupported attributes, attribute syntaxes, or values MUST be returned in the Unsupported Attributes group of the response. successful-ok-conflicting-attributes: some supplied attribute values conflicted with the values of other supplied attributes and were either substituted or ignored. Attributes or values which conflict with other attributes and have been substituted or ignored MUST be returned in the Unsupported Attributes group of the response as supplied by the client. [RFC2566] section 3.1.6 Operation Status Codes and Messages states: If the Printer object supports the "status-message" operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a status message for the following error status codes (see section 14): 'client-error-bad-request', 'client-error- charset-not-supported', 'server-error-internal-error', ' server-error-operation-not-supported', and 'server-error- version-not-supported'. In this case, it MUST set the value of the "attributes-charset" operation attribute to 'utf-8' in the error response. For the following error status codes, no job is created and no "job- id" or "job-uri" is returned: client-error-bad-request: The request syntax does not conform to the specification.
client-error-forbidden: The request is being refused for
authorization or authentication reasons. The implementation
security policy is to not reveal whether the failure is one of
authentication or authorization.
client-error-not-authenticated: Either the request requires
authentication information to be supplied or the authentication
information is not sufficient for authorization.
client-error-not-authorized: The requester is not authorized to
perform the request on the target object.
client-error-not-possible: The request cannot be carried out
because of the state of the system. See also 'server-error-
not-accepting-jobs' status code which MUST take precedence if
the Printer object's "printer-accepting-jobs" attribute is '
false'.
client-error-timeout: not applicable.
client-error-not-found: the target object does not exist.
client-error-gone: the target object no longer exists and no
forwarding address is known.
client-error-request-entity-too-large: the size of the request
and/or print data exceeds the capacity of the IPP Printer to
process it.
client-error-request-value-too-long: the size of request variable
length attribute values, such as 'text' and 'name' attribute
syntaxes, exceed the maximum length specified in [RFC2566] for
the attribute and MUST be returned in the Unsupported
Attributes Group.
client-error-document-format-not-supported: the document format
supplied is not supported. The "document-format" attribute
with the unsupported value MUST be returned in the Unsupported
Attributes Group. This error SHOULD take precedence over any
other 'xxx-not-supported' error, except 'client-error-charset-
not-supported'.
client-error-attributes-or-values-not-supported: one or more
supplied attributes, attribute syntaxes, or values are not
supported and the client supplied the "ipp-attributes-fidelity"
operation attribute with a 'true' value. They MUST be returned
in the Unsupported Attributes Group as explained below.
client-error-uri-scheme-not-supported: not applicable.
client-error-charset-not-supported: the charset supplied in the
"attributes-charset" operation attribute is not supported. The
Printer's "configured-charset" MUST be returned in the response
as the value of the "attributes-charset" operation attribute
and used for any 'text' and 'name' attributes returned in the
error response. This error SHOULD take precedence over any
other error, unless the request syntax is so bad that the
client's supplied "attributes-charset" cannot be determined.
client-error-conflicting-attributes: one or more supplied
attribute va attribute values conflicted with each other and
the client supplied the "ipp-attributes-fidelity" operation
attribute with a 'true' value. They MUST be returned in the
Unsupported Attributes Group as explained below.
server-error-internal-error: an unexpected condition prevents the
request from being fulfilled.
server-error-operation-not-supported: not applicable (since
Print-Job is REQUIRED).
server-error-service-unavailable: the service is temporarily
overloaded.
server-error-version-not-supported: the version in the request is
not supported. The "closest" version number supported MUST be
returned in the response.
server-error-device-error: a device error occurred while
receiving or spooling the request or document data or the IPP
Printer object can only accept one job at a time.
server-error-temporary-error: a temporary error such as a buffer
full write error, a memory overflow, or a disk full condition
occurred while receiving the request and/or the document data.
server-error-not-accepting-jobs: the Printer object's "printer-
is-not-accepting-jobs" attribute is 'false'.
server-error-busy: the Printer is too busy processing jobs to
accept another job at this time.
server-error-job-canceled: the job has been canceled by an
operator or the system while the client was transmitting the
document data.
2.3.1.2 Print-URI
All of the Print-Job status codes described in Section 3.2.1.2
Print-Job Response are applicable to Print-URI with the following
specializations and differences. See Section 14 for a more complete
description of each status code.
server-error-uri-scheme-not-supported: the URI scheme supplied in
the "document-uri" operation attribute is not supported and is
returned in the Unsupported Attributes group.
2.3.1.3 Validate-Job
All of the Print-Job status codes described in Section 3.2.1.2
Print-Job Response are applicable to Validate-Job. See Section 14
for a more complete description of each status code.
2.3.1.4 Create-Job All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Create-Job with the following specializations and differences. See Section 14 for a more complete description of each status code. server-error-operation-not-supported: the Create-Job operation is not supported. 2.3.1.5 Get-Printer-Attributes All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specializations and differences. See Section 14 for a more complete description of each status code. For the following success status codes, the requested attributes are returned in Group 3 in the response: successful-ok: no request attributes were substituted or ignored (same as Print-Job) and no requested attributes were unsupported. successful-ok-ignored-or-substituted-attributes: same as Print- Job, except the "requested-attributes" operation attribute MAY, but NEED NOT, be returned with the unsupported values. successful-ok-conflicting-attributes: same as Print-Job. For the error status codes, Group 3 is returned containing no attributes or is not returned at all: client-error-not-possible: Same as Print-Job, in addition the Printer object is not accepting any requests. client-error-request-entity-too-large: same as Print-job, except that no print data is involved. client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes MUST be ignored and ' successful-ok-ignored-or-substituted-attributes' returned. client-error-conflicting-attributes: same as Print-Job, except that "ipp-attribute-fidelity" is not involved. server-error-operation-not-supported: not applicable (since Get- Printer-Attributes is REQUIRED). server-error-device-error: same as Print-Job, except that no document data is involved. server-error-temporary-error: same as Print-Job, except that no document data is involved. server-error-not-accepting-jobs: not applicable.
server-error-busy: same as Print-Job, except the IPP object is
too busy to accept even query requests.
server-error-job-canceled: not applicable.
2.3.1.6 Get-Jobs
All of the Print-Job status codes described in Section 3.2.1.2
Print-Job Response are applicable to the Get-Jobs operation with the
following specializations and differences. See Section 14 for a
more complete description of each status code.
For the following success status codes, the requested attributes are
returned in Group 3 in the response:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job) and no requested attributes were
unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-
Job, except the "requested-attributes" operation attribute MAY,
but NEED NOT, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
For any error status codes, Group 3 is returned containing no
attributes or is not returned at all. The following brief error
status code descriptions contain unique information for use with
Get-Jobs operation. See section 14 for the other error status codes
that apply uniformly to all operations:
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-request-entity-too-large: same as Print-job, except
that no print data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable,
since unsupported operation attributes MUST be ignored and '
successful-ok-ignored-or-substituted-attributes' returned.
client-error-conflicting-attributes: same as Print-Job, except
that "ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since Get-
Jobs is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
2.3.2 Job Operations 2.3.2.1 Send-Document All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to the Get-Printer-Attributes operation with the following specializations and differences. See Section 14 for a more complete description of each status code. For the following success status codes, the document has been added to the specified Job object and the job's "number-of-documents" attribute has been incremented: successful-ok: no request attributes were substituted or ignored (same as Print-Job). successful-ok-ignored-or-substituted-attributes: same as Print- Job. successful-ok-conflicting-attributes: same as Print-Job. For the error status codes, no document has been added to the Job object and the job's "number-of-documents" attribute has not been incremented: client-error-not-possible: Same as Print-Job, except that the Printer's "printer-is-accepting-jobs" attribute is not involved, so that the client is able to finish submitting a multi-document job after this attribute has been set to 'true'. Another condition is that the state of the job precludes Send- Document, i.e., the job has already been closed out by the client. However, if the IPP Printer closed out the job due to timeout, the 'client-error-timeout' error status SHOULD be returned instead. client-error-timeout: This request was sent after the Printer closed the job, because it has not received a Send-Document or Send-URI operation within the Printer's "multiple-operation- time-out" period. client-error-request-entity-too-large: same as Print-Job. client-error-conflicting-attributes: same as Print-Job, except that "ipp-attributes-fidelity" operation attribute is not involved. server-error-operation-not-supported: the Send-Document request is not supported. server-error-not-accepting-jobs: not applicable. server-error-job-canceled: the job has been canceled by an operator or the system while the client was transmitting the data.
2.3.2.2 Send-URI All of the Print-Job status code descriptions in Section 3.2.1.2 Print-Job Response with the specializations described for Send- Document are applicable to Send-URI. See Section 14 for a more complete description of each status code. server-error-uri-scheme-not-supported: the URI scheme supplied in the "document-uri" operation attribute is not supported and the "document-uri" attribute MUST be returned in the Unsupported Attributes group. 2.3.2.3 Cancel-Job All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Cancel-Job with the following specializations and differences. See Section 14 for a more complete description of each status code. For the following success status codes, the Job object is being canceled or has been canceled: successful-ok: no request attributes were substituted or ignored (same as Print-Job). successful-ok-ignored-or-substituted-attributes: same as Print- Job. successful-ok-conflicting-attributes: same as Print-Job. For any of the error status codes, the Job object has not been canceled or was previously canceled. client-error-not-possible: The request cannot be carried out because of the state of the Job object ('completed', ' canceled', or 'aborted') or the state of the system. client-error-not-found: the target Printer and/or Job object does not exist. client-error-gone: the target Printer and/or Job object no longer exists and no forwarding address is known. client-error-request-entity-too-large: same as Print-Job, except no document data is involved. client-error-document-format-not-supported: not applicable. client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and values MUST be ignored. client-error-conflicting-attributes: same as Print-Job, except that the Printer's "printer-is-accepting-jobs" attribute is not involved.
server-error-operation-not-supported: not applicable (Cancel-Job
is REQUIRED).
server-error-device-error: same as Print-Job, except no document
data is involved.
server-error-temporary-error: same as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
2.3.2.4 Get-Job-Attributes
All of the Print-Job status codes described in Section 3.2.1.2
Print-Job Response are applicable to Get-Job-Attributes with the
following specializations and differences. See Section 14 for a more
complete description of each status code.
For the following success status codes, the requested attributes are
returned in Group 3 in the response:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job) and no requested attributes were
unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-
Job, except the "requested-attributes" operation attribute MAY,
but NEED NOT, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
For the error status codes, Group 3 is returned containing no
attributes or is not returned at all.
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable.
client-error-uri-scheme-not-supported: not applicable.
client-error-conflicting-attributes: not applicable
server-error-operation-not-supported: not applicable (since Get-
Job-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except no document
data is involved.
server-error-temporary-error: sane as Print-Job, except no
document data is involved.
server-error-not-accepting-jobs: not applicable. server-error-
job-canceled: not applicable.
2.4 Validate-Job The Validate-Job operation has been designed so that its implementation may be a part of the Print-Job operation. Therefore, requiring Validate-Job is not a burden on implementers. Also it is useful for client's to be able to count on its presence in all conformance implementations, so that the client can determine before sending a long document, whether the job will be accepted by the IPP Printer or not. 2.5 Case Sensitivity in URIs IPP client and server implementations must be aware of the diverse uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and Host names as case insensitive but reminds us that the rest of the URL may well demonstrate case sensitivity. When creating URL's for fields where the choice is completely arbitrary, it is probably best to select lower case. However, this cannot be guaranteed and implementations MUST NOT rely on any fields being case-sensitive or case-insensitive in the URL beyond the URL scheme and host name fields. The reason that the IPP specification does not make any restrictions on URIs, is so that implementations of IPP may use off-the-shelf components that conform to the standards that define URIs, such as RFC 2396 and the HTTP/1.1 specifications [RFC2068]. See these specifications for rules of matching, comparison, and case- sensitivity. It is also recommended that System Administrators and implementations avoid creating URLs for different printers that differ only in their case. For example, don't have Printer1 and printer1 as two different IPP Printers. The HTTP/1.1 specification [RFC2068] contains more details on comparing URLs. 2.6 Character Sets, natural languages, and internationalization This section discusses character set support, natural language support and internationalization. 2.6.1 Character set code conversion support IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY support additional charsets. It is RECOMMENDED that an IPP object also support US-ASCII, since many clients support US-ASCII, and indicate that UTF-8 and US-ASCII are supported by populating the
Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An IPP object is required to code covert with as little loss as possible between the charsets that it supports, as indicated in the Printer's "charsets-supported" attribute. How should the server handle the situation where the "attributes- charset" of the response itself is "us-ascii", but one or more attributes in that response is in the "utf-8" format? Example: Consider a case where a client sends a Print-Job request with "utf-8" as the value of "attributes-charset" and with the "job- name" attribute supplied. Later another client submits a Get-Job- Attribute or Get-Jobs request. This second request contains the "attributes-charset" with value "us-ascii" and "requested-attributes" attribute with exactly one value "job-name". According to the RFC2566 document (section 3.1.4.2), the value of the "attributes-charset" for the response of the second request must be "us-ascii" since that is the charset specified in the request. The "job-name" value, however, is in "utf-8" format. Should the request be rejected even though both "utf-8" and "us-ascii" charsets are supported by the server? or should the "job-name" value be converted to "us-ascii" and return "successful-ok-conflicting-attributes" (0x0002) as the status code? Answer: An IPP object that supports both utf-8 (REQUIRED) and us- ascii, the second paragraph of section 3.1.4.2 applies so that the IPP object MUST accept the request, perform code set conversion between these two charsets with "the highest fidelity possible" and return 'successful-ok', rather than a warning 'successful-ok- conflicting-attributes, or an error. The printer will do the best it can to convert between each of the character sets that it supports-- even if that means providing a string of question marks because none of the characters are representable in US ASCII. If it can't perform such conversion, it MUST NOT advertise us-ascii as a value of its "attributes-charset-supported" and MUST reject any request that requests 'us-ascii'. One IPP object implementation strategy is to convert all request text and name values to a Unicode internal representation. This is 16-bit and virtually universal. Then convert to the specified operation attributes-charset on output. Also it would be smarter for a client to ask for 'utf-8', rather than 'us-ascii' and throw away characters that it doesn't understand, rather than depending on the code conversion of the IPP object.
2.6.2 What charset to return when an unsupported charset is requested? Section 3.1.4.1 Request Operation attributes was clarified in November 1998 as follows: All clients and IPP objects MUST support the 'utf-8' charset [RFC2044] and MAY support additional charsets provided that they are registered with IANA [IANA-CS]. If the Printer object does not support the client supplied charset value, the Printer object MUST reject the request, set the "attributes-charset" to 'utf-8' in the response, and return the 'client-error-charset-not- supported' status code and any 'text' or 'name' attributes using the 'utf-8' charset. Since the client and IPP object MUST support UTF-8, returning any text or name attributes in UTF-8 when the client requests a charset that is not supported should allow the client to display the text or name. Since such an error is a client error, rather than a user error, the client should check the status code first so that it can avoid displaying any other returned 'text' and 'name' attributes that are not in the charset requested. Furthermore, [RFC2566] section 14.1.4.14 client-error-charset-not- supported (0x040D) was clarified in November 1998 as follows: For any operation, if the IPP Printer does not support the charset supplied by the client in the "attributes-charset" operation attribute, the Printer MUST reject the operation and return this status and any 'text' or 'name' attributes using the 'utf-8' charset (see Section 3.1.4.1). 2.6.3 Natural Language Override (NLO) The 'text' and 'name' attributes each have two forms. One has an implicit natural language, and the other has an explicit natural language. The 'textWithoutLanguage' and 'textWithoutLanguage' are the two 'text' forms. The 'nameWithoutLanguage" and ' nameWithLanguage are the two 'name' forms. If a receiver (IPP object or IPP client) supports an attribute with attribute syntax 'text', it MUST support both forms in a request and a response. A sender (IPP client or IPP object) MAY send either form for any such attribute. When a sender sends a WithoutLanguage form, the implicit natural language is specified in the "attributes-natural-language" operation attribute which all senders MUST include in every request and response.
When a sender sends a WithLanguage form, it MAY be different from the implicit natural language supplied by the sender or it MAY be the same. The receiver MUST treat either form equivalently. There is an implementation decision for senders, whether to always send the WithLanguage forms or use the WithoutLanguage form when the attribute's natural language is the same as the request or response. The former approach makes the sender implementation simpler. The latter approach is more efficient on the wire and allows inter- working with non-conforming receivers that fail to support the WithLanguage forms. As each approach have advantages, the choice is completely up to the implementer of the sender. Furthermore, when a client receives a 'text' or 'name' job attribute that it had previously supplied, that client MUST NOT expect to see the attribute in the same form, i.e., in the same WithoutLanguage or WithLanguage form as the client supplied when it created the job. The IPP object is free to transform the attribute from the WithLanguage form to the WithoutLanguage form and vice versa, as long as the natural language is preserved. However, in order to meet this latter requirement, it is usually simpler for the IPP object implementation to store the natural language explicitly with the attribute value, i.e., to store using an internal representation that resembles the WithLanguage form. The IPP Printer MUST copy the natural language of a job, i.e., the value of the "attributes-natural-language" operation attribute supplied by the client in the create operation, to the Job object as a Job Description attribute, so that a client is able to query it. In returning a Get-Job-Attributes response, the IPP object MAY return one of three natural language values in the response's "attributes- natural-language" operation attribute: (1) that requested by the requester, (2) the natural language of the job, or (3) the configured natural language of the IPP Printer, if the requested language is not supported by the IPP Printer. This "attributes-natural-language" Job Description attribute is useful for an IPP object implementation that prints start sheets in the language of the user who submitted the job. This same Job Description attribute is useful to a multi-lingual operator who has to communicate with different job submitters in different natural languages. This same Job Description attribute is expected to be used in the future to generate notification messages in the natural language of the job submitter. Early drafts of [RFC2566] contained a job-level natural language override (NLO) for the Get-Jobs response. A job-level (NLO) is an (unrequested) Job Attribute which then specified the implicit natural
language for any other WithoutLanguage job attributes returned in the response for that job. Interoperability testing of early implementations showed that no one was implementing the job-level NLO in Get-Job responses. So the job-level NLO was eliminated from the Get- Jobs response. This simplification makes all requests and responses consistent in that the implicit natural language for any WithoutLanguage 'text' or 'name' form is always supplied in the request's or response's "attributes-natural-language" operation attribute.
(page 50 continued on part 3)