IPP> MOD - 36) ISSUE: Don't require 1.0 support and add REQUIRED "ver sion-numbers-supported" attribute

IPP> MOD - 36) ISSUE: Don't require 1.0 support and add REQUIRED "ver sion-numbers-supported" attribute

Ron Bergman rbergma at dpc.com
Wed May 5 10:58:26 EDT 1999


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.
> 
> 




More information about the Ipp mailing list