While finishing the editing on the Set2 operations about the Interpreter
Object, it occurred to me that we don't really need the
"interpreter-settable-attributes" attribute, since the Interpreter object is
sort of a sub-class of the Printer object. We aren't adding a
Get-Interpreter-Attributes and a Set-Interpreter-Attributes or a
Get-Interpreters operation. So whether an attribute is a Printer object
attribute or an Interpreter object attribute depends on implementation (and
whether there are even interpreter objects at all).
So I think we only need "job-settable-attributes" and
"printer-settable-attributes".
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.
Comments?
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Friday, October 22, 1999 14:22
To: ipp
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
here.
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
benefit.
Ok?
Thanks,
Tom