At 12:37 04/18/97 PDT, Roger K Debry wrote:
...
>[5] When an implementation doesn't know the value, DPA, IPP, and most SNMP MIBs
>have been using the value "unknown". I suggest that IPP continue this.
>RKD> Does this cover the case where the device may support an
>RKD> attribute, such as finishing, but has no means for passing
>RKD> this information back to the IPP layer? If so, I agree.
I think that we should clarify that 'unknown' covers this case.
...
>[7] Because of extensibiity, I don't think that there is any need to consider
>the case of an implementation recognizing an attribute that it doesn't
>implement. An implementation either implements an attribute or it doesn't.
>RKD> Not sure what this applies to in my text???
You used the word "recognize" as distinct from supported. I feel that
there is no need for a Printer to return two different error codes for
attributes: one for attributes it recognizes, but doesn't support,
versus attributes it doesn't recognized and doesn't support.
For example, an implementation might recognize all attributes in the
standard, but not support all of them. But another implementation might
not recognize all of them and so would return the unsupported error.
And both implementations would return the unsupported error when a new
registered attribute is supplied by a client.
...
>- The client supplies an attribute or an attribute group, but it is an
>attribute or attribute group that is not implemented by that instance of
>the Printer. The Printer shall return no attribute and value for that
>attribute and shall return the status code:
>some-requested-attributes-not-implemented.
>RKD> But I assume the Printer still returns data for
>RKD> supported attributes. Is this approach better (easier)
>RKD> than a value of "unsupported"?
Actually, I agree with you that it would be much better for the user to see
which attributes aren't supported and shouldn't be too much harder to support.
And having an "unsupported" value come back with any of our attributes
would be a simple way to do it for our "ASCII" approach. It isn't so easy
for binary approaches, such as ASN.1 because the syntax for every value
as to include a CHOICE "unsupported".
>[13] Again, I think that it is simpler not to make a distinction between
>(1) recognized, but unimplemented, and (2) unrecognized. So just return
>no attribute at all and the status code:
>some-requested-attributes-not-implemented
>RKD> I would prefer a value of "unsupported". Going back to your point
>RKD> in [12], not returning an attribute at all seems a bit like returning
>RKD> an empty list. If an end user requests (in a list of attributes)
>RKD> attribute x, wouldn't a value of unspupported be easier to understand
>RKD> than leaving x out of the list of responses.
Again, I agree that it would be much better for the user to see which
attributes aren't supported and shouldn't be too much harder to implement.
A sub-issue would be when an implementation doesn't support all attributes
in a requested group. I would assume that the implementation would NOT
need to return the unsupported attributes in the group with a value of
"unsupported". Also when a new attribute is registered, the registration
would specify which group the attribute belongs, so we would have future
attributes belonging to groups that older implementations wouldn't
know about.