-----------
I've drafted a new section on conformance as it applies to attributes.
Comments please.....
IPP conforming implementations must do the following with respect to
attributes:
In response to a query (Get_Attributes or Get_jobs) an IPP Printer
- shall respond with all available supported values for each attribute
if the attribute is supported by the Printer. Support for some attributes
is mandatory. Available means that the Printer can actually determine what
the attribute value is. For example, printer-state would be unavailable
when a Printer is driving a legacy output device which has no capability
of reporting its current state.
- shall respond with an empty value for each attribute that it recognizes,
but which is unavailable.
Issue: The notion of unavailable here is meant to handle cases
where an IPP Printer is driving a legacy device which has no
ability to report any information about itself upstream. Should
there be an attribute value of "unavailable" to better indicate
this condition?
- 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?
In response to a Print request, if the best-effort attribute is set to
substitute-as-needed, an IPP Printer
Issue: The following assumes best-effort as currently defined
in the model document. best-effort would be a mandatory attribute.
- shall use the specified attribute value in the print operation if the
attribute and the specified value are supported.
- shall ignore the attribute if the attribute is supported but the specificed
value is not
Issue: Should a return code indicate that the attribute was
ignored because an unsupported value was specified?
- shall ignore the attribute if the attribute is not supported.
Issue: Should a return code indicate that the attribute was ignored
because it is unsupported?
In response to a Print request, if the best-effort attribute is set to
do-not-substitute, an IPP Printer
- shall use the specified attribute value in the print operation if the
attribute and the specified value are supported.
- shall reject the print job if the attribute is supported but the specified
value is not.
Issue: Should a return code indicate that the job was rejected
because an unsupported attribute value was specified?
- shall reject the print job is the attribute is not supported.
Issue: Should a return code indicate that the job was rejected
because an unsupported attribute was specified?
Sending a Query or Print request, an IPP client need not specify any
attributes.
Issue: Are there any attributes that are mandatory for a client to
set in a Print request?
In response to a Query, an IPP client shall not fail for any attributes or
values for those attributes which are returned. The client need not use any
returned attributes in subsequent operations. IPP clients should provide a
means for displaying any returned attributes and values to an end user.
Issue: Bob Herriot had suggested that the protocol should not
say anything about what a client presents to an end user. If
others agree, then perhaps this is just an implementation guideline.
However, I think it is important to note.