IPP>MOD problem with MANDATORY support of operation attributes

IPP>MOD problem with MANDATORY support of operation attributes

IPP>MOD problem with MANDATORY support of operation attributes

Robert Herriot Robert.Herriot at Eng.Sun.COM
Mon Nov 10 19:52:40 EST 1997


I have two concerns
   a)  about an operation being rejected if it contains an unsupported
       operation-attribute, and
   b)  the incrementing of the major version when an operation attribute
       is added. 


I think that the major version should be incremented only when a
Printer is likely to make a major mistake, e.g. the syntax has
changed.  A new operation attribute might fall into this category, but
wouldn't normally if a Printer is allowed to ignore unrecognized ones,
as I suggest below.


The current model document says that a Printer MUST support all
operation-attributes and by implication that a Printer rejects an
operation if the operation contains an unsupported operation attribute
(though I cannot find such language and the algorithm in section 15.3
does not loop through operation attributes (a bug?)). But Scott and Tom
believe this to be the case.


This issue is much like the fidelity notion for Job-Template attributes
and probably calls for two changes in the future: 
  a) an operation attribute "ipp-operation-fidelity" which if 
     false allows the Printer to ignore operation-attributes, and 
  b) an unsupported-operation-attributes group in a response to 
     hold those operation attributes that the Printer ignored.


The current behavior of rejecting an operation with unsupported operation
attributes is simple, but will lead to problems in the future when
different versions are trying to interoperate and users prefer something
to nothing. But if an operation ignores attributes without telling
the client, that can create problems too.


I think that we have painted ourselves into a corner here.  
  a) If we keep the current behavior of rejecting operations that have
     unsupported operation attributes, we have to rev the major version with
     each new operation attribute which will create a lot of needless
     versions to deal with.  
  b) If we allow operations with unsupported operation attributes, then all 
     operations responses need to be able to contain a list of ignored 
     operation attributes (yet another change); otherwise clients won't
     know how to interpret a response.
  c) If we believe that a client should be able to choose between a strict
     and forgiving operation, then we also need to add the operation
     attribute "ipp-operation-fidelity".




Bob Herriot


 



More information about the Ipp mailing list