I have two concerns
a) about an operation being rejected if it contains an unsupported
operation-attribute, and
b) the incrementing of the major version when an operation attribute
is added.
I think that the major version should be incremented only when a
Printer is likely to make a major mistake, e.g. the syntax has
changed. A new operation attribute might fall into this category, but
wouldn't normally if a Printer is allowed to ignore unrecognized ones,
as I suggest below.
The current model document says that a Printer MUST support all
operation-attributes and by implication that a Printer rejects an
operation if the operation contains an unsupported operation attribute
(though I cannot find such language and the algorithm in section 15.3
does not loop through operation attributes (a bug?)). But Scott and Tom
believe this to be the case.
This issue is much like the fidelity notion for Job-Template attributes
and probably calls for two changes in the future:
a) an operation attribute "ipp-operation-fidelity" which if
false allows the Printer to ignore operation-attributes, and
b) an unsupported-operation-attributes group in a response to
hold those operation attributes that the Printer ignored.
The current behavior of rejecting an operation with unsupported operation
attributes is simple, but will lead to problems in the future when
different versions are trying to interoperate and users prefer something
to nothing. But if an operation ignores attributes without telling
the client, that can create problems too.
I think that we have painted ourselves into a corner here.
a) If we keep the current behavior of rejecting operations that have
unsupported operation attributes, we have to rev the major version with
each new operation attribute which will create a lot of needless
versions to deal with.
b) If we allow operations with unsupported operation attributes, then all
operations responses need to be able to contain a list of ignored
operation attributes (yet another change); otherwise clients won't
know how to interpret a response.
c) If we believe that a client should be able to choose between a strict
and forgiving operation, then we also need to add the operation
attribute "ipp-operation-fidelity".
Bob Herriot