Tom,
What is the impact of this change? That is, what required features of IPP
1.0 are not in IPP 1.1?
All I am aware of is SSL3 and the HTTPS scheme.
Ron Bergman
Hitachi Koki Imaging Solutions
On Wed, 5 May 1999, Hastings, Tom N wrote:
> 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.
>>