Subject: IPP>MOD - conformance -Reply

From: "Scott A. Isaacson" <[email-masked]>
Date: Mon, 14 Apr 1997 17:41:04 -0600

Roger,

>>> Roger K Debry <[email-masked]> 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