Page 144, end of section 15.3.5 Validate the values of the OPTIONAL
Operation attributes
contains the handling of unknown or unsupported attributes, followed by a=
=20
one paragraph note and a series of dashes. The two paragraphs following
the dashes should be part of the note, since all three paragraphs are
explaning=20
the handling of unknown or unsupported operation attributes. I suggest t=
hat=20
the dashed line be deleted and the two last paragraphs be indented at the=
=20
same level as the first paragraph of the note.
Here is the text:
unknown or unsupported attribute
IF the attribute syntax supplied by the client is supported but the=20
length is not legal for that attribute syntax, REJECT/RETURN=20
'client-error-bad-request'.
ELSE copy the attribute and value to the Unsupported Attributes respon=
se=20
group and change the attribute value to the out-of-band 'unsupporte=
d'=20
value, but otherwise ignore the attribute.
Note: Future Operation attributes may be added to the protocol=20
specification that may occur anywhere in the specified group. When=
the=20
operation is otherwise successful, the IPP object returns the=20
'successful-ok-ignored-or-substituted-attributes' status code. =20
Ignoring unsupported Operation attributes in all operations is
analogous=20
to the handling of unsupported Job Template attributes in the creat=
e and
Validate-Job operations when the client supplies the=20
"ipp-attribute-fidelity" Operation attribute with the 'false' value=
.=20
-----------------------------------------------
This last rule is so that we can add OPTIONAL Operation attributes to
future versions of IPP so that older clients can inter-work with new IPP
objects and newer clients can inter-work with older IPP objects. (If the
new attribute cannot be ignored without performing unexpectedly, the majo=
r
version number would have been increased in the protocol document and in
the request). This rule for Operation attributes is independent of the
value of the "ipp-attribute-fidelity" attribute. =20
For example, if an IPP object doesn=92t support the OPTIONAL "job-k-octet=
s"
attribute (because of the implementation or because of some administrator=
=92s
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.