IPP>MOD - Conformance -Reply

IPP>MOD - Conformance -Reply

IPP>MOD - Conformance -Reply

Tom Hastings hastings at cp10.es.xerox.com
Wed Apr 23 15:02:53 EDT 1997


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
>
>
>



More information about the Ipp mailing list