To get the discussion going, here is Issue 28 that has several possible
alternatives. Lets discuss them and/or add additional alternatives.
Thanks,
Tom
28) ISSUE: What if compression is supplied but not supported?
The "compression" operation attribute is an OPTIONAL attribute for a
Printer object to support in a create operation. However, if a client
supplies the "compression" attribute, but the IPP object doesn't support
the attribute at all, the Printer might attempt to print data it doesn't
understand, because it is compressed. In order to prevent this error,
the "compression" operation attribute should have been REQUIRED.
Possible Alternatives (related to Issues 3 and 6):
1.Clarify that an IPP object MUST reject a request that supplies a
"compression" operation attribute, if the IPP object does not support
the "compression" attribute at all. As with any such error, the IPP
object copies the "compression" attribute to the Unsupported
Attribute Group setting the value to the out-of-band 'unsupported'
value and returns the "client-error-attributes-or-values-not-
supported" status code. The IPP object MAY reject the request, even
if the client supplies the 'none' value, since the IPP Printer does
not have a corresponding "compression-supported" attribute.
2.Add a 'client-error-compression-not-supported' error status code.
Require IPP Printer's to support this error code if they do not
support the "compression" operation attribute.
3.Change IPP/1.1 Model and Semantics conformance requirement for the
"compression" and "compression-supported" attributes from OPTIONAL
to REQUIRED.