IPP Mail Archive: IPP> MOD - ISSUE 36 Resolution: Don't require 1.0 support and add REQ

IPP> MOD - ISSUE 36 Resolution: Don't require 1.0 support and add REQ

Hastings, Tom N (hastings@cp10.es.xerox.com)
Wed, 2 Jun 1999 18:01:19 -0700

Comments on the proposed resolution to the IPP/1.1 issue concerning the
conformance requirements for supporting version 1.0 semantics and the
conformance requirements for accepting 1.x requests was raised as WG Last
Call comments. At the IPP WG meeting on 5/26-27 we reached the following
agreement.
The editors will be updating the IPP/1.1 Model and Semantics document and
the Encoding and Transport document to reflect these agreements. Any
comments should be send to the mailing list by Thursday, June 10, 1999.
Then the resulting documents will be sent as Internet-Drafts on Friday, June
11, 1999 for review by the IESG as proposed standards.
ISSUE 36: Don't require 1.0 support and add REQUIRED
"ipp-version-supported" attribute
If the major version number matches, but the minor version number does not,
the Printer SHOULD accept and attempt to process the request, or MAY reject
the request and return the 'server-error-version-not-supported' status code.
In all cases, the Printer MUST return the nearest version number that it
supports. For example, suppose that an IPP/1.2 Printer supports versions
'1.1' and '1.2'. The following responses are conforming:
Client supplies Printer Accept Request? Printer returns
1.0 yes (SHOULD) 1.1
no (SHOULD NOT) 1.1
1.1 yes (MUST) 1.1
1.2 yes (MUST) 1.2
1.3 yes (SHOULD) 1.2
no (SHOULD NOT) 1.2
Put this table in the IIG.
Changes to the text for the new attribute:
4.4.14 ipp-versions-supported (1setOf type2 keyword)
This REQUIRED attribute identifies the IPP protocol version(s) that this
Printer supports, including major and minor versions, i.e., the version
numbers for which this Printer implementation meets the conformance
requirements. For version number validation, the Printer matches the
(two-octet binary) "version-number" parameter supplied by the client in each
request (see sections 3.1.1 and 3.1.8) with the (US-ASCII) keyword values of
this attribute.
The following standard keyword values are defined:
'1.0': Meets the conformance requirement of IPP version 1.0 as
specified in RFC 2566 [RFC2566] and RFC 2565 [RFC2565] including any
extensions registered according to Section 6 and any extension defined in
this version or any future version of the IPP "Model and Semantics" document
or the IPP "Encoding and Transport" document following the rules, if any,
when the "version-number" parameter is '1.0'.
'1.1': Meets the conformance requirement of IPP version 1.1 as
specified in this document and [IPP-PRO] including any extensions registered
according to Section 6 and any extension defined in any future versions of
the IPP "Model and Semantics" document or the IPP Encoding and Transport
document following the rules, if any, when the "version-number" parameter is
'1.1'.
Modification to section 3.1.8 Versions:
3.1.8 Versions
Each operation request and response carries with it a "version-number"
parameter. Each value of the "version-number" is in the form "X.Y" where X
is the major version number and Y is the minor version number. By including
a version number in the client request, it allows the client to identify
which version of IPP it is interested in using, i.e., the version whose
conformance requirements the client may be depending upon the Printer to
meet.
If the IPP object does not support that major version number supplied by the
client, i.e., the major version field of the "version-number" parameter does
not match any of the values of the Printer's "ipp-versions-supported" (see
section 4.4.14), the object MUST respond with a status code of
'server-error-version-not-supported' along with the closest version number
that is supported (see section 13.1.5.4). If the major version number is
supported, but the minor version number is not, the IPP object SHOULD accept
and attempt to perform the request (or reject the request if the operation
is not supported), else it rejects the request and return the
'server-error-version-not-supported' status code. In all cases, the IPP
object MUST return the "version-number" that it supports that is closest to
the version number supplied by the client in the request.
There is no version negotiation per se. However, if after receiving a
'server-error-version-not-supported' status code from an IPP object, a
client SHOULD try again with a different version number. A client MAY also
determine the versions supported either from a directory that conforms to
Appendix E (see section 16) or by querying the Printer object's
"ipp-versions-supported" attribute (see section 4.4.14) to determine which
versions are supported. Issue 36
An IPP object implementations MUST support version '1.1', i.e., meet the
conformance requirements for IPP/1.1 as specified in this document and
[IPP-PRO]. An IPP object implementation SHOULD support version '1.0', i.e.,
meet the conformance requirements for IPP/1.0 [RFC2566 and RFC2565]. and
SHOULD support version '1.0', i.e., meet the conformance requirements for
IPP/1.0 [RFC2566 and RFC2565]. A client MAY also determine the versions
supported either from a directory that conforms to Appendix E (see section
16) or by querying the Printer object's "ipp-versions-supported" attribute
(see section 4.4.14) to determine which versions are supported. Issue 36
There is only one notion of "version number" that covers both IPP Model and
IPP Protocol changes. Thus the version number MUST change when introducing a
new version of the Model and Semantics document [IPP-MOD] or a new version
of the "Encoding and Transport" document [IPP-PRO].
Note: Changes to the major version number of the Model and Semantics
document indicate structural or syntactic changes that make it impossible
for older version of IPP clients and Printer objects to correctly parse and
correctly process the new or changed attributes, operations and responses.
If the major version number changes, the minor version numbers is set to
zero. As an example, adding the REQUIRED "ipp-attribute-fidelity" attribute
to version '1.1' (if it had not been part of version '1.1'), would have
required a change to the major version number, since an IPP/1.0 Printer
would not have processed a request with the correct semantics that contained
the "ipp-attribute-fidelity" attribute that it did not know about. Items
that might affect the changing of the major version number include any
changes to the Model and Semantics document [IPP-MOD] or the "Encoding and
Transport" document [IPP-PRO] itself, such as:
- reordering of ordered attributes or attribute sets
- changes to the syntax of existing attributes
- adding REQUIRED (for an IPP object to support) operation attribute
groups
- adding values to existing REQUIRED operation attributes
- adding REQUIRED operations

Changes to the minor version number indicate the addition of new features,
attributes and attribute values that may not be understood by all IPP
objects, but which can be ignored if not understood. Items that might
affect the changing of the minor version number include any changes to the
model objects and attributes but not the encoding and transport rules
[IPP-PRO] (except adding attribute syntaxes). Examples of such changes are:
- grouping all extensions not included in a previous version into a
new version
- adding new attribute values
- adding new object attributes
- adding OPTIONAL (for an IPP object to support) operation
attributes (i.e., those attributes that an IPP object can ignore without
confusing clients)
- adding OPTIONAL (for an IPP object to support) operation attribute
groups (i.e., those attributes that an IPP object can ignore without
confusing clients)
- adding new attribute syntaxes
- adding OPTIONAL operations
- changing Job Description attributes or Printer Description
attributes from OPTIONAL to REQUIRED or vice versa.
- adding OPTIONAL attribute syntaxes to an existing attribute.
Issue 33

The encoding of the "version-number" MUST NOT change over any version number
(either major or minor). This rule guarantees that all future versions will
be backwards compatible with all previous versions (at least for checking
the "version-number"). In addition, any protocol elements (attributes,
error codes, tags, etc.) that are not carried forward from one version to
the next are deprecated so that they can never be reused with new semantics.
Implementations that support a certain version NEED NOT support ALL previous
versions. As each new version is defined (through the release of a new
specification), that version will specify which previous versions MUST and
which versions SHOULD be supported in compliant implementations. Issue 36
Change to section 5.2.4 [Conformance of] Versions:
Clients MUST support version 1.1, i.e., MUST meet the conformance
requirements for clients specified in this document and [IPP-PRO] and SHOULD
also support version 1.0, i.e., SHOULD meet the conformance requirements for
clients as specified in [RFC2566] and [RFC2565]. IPP objects MUST support
version 1.1, i.e., MUST meet the conformance requirements for IPP objects
specified in this document and [IPP-PRO] and SHOULD also support version
1.0, i.e., SHOULD meet the conformance requirements for IPP objects as
specified in [RFC2566] and [RFC2565].
IPP clients MUST send a version '1.1' in requests and SHOULD try alternate
versions if they receive a 'server-error-version-not-supported' error
return. IPP objects MUST accept a version 1.1 request (or reject the
request if the operation is not supported). IPP objects SHOULD accept any
request with the major version '1' (or reject the request if the operation
is not supported). See section 3.1.8.
Changes to section 13.1.5.4 server-error-version-not-supported (0x0503):
13.1.5.4 server-error-version-not-supported (0x0503)
The IPP object does not support, or refuses to support, the IPP protocol
version that was supplied as the value of the "version-number" operation
parameter in the request. The IPP object is indicating that it is unable or
unwilling to complete the request using the same major and minor version
number as supplied in the request other than with this error message. The
error response SHOULD contain a "status-message" attribute describing why
that version is not supported and what other versions are supported by that
IPP object. See sections 3.1.6 and 3.1.8. Issue 11
The error response MUST identify in the "version-number" operation parameter
the closest version number that the IPP object does support. For example,
if a client supplies version '1.0' and an IPP/1.1 object supports version
'1.0', then it MUST respond with version '1.0' in all responses to such a
request. If the IPP/1.1 object does not support version '1.0', then it
SHOULD accept the request and respond with version '1.1' or MAY reject the
request and respond with this error code and version '1.1'. If the IPP/1.1
object does not support version '1.0', then it SHOULD accept the request and
respond with version '1.1' or MAY reject the request and respond with this
error code and version '1.1'. If a client supplies a version '1.2' the
IPP/1.1 object SHOULD accept the request and return version '1.1' or MAY
respond with this error code and version '1.1'. See sections 3.1.8 and
4.4.14. Issue 36