At last week's telecon with a good number of people participating, we
relaxed the requirement that an IPP/1.1 Client and Printer MUST support
IPP/1.0 requests and responses and made it a SHOULD. As a consequence, we
agreed also agreed that we have to add a REQUIRED
"version-numbers-supported" so that a client can determine which versions
are supported. This attribute will also be added to the RECOMMEND list in
the directory appendix list.
36) ISSUE: Don't require 1.0 support and add REQUIRED
"version-numbers-supported" attribute
RECOMMEND, rather than REQUIRE, conforming IPP/1.1 clients and the IPP/1.1
Printers to support IPP/1.0 requests and responses. Therefore, add an
"ipp-versions-supported" Printer Description attribute. Also add this
attribute as RECOMMENDED in the directory schema list in the Appendix.
Suggested text:
4.4.n ipp-versions-supported(1setOf type2 keyword)
This REQUIRED attribute identifies the IPP protocol versions that this
Printer supports, including minor versions. If an IPP Printer receives a
request with the "version-number" parameter set to a (two-octet binary)
value that does not correspond to one of the values of this (US-ASCII)
keyword, it MUST reject the request and return the
'server-error-version-not-supported' status code. See Section 3.1.7.
The following standard keyword values are defined:
'1.0': Version 1.0 as specified in [RFC 2566] including any
extension defined in this document that would not compromise
interoperability with client or Printer that conforms to RFC 2566.
'1.1': Version 1.1 as specified in this document.
Section 3.1.7 needs the following changes:
3.1.7 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. If the IPP object does not
support that version, the object responds with a status code of
'server-error-version-not-supported' along with the closest version number
that is supported (see section 14.1.5.4).
There is no version negotiation per se. However, if after receiving a
'server-error-version-not-supported' status code from an IPP object, there
is nothing that prevents a client from trying again with a different version
number. In order to conform to IPP/1.1, an IPP object implementations MUST
support versions '1.1' SHOULD support version' 1.0'.
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].
Changes to the major version number indicate structural or syntactic changes
that make it impossible for older version of IPP clients and Printer objects
to correctly parse and 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 "ipp-attribute-fidelity"
attribute (if it had not been part of version '1.1'), would have required a
change to the major version number. 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
- changing Operation or Job Template attributes from OPTIONAL to
REQUIRED and vice versa
- adding REQUIRED (for an IPP object to support) operation
attributes
- adding REQUIRED (for an IPP object to support) operation attribute
groups
- adding values to existing 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.
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 major version NEED NOT support ALL
previous versions. As each new major version is defined (through the
release of a new specification), that major version will specify which
previous major versions MUST be supported in compliant implementations.