Subject: IPP> MOD - Formatting problem with note on unknown/unsupported attributes

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

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 
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 
the handling of unknown or unsupported operation attributes.  I suggest that 
the dashed line be deleted and the two last paragraphs be indented at the 
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 
      length is not legal for that attribute syntax, REJECT/RETURN 
      'client-error-bad-request'.
   ELSE copy the attribute and value to the Unsupported Attributes response 
      group and change the attribute value to the out-of-band 'unsupported' 
      value, but otherwise ignore the attribute.

   Note: Future Operation attributes may be added to the protocol 
      specification that may occur anywhere in the specified group.  When the 
      operation is otherwise successful, the IPP object returns the 
      'successful-ok-ignored-or-substituted-attributes' status code.  
      Ignoring unsupported Operation attributes in all operations is
analogous 
      to the handling of unsupported Job Template attributes in the create and
      Validate-Job operations when the client supplies the 
      "ipp-attribute-fidelity" Operation attribute with the 'false' value. 
-----------------------------------------------

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 major
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.  

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.