Subject: IPP>MOD - Conformance -Reply

From: Roger K Debry <[email-masked]>
Date: Tue, 22 Apr 1997 12:49:35 -0400

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

Scott ...

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

---

From: Tom Hastings <[email-masked]>
Date: Wed, 23 Apr 1997 12:02:53 PDT

At 08:57 04/22/97 PDT, Scott Isaacson wrote:
>Roger,
>My comments...

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.

>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