So I think we only need "job-settable-attributes" and
For consistency, should they have the -supported suffix. That might help
general validation algorithms in some implementations, but does make the
attribute name long (37 characters).
I also think that "job-settable-attributes" should be REQUIRED if the
OPTIONAL Set-Job-Attributes operation is supported. Similarly, the
"printer-settable-attributes" attribute should be REQUIRED if the OPTIONAL
Set-Printer-Attributes operation is supported.
From: Hastings, Tom N [mailto:firstname.lastname@example.org]
Sent: Friday, October 22, 1999 14:22
Subject: IPP> OPS - Push back on issue 1 and 2 resolutions from Denver:
"when-supported" and "job-settable-attributes"
The minutes from the Denver meeting indicate:
Issue 1: The concept of a 'when-values-supported' was rejected. The
printer will do the best it can to support the request.
Issue 2: The decision was to remove the queries for settable attributes.
To determine if an attribute can be set, just try to set it. A new error
code will be added to indicate an attribute is 'not-settable'.
While I'm in favor of keeping things simple, I think we are going to far
Without the "when-supported", "job-settable-attributes",
"printer-settable-attributes", and "interpreter-settable-attributes", the
client can't decide what to show to the user and the user just tried
randomly to see what happens. This certainly is against the major thrust of
IPP that a client can determine what the Printer supports.
I talked with Harry, and I'm finishing editing in the agreements from Denver
into the document for Raleigh. We agreed to leave these in with an issue to
revisit as to whether to keep them or not. By keeping them in it will be
easier to understand their semantics and whether the complexity is worth the