Scott ...
>>> Roger K Debry <rdebry@us.ibm.com> 04/21/97 01:46pm >>>
> o If the client supplies an attribute group that is implemented
> by the Printer, the Printer shall respond with all currently
> supported values for each implemented attribute in the group.
> It shall not respond for unimplemented attributes in the
> group. If the value of an attribute is unknown for some
> reason, the Printer shall respond with the value "unknown" for
> that attribute.
Add:
o If the client supplies an attribute group that is not implemented
by the Printer, the Printer shall respond with no attributes or attribute
values for that group.
RKD> Tom also pointed this out. The reason I did not
RKD> add it was because I reasoned that if a Printer
RKD> did not implement an attribute group, it actually
RKD> would not know if the thing it got was an attribute
RKD> group or simply an attribute, and thus must always
RKD> treat it as a simple attribute. The response for
RKD> an unimplemented attribute is to return a value of
RKD> "unsupported".
Also, we need to talk about extensions:
o In a query, if the client supplies an attribute group that is implemented
by the Printer, the Printer shall respond with all currently
supported values for each implemented attribute in the group. Since
the printer may implement attributes for that group that the client
might not expect to be in that group, the client may choose to
ignore any attributes returned as part of that group. The client shall
not fail on any response to a query.
RKD> Isn't this covered in the last section which says that
RKD> "In response to a query an IPP client may ignore any
RKD> attributes that it does not implement"?
Have we decided what to do in the case where the client does not
supply any attributes or attribute groups in a query?
RKD> I think the current model document does describe the
RKD> actions to take when no attributes are supplied.
RKD> For example lines 751-755.
> Sending a Query or Print request, an IPP client need not specify
> any attributes.