Currently the Hold-Job and Restart-Job operation have the following text
that indicates what to do if the client supplies a supported value for the
RECOMMENDED "job-hold-until" operation attribute:
If supplied and supported as specified in the Printer's
"job-hold-until-supported" attribute, the IPP object copies the supplied
operation attribute to the Job object, replacing the job's previous
"job-hold-until" attribute, if present, and makes the job a candidate for
scheduling during the supplied named time period.
What is not specified is what happens if:
1. The client supplies a value that is not supported, i.e., is not in the
Printer's "job-hold-until-supported" attribute?
The conservative approach is to return the
'client-error-attributes-or-values-not-supported' and refuse to do the
operation, rather than to return
'successful-ok-ignored-or-substituted-attributes' and ignore the unsupported
attribute value. Since the unsupported attribute value is returned, the
client can show it to the user and the user can try again with a different
value.
2. The client supplies the "job-hold-until" attribute and the Printer
doesn't support the "job-hold-until" Job Template (and operation) attribute
at all (which is conforming)?
The same conservative approach could be used when the entire attribute is
not supported. In this case, the attribute is returned in the Unsupported
Attributes Group with the out-of-band 'unsupported' value.
If we do follow these conservative suggestions, then the following (liberal)
paragraph in Section 3.1.3 Attributes entitled Unsupported Attributes should
be changed from:
- Unsupported Attributes: In a create request, the client supplies a
set of Operation and Job Template attributes. If any of these attributes or
their values is unsupported by the Printer object, the Printer object
returns the set of unsupported attributes in the response. Section 16 gives
a full description of how Job Template attributes supplied by the client in
a create request are processed by the Printer object and how unsupported
attributes are returned to the client. Because of extensibility, any IPP
object might receive a request that contains new or unknown attributes or
values for which it has no support. In such cases, the IPP object processes
what it can and returns the unsupported attributes in the response.
to something like:
- Unsupported Attributes: If a client supplies Operation or Job
Template attributes or values in a request that are not supported, the IPP
object returns them in the Unsupported Attributes Group to indicate to the
client which attribute or values are not supported. See the Unsupported
Attributes Group description for the Print-Job Response (section 3.2.1.2),
the other operation responses sections, and section 16 for a full
description of what is returned in the Unsupported Attributes group.
Whether the operation is rejected or accepted depends on the (1) attribute,
(2) whether the attribute is an Operation or Job Template attribute, and (3)
the value of the "ipp-attribute-fidelity" attribute. If the attribute is an
Operation attribute, the operation is rejected, unless specified otherwise
in this document. If the attribute is a Job Template attribute, the
operation is accepted if the value of "ipp-attributes-fidelity" is 'true',
else it is rejected (see section 3.2.1.1 and 16).
Tom Hastings
(310) 333-6413