> From rdebry at us.ibm.com Fri Jul 18 08:58:03 1997
>>> 1) When the job is rejected, shouldn't the error code say something
> like 'client-error-attribute-value-unsupported'? Otherwise it is not
> clear that the attribute itself is supported, but the supplied value is not.
We have one status-code for both 'attribute not supported' and 'attribute value
not supported' because a job could be rejected because both problems exist.
The collection of unsupported attributes returned specify that it is
the attribute that is unsupported by returning the attribute in the
response with a value of "unsupported". Note an implementation that
rejects a job may return only the first attribute found, or all attributes
found or something in between.
>> 2) Should the unsupported values be returned as parameters's?
>> 3) As the text currently reads, when substitution occurs, the Printer
> may choose any supported attribute value that it chooses. Is this
> is what is intended? I would prefer that the default value be used
> and the text reflect the same processing as in case 5 (the value
> is not assigned at job creation, but at job processing time).
In an email about simplifying "best-effort" that I will send shortly I
will propose that the Printer simply ignore (treat as if not included
in the request) any 'attribute not supported' and 'attribute value not
supported'. That effectively means the job gets the default value.
This makes the solution very simple to implement.
>> 4) At one time, I thought we had a status code the said something
> like "ok-values substituted" for the case where "best-effort" was
> set to true. This alerts the end user that the ouput may not appear
> exactly as intended, but is printing anyway.
That might be useful information. The Printer could also return an OK
status-code with a list of the unsupported attributes as well to give
more detail.
Bob Herriot