> Issue 1a - Regarding IPP-IIG Section 3.1.2.3.1 (Checking for conflicting Job
> Template attribute values), is it allowable for an administrator to define
> her own attribute/value conflicts? For instance, a printer object
> implementation ALLOWS transparencies to be stapled, but the administrator
> would prefer this to be NOT allowed on her particular printer. An
> additional admin (Set 2) operation or printer attribute collection may easy
> provide the functionality for this.
> HH> I don't quite understand your question. A printer object should describe
> HH> the physical device. If the the device does allow transparencies to
> HH> be stabled, then the printer object should support it too. If the
> HH> administrator wants to disable this functionality he should do it
> HH> in the printer object somehow.
This raises an interesting philosophical aspect regarding the wrapping
of a protocol around a "physical" object.
If a protocol is able to provide additional administratively-oriented
control capabilities, shouldn't the administrator be allowed to use it?
In this specific example, say the printer doesn't provide sufficient control
capabilities to disallow the use of staples with transparencies. Yet, for
obvious reasons, the administrator doesn't want to allow this operation to
occur. Shouldn't the protocol allow this degree of control, even though
the printer doesn't directly support it?
Henrik's statement makes me think that he believes IPP should *only* mirror
the capability of the printer, and nothing more. (Am I reading this wrong?)
How do others feel about extending control capabilities thru the use of the
protocol, rather than simply mirroring the capabilities of the printer?
...jay