At 08:57 04/22/97 PDT, Scott Isaacson wrote:
>Roger,
>>My comments...
>>>>> Roger K Debry <rdebry at 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.
ISSUE: at present there is no distinguishing syntax between an attribute
and an attribute group, so that the Printer that received a query for
a token that it doesn't implement, has no idea whether it is a group
or an attribute.
Without any distinguishing syntax, the Printer can only assume its an
attribute (or like UNIX file system, say its a directory or a file, I
can't tell which). So the error code could be:
some-attributes-or-attribute-groups-not-implemented
instead of
some-attributes-not-implemented
(Or we could keep the error code simpler as the second one and just explain
in documentation and helpd text that the error could be an unimplemented group.
ISSUE: can we add groups as extensions in the future, or are the current
groups fixed? If fixed, then we could require a Printer to know about
all the groups. On the other hand, a future version of the Protocol might
add new groups, and so the idea of a fixed set of groups just seems to be
a bad idea, unless we simplify to a very small set of very general groups.
So the bottom line and simplest is to just require a Printer to handle
an unimplemented token (whether a group or an attribute) as if it were
an unimplemented attribute.
>>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.
>>Have we decided what to do in the case where the client does not
>supply any attributes or attribute groups in a query?
>>> Sending a Query or Print request, an IPP client need not specify
>> any attributes.
>>Add:
>>If a client does not specify any attributes in a Query, the Printer responds
>will ALL implemented attributes.
No, lines 752:755 specify the default groups that a Printer shall respond
with if the client does not submit any attributes or groups in a query.
The list is the useful set of attributes (which will be a constant
source of debate).
ISSUE: But we do need a way for a client to query "all" attributes supported.
Should we add "all" as a new (super) group?
Or is it simpler to abandon the idea of a default set of groups, so that
all is requested by the client by not specifying any attributes or groups?
(as Scott suggested above).
>>Scott
>>>