IPP>MOD - conformance

IPP>MOD - conformance

IPP>MOD - conformance

Roger K Debry rdebry at us.ibm.com
Wed Apr 9 13:24:00 EDT 1997


Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080


-----------
I've drafted a new section on conformance as it applies to attributes.
Comments please.....


IPP conforming implementations must do the following with respect to
attributes:


In response to a query (Get_Attributes or Get_jobs) an IPP Printer


- shall respond with all available supported values for each attribute
  if the attribute is supported by the Printer. Support for some attributes
  is mandatory. Available means that the Printer can actually determine what
  the attribute value is. For example, printer-state would be unavailable
  when a Printer is driving a legacy output device which has no capability
  of reporting its current state.


- shall respond with an empty value for each attribute that it recognizes,
   but which is unavailable.


         Issue: The notion of unavailable here is meant to handle cases
         where an IPP Printer is driving a legacy device which has no
         ability to report any information about itself upstream. Should
         there be an attribute value of "unavailable" to better indicate
         this condition?




- shall respond with an empty value for each attribute that it does not
   recognize.


        Issue: Should there be an attribute value of "unsupported" to
        better indicate this?


In response to a Print request, if the best-effort attribute is set to
substitute-as-needed, an IPP Printer


        Issue: The following assumes best-effort as currently defined
        in the model document.  best-effort would be a mandatory attribute.


- shall use the specified attribute value in the print operation if the
  attribute and the specified value are supported.


- shall ignore the attribute if the attribute is supported but the specificed
  value is not


        Issue: Should a return code indicate that the attribute was
        ignored because an unsupported  value was specified?


- shall ignore the attribute if the attribute is not supported.


        Issue: Should a return code indicate that the attribute was ignored
        because it is unsupported?








In response to a Print request, if the best-effort attribute is set to
do-not-substitute, an IPP Printer


- shall use the specified attribute value in the print operation if the
  attribute and the specified value are supported.


- shall reject the print job if the attribute is supported but the specified
  value is not.


        Issue: Should a return code indicate that the job was rejected
        because an unsupported attribute value was specified?


- shall reject the print job is the attribute is not supported.


        Issue: Should a return code indicate that the job was rejected
        because an unsupported attribute was specified?


Sending a Query or Print request, an IPP client need not specify any
attributes.


 Issue: Are there any attributes that are mandatory for a client to
 set in a Print request?


In response to a Query, an IPP client shall not fail for any attributes or
values for those attributes which are returned. The client need not use any
returned attributes in subsequent operations. IPP clients should provide a
means for displaying any returned attributes and values to an end user.


         Issue: Bob Herriot had suggested that the protocol should not
        say anything about what a client presents to an end user. If
        others agree, then perhaps this is just an implementation guideline.
        However, I think it is important to note.



More information about the Ipp mailing list