Subject: IPP> MOD - Contradictoy handling of "xxx-supported" with 'no-value'

From: Tom Hastings <[email-masked]>
Date: Wed, 7 Jan 1998 10:24:06 PST

There are three places in section 15.3 and 15.4 where a value of the
Printer object's "xxx-supported" of 'no-value' (meaning that the 
system administrator hasn't configured supported value(s)), indicates
that the validation fails, and one place where it says that the
client supplied "xxx" attribute validation is accepted.

The three places are:

In 15.3.4 Validate the values of the MANDATORY Operation attributes

In addition, the IPP object checks each Operation attribute value against
some Printer object attribute or some hard-coded value if there is no
"xxx-supported" Printer object attribute defined. If its value is not among
those supported or is not in the range supported, then the IPP object
REJECTS the request and RETURNS the error status code indicated in the
table by the second IF statement.  If the value of the Printer object's
"xxx-supported" attribute is 'no-value' (because the system administrator
hasn't configured a value), the check always fails.

In 15.3.5 Validate the values of the OPTIONAL Operation attributes

In addition, the IPP object checks each Operation attribute value against
some Printer attribute or some hard-coded value if there is no
"xxx-supported" Printer attribute defined. If its value is not among those
supported or is not in the range supported, then the IPP object REJECTS the
request and RETURNS the error status code indicated in the table.  If the
value of the Printer object's "xxx-supported" attribute is 'no-value'
(because the system administrator hasn't configured a value), the check
always fails.  

and in 15.4.2	Validate the values of the Job Template attributes

In addition, the IPP object loops through all the client-supplied Job
Template attributes, checking to see if the supplied attribute value(s) are
supported or in the range supported, i.e., the value of the "xxx" attribute
in the request is (1) a member of the set of values or is in the range of
values of the Printer' objects "xxx-supported" attribute.  If the value of
the Printer object's "xxx-supported" attribute is 'no-value' (because the
system administrator hasn't configured a value), the check always fails.
If the check fails, the IPP object copies the attribute to the Unsupported
Attributes response group with its unsupported value.  If the attribute
contains more than one value, each value is checked and each unsupported
value is separately copied, while supported values are not copied.  If an
IPP object doesn’t recognize/support a Job Template attribute, i.e., there
is no corresponding Printer object "xxx-supported" attribute, the IPP
object treats the attribute as an unknown or unsupported attribute (see the
last row in the table below).

However, at the end of 15.3.5 it contradicts that 'no-value' fails:

For example, if an IPP object doesn’t support the OPTIONAL "job-k-octets"
attribute (because of the implementation or because of some administrator’s
choice not to configure a value for the Printer object's
"job-k-octets-supported" attribute, leaving it with a 'no-value'
out-of-band value), the IPP object treats "job-k-octets" as an unknown
attribute and only checks the length for the 'integer' attribute syntax
supplied by the client.  If it is not four octets, the IPP object REJECTS
the request and RETURNS the 'client-error-bad-request' status code, else
the IPP object copies the attribute to the Unsupported Attribute response
group, setting the value to the out-of-band 'unsupported' value, but
otherwise ignores the attribute.

1. Suggested fix:  just delete the entire parenthetical remark:

(because of the implementation or because of some administrator’s choice
not to configure a value for the Printer object's "job-k-octets-supported"
attribute, leaving it with a 'no-value' out-of-band value)

so that an unconfigured "xxx-supported" attribute causes the validation
check to fail.  Then there is nothing special about the compare. If the
user supplies a value 'yyy' for attribute "xxx", and the corresponding
"xxx-supported" doesn't contain 'yyy', the validation check fails.

Thus we have no way for an administrator to configure the Printer to
accept any value of an attribute (a requirement that we have seen yet.)
If we ever get such a requirement, I suggest that we add another
out-of-band value that can only be used in "xxx-supported" attributes,
like 'no-value' and call it, say, 'any'.

NOTE: if a Job Template attribute "xxx" has a corresponding "xxx-supported"
Printer attribute that is not configured, the validation fails, but the
request is accepted or rejected depending on whether the value of 
"ipp-attribute-fidelity" is 'false' or 'true, respectively.  Not
configuring "xxx-supported" doesn't change how "ipp-attribute-fidelity" works.

NOTE: Clients MUST NOT supply the out-of-band value of 'no-value' as specified
in section 4.1, else the validation check with an configured "xxx-supported"
value would succeed.