Here is some suggested text for section 6 of the IPPv2 spec:
6 CONFORMANCE
6.1 IPP CONFORMANCE
The current IPP specification [RFC2911] requires that IPP
attributes received, that are not supported or not understood,
are to be processed according to the defined procedures, and
an appropriate status code returned. Many implementations
historically have not conformed to this requirement, causing
communications problems and failed printing.
To claim compliance with any of the IPPv2 versions, an
implementation MUST correctly process attributes, values, or
groups that are not supported per RFC 2911, sections 3.1.7,
3.1.8, 3.2.1.2, 3.3.5.1, 3.3.7.1, 4.1.2.3, and 13.1.2.2,
including collection attributes as defined in RFC 3382,
section 7.
For example, implementations MUST support reading the IPP
noValue tag as a valid value for an attribute that normally
would be encoded as an enum, integer, name, or keyword value
tag. Similarly, implementations MUST correctly process (or
ignore) collection values as defined by RFC 3382, even if
the implementation does not support the media-col attribute
itself.
6.2 HTTP CONFORMANCE
The current IPP specification [RFC2911] requires transport
over HTTP/1.1 as defined in RFC 2616. Many implementations
historically have not used a HTTP/1.1 transport or provided
complete HTTP/1.1 support.
To claim compliance with any of the IPPv2 versions, an
implementation MUST support the complete HTTP/1.1 protocol
as defined in RFC 2616, including chunking as defined in
section 3.6.1 and the Expect header as defined in section
5.3.
In addition, implementations supporting TLS encryption MUST
support the HTTP Upgrade protocol as defined in RFC 2817.
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer