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 have found the section on conformance, as it relates to attributes,
to be confusing. I've tried to reason out what I think conformance
means. If this sounds reasonable then perhaps we can use some
of the following text to clarify conformance in section 1.1 of the
model document. Please let me know your thoughts on the
following. What I've suggested may not be correct, but I think we
have to be this specific.
Attributes are conditionally mandatory. This means the following:
(The attribute sides will be used as an example)
If a Printer does not provide a feature that a given attribute
controls, then
In response to a general query (all or an attribute group) the
Printer should respond with any attributes it does not
support. For example, if jobTemplate is specified in a Get
Attributes request, and the Printer only supports simplex
printing, then it should return the attribute keyword sides
with the attribute value 1-sided. However, it need not
send back anything for sides.
In response to a specific query for an unsupported attribute,
the Printer should return the attribute keyword with an
appropriate value. For example, if Sides is requested in a
Get attributes request, and the Printer only supports simplex
printing, then it should respond with sides = 1-sided. However,
it may respond with sides = null value, since if it is really
unsupported it will not know what value to respond with.
In response to a print request including a non-supported
attribute, the Printer must recognize the attribute as one
that it does not support (this would have to include syntax
errors or private extensions not supported) and honor the
print request ONLY if the best-effort attribute is set to
substitute-as-needed (this implies that best-effort is either
a mandatory attribute, or always defaults to do-not-
substitute). In our example, a duplex job sent to a simplex
printer would not print unless substitute-as-needed is
indicated.
When a print request is rejected because of an
unsupported attribute, the Printer must be able to indicate
which attribute(s) in the request were not supported and
therefore caused the failure. In our example, if a duplex job
is sent to a simplex printer, and the print request is rejected, the
response must say sides=duplex not supported.
In response to a general query, a client should provide end
users with some mechanism to see and select all attributes
returned by the Printer. However, a client need not provide
the end user with visibility of any attributes.
When submitting a print request, the client need not explicity
specify any attributes, thus taking the Printer defaults.
For example, it might always default sides to be either
1-sided or take the Printer default. From this point of view,
it is probably correct to say that a client need not support
any attributes. This is contradictory to the current model doc.