Subject: IPP>MOD - updated conformance paper

From: Roger K Debry <[email-masked]>
Date: Wed, 23 Apr 1997 13:14:06 -0400

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
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?

---

From: [email-masked] (Robert Herriot)
Date: Wed, 23 Apr 1997 12:37:32 -0700

I agree with your conformance paper, except for a couple of places noted
below.

Bob Herriot

> From [email-masked] Wed Apr 23 10:10:14 1997
> 
> 
              --------------------------------------------------------
>             group. If the value of an attribute is unknown for any
              ------
>             reason, the Printer shall respond with the value "unknown" for

The underlined sentence is meaningful for attributes in the standard
that the Printer doesn't implement, but not for other undefined and
unimplemented attributes like "foobar".

I assume that GetAttributes of a group does not return job attributes
which acquired the value of unsupported for the case where a job
submission includes an unsupported attribute, even for those
unsupported attributes defined in the standard. The one exception is
the group "all". This is because the Printer doesn't know what group it
belongs to except for the group "all".

>           returned in response to a query on that attribute.  Furthermore,

As my previous email stated, I disagree with the notion that the first
value is the default. This may simplify things, but it doesn't solve
the integer range case. This rule may be a good fallback rule for the
case where there is not an explicit default, but I think we need a
mechanism for defining default values. I have suggested that a naming
convention, such as "default-XXX" or "XXX-default" be used as the
default for "XXX". Or perhaps printer attribute XXX contains the default value
for job attribute XXX and the printer attribute "XXX-supported" contains
the supported values.

If you are looking for simplification, I would prefer to reduce the number
of groups to two for each object rather than give up the defaulting 
mechanism.  The two groups for each object (Job and Printer) would be
JobTemplate and xxxStatus.  All attributes in the current JobTemplate group
would remain in JobTemplate, but without any subgroups (at least as
knowledge within the implementation).  All other job attributes would
be in the JobStatus group and all other printer attributes would be in
the PrinterStatus group.