Last Call comment on Issue 36 resolution:
IPP/1.0 and IPP/1.1 are strict on what an IPP Printer MUST do if it receives
a version number (major minor combination) that it doesn't support. The
Printer MUST reject the request.
These parts of the specification were written when we were in the original
"server-be-strict" mood. Subsequently, we have drifted towards a
"server-be-lenient" mood and have allowed a server implementation to choose
whether to be strict or to be lenient. The client is warned that it cannot
count on a server to be strict or to be lenient. So a client can maximize
its interoperability by sending conforming requests, so that it doesn't
matter which implementation choice the Printer has made.
Why is allowing leniency a good idea in checking the version number?
Because when we have an IPP/1.2 specification that collects approved
extensions, such as, say, notification and output-bin, it might be a good
thing for an IPP/1.1 Printer to accept IPP/1.2 requests, instead of
rejecting them.
Therefore, I'd like us to apply the same reasoning to Issue 36 about version
number validation of requests. There is no question that a Printer MUST
reject a request if the major version number isn't supported, i.e., isn't in
any of the values of the "ipp-versions-supported" attribute. However, if
the major version does match, but there is no minor version number match,
the spec should be changed so that a Printer MUST:
1. either reject the request with 'server-error-version-not-supported'
OR
2. accept the request and process the request normally and return the
usual status codes
depending on implementation. In all cases, the "version-number" returned in
the response MUST be the closest version number that the Printer supports to
the version number supplied by the client in the request.
Comments?
Tom