I suggest that it become an optional parameter to Print-Job, Print-URI,
Create-Job, and Validate-Job and that it be renamed to
`may-ignore-attributes' to reflect its new meaning.
If it is omitted in these operations, it has a value of false. All
implementations must support both values of this parameter. It seems
to me that this is not much of a requirement because very
implementation has to check if it supports an attribute and each value.
If the answer is yes, the value of may-ignore-attributes doesn't
matter. If it is no and may-ignore-attributes is false, the job is
rejected and the offending attribute returned in the response ( the
current required mechanism). If it is no and may-ignore-attributes is
true, I propose that the Printer ignore the attribute not to add it to
the job, which means the default behavior takes hold (the new
very-simple mechanism).
There should be an OPTIONAL job attribute may-ignore-attributes which
is set by the parameter may- ignore-attributes. This attribute is
MANDATORY if Create-Job is supported because Send-Document and Send-URI
use the value set by Create-Job. Otherwise, I wouldn't expect it to be
implemented. It would be useful in a future resubmit-job operation
The following is the change in wording that I propose for rules 3 and 4
in section 3.1.2.1 Print-Job Request:
3. The client supplies a Job Template attribute and either the
attribute is not supported by the Printer or the attribute value is not
among the values supported by the Printer: The value of the
"may-ignore- attributes" parameter determines the Printer's behavior.
3a. The client supplies no "may-ignore-attributes" parameter, or
supplies a "may-ignore- attributes" parameter of 'false': the
Printer SHALL reject the Job. It SHALL return the 'client-
error-attribute-unsupported" error code and the unsupported attribute
in the "unsupported attributes " output parameter. If it is the
attribute value that is unsupported, the attribute in the unsupported
attributes output parameter SHALL be exactly as received in the
request. If it is the attribute itself that is unsupported, the
attribute in the `unsupported attributes' output parameter SHALL have
the name as received in the request, but its value SHALL be
"unsupported". If a job contains more than one unsupported attribute or
attribute value that cause a job to be rejected, a Printer may return
all of them, some of them, or only one of them in the `unsupported
attributes' output parameter. Note: in the Send-Document or Send-URI
operation, the document and not the job is rejected, and if the
last-document flag is true, it is treated as if it were false so that
the client can resubmit the document.
3b. The client supplies a "may-ignore-attributes" of 'true': the
Printer SHALL continue accepting the Job but ignore the attribute and
not associate it with the new Job object. The Printer's default value
effectively becomes the value of this attribute (see rule 4 below). In
this case, if everything else is ok, the Printer SHALL return a
"successful-attributes-ignored" status code along an optional complete
list of ignored attributes in the `unsupported attributes' output
parameter.
Job-name
Job-name, like best-effort, doesn't fit in the job-template section.
For example, it alone is mandatory and it alone has no xxx-supported
attribute. It also has special rules for setting its value because it
has no default.
I suggest that it become a parameter to Print-Job, Print-URI,
Create-Job and Validate-Job and become a job-description attribute
where there are several mandatory attributes. The description for the
job attribute can contain all the rules for how a printer sets its
value, i.e. from the parameter, or the document-name or from an
implementation defined value, in that order of precedence.