IPP> MOD - Issue 28: What if compression is supplied but compression i sn't supported?

IPP> MOD - Issue 28: What if compression is supplied but compression i sn't supported?

IPP> MOD - Issue 28: What if compression is supplied but compression i sn't supported?

Hastings, Tom N hastings at cp10.es.xerox.com
Tue Mar 23 19:34:29 EST 1999


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.





More information about the Ipp mailing list