I have suggested in the past that I am in favor of very strict versioning
rules
(new operation attrtibute means reject). However, as I think about the
principles of backwards compatiblity and versioning I come up with:
1. Reserver MAJOR version numbers for stuff that really breaks
the protocol and requires both client and server upgrades or you
just don't communicated (analogy: pick the human natural language
for our conversation or we don't talk)
2. Reserve MINOR version numbers for bundling of new features which
do not break clients or servers if the new features can successfully be
ignored therefore DO NOT REQUIRE all implementations (clients and
servers) to support ALL minor versions in sequence. You speak 2.5. I speak
2.6. I can choose to 1) revert to 2.5 and speak 2.5 with you or 2) just
keep talking 2.6 (knowing you will not reject any deltas between 2.5 and
2.6) but
at least we will still talk without forcing me to revert to 2.5. (analogy:
we both choose French, but you throw in some German words now and then and I
just ignore them, but the real language we are speaking is French).
The same example above holds if 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, and 2.6 all
exist and you support only 2.0 and I support 2.6. If I find out you only
speak 2.0, I can choose to revert to 2.0, or still speak 2.6 to you knowing
you will do your best up to 2.0 and you might ignore stuff.
However, if I speak 2.6 and you only speak 1.2, then we just can't speak
until I revert to something less than 2.0.
3. What if I support 2.5 and you support 2.6? Does this mean that I assume
you support 2.5 as well? I submit, that if either of us support 2.x then we
can both choose to communcate using 2.x and we should not break each other
(protocol error out).
4. This means that, yes, I am in favor of generally "ignoring what you don't
understand". However, I am not in favor of accepting anything from you in
any order or missing tags. The tags must still be there even if the set is
empty.
5. I am not in favor of adding an attribute to every operation that is like
"ipp-attribute-fidelity".
Summary:
1. Major version break stuff
2. Minor version are hints packaging of new features
3. Ignore stuff you don't understand (as much as possible)
4. Don't require all sides to implement all minor versions
5. Make version queriable in a way that never breaks across all
versions major and minor (if it does break it is a new protocol, not a major
version, ie., XXXng (next generation))
Scott
>>> Robert Herriot <Robert.Herriot@Eng.Sun.COM> 11/10/97 05:52PM >>>
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