> - 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?
RKD> I think this would be okay as long as returning nothing at all
RKD> is unambigous. Are there any other circumstances that would
RKD> result in returning nothing?
> 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.
RKD> That's fine, I wasn't suggesting returning a list of attributes
RKD> or values ... just wanted to indicate the reason the job was
RKD> rejected.
> 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?
RKD> What I meant by fail was to literally fail ... i.e.
RKD> do something unexpected, abend, display incorrect
RKD> info to the end-user, etc.