IPP>MOD - Conformance

IPP>MOD - Conformance

IPP>MOD - Conformance

Robert Herriot Robert.Herriot at Eng.Sun.COM
Tue Apr 22 19:02:29 EDT 1997


I agree with you rules below with the following suggestions and additions.
This reply got longer than I initially expected.


First, we need to define the terms "supported", "implements", and "default"
more carefully.


The text should indicate that a value is "supported" for an attribute
"XXX" if it is member of the set of values for the Printer attribute
"supportedXXX".  If a value is not supported, that does not make a
statement about whether the Printer implements the value. That is,
a Printer may implement values that someone (e.g. an administrator)
has decided a Printer will not support.


NOTE: the model group is still debating the name of "supportedXXX",
versus "XXXsupported" versus "XXX-supported", etc.


A printer implements an attribute if that attribute is in the list of
attributes that the Printer knows about.  A Printer may have behavior
that corresponds to the value of some attribute, but if the Printer
doesn't know about the attribute name, it doesn't implement it.  For
example, if a printer prints one-sided only but does not know about the
attribute "sides", it does not implement "sides" even though it prints
one-sided jobs. I would hope that most Printers would implement "sides",
even for one-sided Printer, but the same reasoning applies to the 
attribute "foo".


If a printer implements an attribute, but that attribute contains
no values (e.g. an Administrator didn't initialize it), what does
the Printer return as its value? "unknown", empty set, or does
every attribute has at least some reasonable value that can never
be empty (for IPP attributes, the model document defines such
a default value)?  


The text should also define what the Printer's default value is. For
attribute "XXX" the Printer's "defaultXXX" attribute contains the
default value.  If the printer doesn't implement "defaultXXX", the
default value is the first value of "supportedXXX". If neither
"supportedXXX" nor "defaultXXX" are defined, the printer does not 
implement the attribute, so the explicit default is moot.


Your text also omits a whole set of rules, namely what happens during
job submission when the job doesn't contain an attribute. The missing
rules are:


  o shall use the Printer's default attribute value in the print operation
      if the Printer implements an attribute which the job does not specify.
      If a client queries the job, subsequently, such attributes shall
      be included with the job, as if the client had included them with
      the original job submission.


  o shall use the default behavior (according to the IPP model document)
      for the attribute in the print operation if the Printer doesn't
      implement the attribute and the job does not specify the attribute
      and the IPP model document does specify the attribute. If a client 
      queries the job, subsequently, such attributes shall not be included
      with the job.




  o shall use the default behavior (according to the Printer)
      for the attribute in the print operation if the Printer doesn't
      implement the attribute and the job does not specify the attribute
      and the IPP model document does not specify the attribute. If a client 
      queries the job, subsequently, such attributes shall not be included
      with the job.


Comments about the text:


>  
> In response to a Print request, if a job or document attribute is
> supplied and the best-effort attribute is set to
> substitute-as-needed, an IPP Printer
> 
Change the following to active voice:


> 
> o shall use the supplied attribute value in the print operation
>     if the attribute is implemented in the Printer and the
>     specified value is supported.


  o shall use the supplied attribute value in the print operation
      if the Printer implements the specified attribute and supports
      the specified value.
> 
> o shall change the attribute value to the default value for the
>     supplied attribute if the attribute is implemented but the
>     supplied value is not supported. A return code will indicate
>     that the job was accepted with attribute substitution.  A
>     subsequent query of the supplied attribute should return the
>     substituted value.


ISSUE: what is the rule if the attribute's default value is "unknown"?
It that the same as the attribute not being implemented.


  o shall change the attribute value to the default value for the
      supplied attribute if the Printer implements the specified 
      attribute but does not support the specified value. A return 
      code shall indicate that the Printer accepted the job 
      with attribute substitution.  A subsequent query of the 
      aforementioned attribute should return the substituted value.
> 
> o shall ignore the attribute if the attribute is not
>     implemented. A return code will indicate that the job was
>     accepted with some attributes ignored. The Printer shall not
>     add the unimplemented attributes to the created job object. A
>     subsesquent Get-attributes operation will not return the
>     ignored unimplemented attributes.


ISSUE: what sort of return code is used when several of the return
code clauses get invoked?


   o shall ignore the attribute if the Printer does not implement
     it.  ...


Note: an alternative approach to the above case, is for the job to
    keep the attribute with a value of "unsupported".  This makes
    it easier for a client to query a job and see the attributes
    that were ignored.
> 
> In response to a Print request, if the best-effort attribute is
> set to do-not-substitute, an IPP Printer


Change these to active voice too:
> 
> 
> o shall reject the print job if the attribute is implemented but
>     the supplied value is not. A return code will indicate that
>     the job was rejected because a supplied attribute value is
>     unsupported.


Keep the language of "supported" for values rather than the implicit
"implemented" here.  Suggested wording:
  o shall reject the print job if the Printer implements the 
    specified attribute but does not support the specified value.
> 
> 




> 
> 
> In response to a Query, an IPP client may ignore any attributes
> that it does not implement.
> 


We probably shouldn't prescribe the behavior of a client. What we
should say is:


   A Query may return attributes and values which a client does not
   implement.


This warns the implementor to be ready to receive unexpected attributes
and value, but leaves the implementer free to handle such attributes
and values in whatever way the implementor chooses. This does not
prohibit bad solutions, such as abnormal termination of the client.



More information about the Ipp mailing list