IPP>MOD - updated conformance paper -Reply

IPP>MOD - updated conformance paper -Reply

IPP>MOD - updated conformance paper -Reply

Scott Isaacson Scott_Isaacson at novell.com
Wed Apr 23 14:34:14 EDT 1997


Roger,


I am in the process of merging what you have done into the Model
document.   One of your issues below asks about "operations".  I have
created a whole new section of the model document (section 2) that
covers all conformance issues.  I created conformance requirements
subsections for "objects", "operations", "attributes", "best effort", "client",
and "server."  I plan to post this by today.


Scott




************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************




>>> Roger K Debry <rdebry at us.ibm.com> 04/23/97 11:14am >>>
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


Following is the text version of the conformance white paper. It
has been modified to include comments from Bob Herriot. Any
additional comments??


          IPP Conformance White Paper


          This paper does not discuss where conformance should go in the
          model document.  Personally, I prefer to see conformance
          described all together in one section, rather than spread
          throughout the document. As an implementor it seems easier to be
          sure that I've got a conforming application if the requirements
          are all stated in one place.


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


               Issue: We need to describe conformance as it relates to
               operations, security, etc.


          A Printer implements an attribute if that attribute is in the
          list of attributes that the Printer knows about, i.e. when
          queried for that attribute the Printer will respond with the
          values supported by the Printer for that attribute. A Printer may
          exhibit a behavior that corresponds to the value of some
          attribute, but if the Printer doesn't know about the attribute
          name, then as far as IPP is concerned, it does not implement the
          attribute. For example, if a printer prints 1-sided only, but it
          does not know about the attribute "sides", then in terms of IPP
          it does not implement the attribute "sides".


          A Printer supports an attribute value if that value represents a
          valid capability or state of the Printer, and the value is in the
          list of attribute values returned in response to a query on that
          attribute. If a value is not supported, that does not make a
          statement about whether the Printer implements the value. For
          example, an output device may be capable of printing  both
          1-sided and 2-sided-long-edge, but if an administrator sets up
          the Printer to always only print 2-sided-long-edge, then only the
          value 2-sided-long-edge is supported as far as IPP is concerned.


          In response to a Get_Attributes or Get_Jobs operation


         o If the client supplies an attribute and it is an attribute
            implemented by the Printer, the Printer shall respond with all
            currently supported values for that attribute.  If the value
            of an implemented attribute is unknown for any reason, the
            Printer shall respond with the value "unknown".


               Note: this requires an encoding of "unknown" for each
              attribute syntax.


          o If the client supplies an attribute and it is an attribute not
            implemented by the Printer, the Printer shall respond with the
            value of "unsupported" for that attribute.


               Note: this requires an encoding of "unsupported" for each
               attribute syntax.


        o If the client supplies an attribute group that is implemented
            by the Printer, the Printer shall respond with all currently
            supported values for each implemented attribute in the group.
            It shall not respond for unimplemented attributes in the
            group. If the value of an attribute is unknown for any
            reason, the Printer shall respond with the value "unknown" for
            that attribute.


          Each job and document attribute implemented by a Printer must
          have a defined default value. This value will be the first value
          returned in response to a query on that attribute.  Furthermore,
          each job and document attribute in this specification has a
          defined behavior for cases where the attribute is not implemented
          by the Printer. To be a conforming implementation, a Printer must
          exhibit the specified behavior for attributes which it does not
          implement. Otherwise the Printer must implement the attribute
          with at least the value which describes its behavior.  For
          example, the default behavior for _sides_ is 1-sided. If an
          output device only prints 2-sided-long, then it must implement
          the sides attribute with the value 2-sided-long.


          In response to a Print request, if a job or document attribute is
          not supplied by the client


          o and the Printer implements the attribute, the default value of
            that attribute shall be used in printing the job. If a client
            subsequently queries the job, such attributes shall be
            included in the job as if the client had included them in the
            original request.


          o and the Printer does not implement the attribute, the Printer
            shall use the default behavior defined for that attribute in
            this specification. If the attribute is not defined in this
            specification, i.e. it is a private extension, then the
            Printer shall use the default behavior built into the Printer
            for that extension. If a client subsequently queries the job,
            such attributes shall not be included in the response.


          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


               Note: The following assumes best-effort as currently defined
               in the model document.


          o shall use the supplied attribute value in the print operation
            if the Printer implements the supplied attribute and supports
            the supplied value.


          o shall change the attribute value to the default value for the
            supplied attribute if the Printer implements the supplied
            attribute but does not support the supplied value. A return
            code of "001" shall indicate that the job was accepted with
            attribute substitution.  A subsequent query of the
            aforementioned attribute should return the substituted value.


               Issue: What happens when the default attribute value is
               "unknown"?


          o shall ignore the attribute if the Printer does not implement
            the supplied attribute. A return code of "001" will indicate
            that the job was accepted with some attributes ignored. The
            Printer shall add the unimplemented attributes to the created
            job object with a value of "unsupported", making it easier for
            a client to query the job and see the attributes which were
            ignored. A subsequent Get-attributes operation will return the
            unsupported attributes.


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


          o shall use the supplied attribute value in the print operation
            if the Printer implements the supplied attributed and supports
            the supplied value.


          o shall reject the print job if the Printer implements the
            supplied attribute but does not support the supplied value. A
            return code of "109" will indicate that the job was rejected
            because a supplied attribute value is unsupported.


          o shall reject the print job if the Printer does not implement
            the supplied attribute. A return code of "109" will indicate
            that the job was rejected because a supplied attribute is not
            implemented.


          Sending a Query or Print request, an IPP client need not specify
          any attributes. A response to a query may contain attributes and
          values which the client does not implement.


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



More information about the Ipp mailing list