IPP Mail Archive: IPP> MOD - ISSUE 36 Version number support (again)

IPP> MOD - ISSUE 36 Version number support (again)

Hastings, Tom N (hastings@cp10.es.xerox.com)
Fri, 21 May 1999 16:32:58 -0700

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