Following is update to the conformance white paper. This reflects Tom's email
and discussion in last week's IPP telecon.
Comments please ....
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
model document. Personally, I prefer to see conformance
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:
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 some 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 some
reason, the Printer shall respond with the value "unknown" for
that attribute.
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 attribute is implemented in the Printer and the
specified value is supported.
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.
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.
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 attribute is implemented and the supplied value is
supported.
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.
o shall reject the print job if a supplied attribute is not
implemented. Aeturn code 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.
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 may ignore any attributes
that it does not implement.