>>> Roger K Debry <rdebry@us.ibm.com> 04/09/97 11:24am >>>
> - shall respond with an empty value for each attribute that it does not
> recognize.
>
> Issue: Should there be an attribute value of "unsupported" to
> better indicate this?
Wouldn't it be better to return nothing at all? For some of the attributes
that have a non-keyword or text syntax, it might be a little more
difficult to parse an integer "12" and/or "unsupported". Doesn't just
not returning anything imply unsupprted?
> In response to a Print request, if the best-effort attribute is set to
> substitute-as-needed, an IPP Printer
> ...
> In response to a Print request, if the best-effort attribute is set to
> do-not-substitute, an IPP Printer
> ...
I agree with these semantics remembering that we wanted to move
best-effort back to an attribute-by-attribute level not a global Job level.
> Issue: Should a return code indicate that the job was rejected
> because an unsupported attribute value was specified?
Yes, but NOT return a list of the attributes (or their values) that were
unsupported as DPA suggested - a direct query could be made to
find out the supported attributes.
> In response to a Query, an IPP client shall not fail for any attributes or
> values for those attributes which are returned.
What does "fail" mean? Show an error that a bad response was
received? Kill the currently running process?
Does "not fail" mean handle it as any other non error case?
Scott