Roger deBry and I were discussing how requests and responses will be handled
between clients and servers that support different version numbers. We
concluded that every major and minor protocol version MUST support the version
and operation/status code fields in the first 4 bytes of the protocol as
currently defined in the IPP 1.0 protocol document.
Scenario 1: An IPP client at version 1.0 sends a request to an IPP server at
version 2.0. The server does not support 1.0. The server responds with
version=2.0 and status-code=ipp-server-error-version-not-supported (0x0503).
The client now understands the server does not support 1.0 and the server
supports 2.0.
Scenario 2: An IPP client at version 2.0 sends a request to an IPP server at
version 1.0. The server responds with version=1.0 and
status-code=ipp-server-error-version-not-supported (0x0503). The client now
understands the server does not support 2.0 and the server supports 1.0.
Scenario 3: An IPP client at version 2.6 sends a request to an IPP server at
version 2.1. The server successfully processes the request, ignoring what it
does not understand, and responds with version=2.1 and
status-code=successful-ok-ignored-or-substituted-attributes (0x0001). This
behavior seems consistent with Scott's comments in the attached note.
We also could not find any statement that requires clients and servers to be
downward compatible across major versions although an implementation may choose
to do so.
Comments?
Keith Carter
- - - - Attached Note - - - -
To: ipp at pwg.org @ internet, Robert.Herriot at Eng.Sun.COM @ internet
cc:
Subject: Re: IPP>MOD problem with MANDATORY support of operation attr
Bob,
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 at 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