Jay,
Since you ask, it was my understanding and I believe that it is well
established in the IPP model specification that the administrator setup of
attributes is independent of the actual attributes of the physical device.
The administrator may choose to not expose certain capabilities; it may also
mean that the administrator can cause IPP to indicate attributes values that
are not supported by the device, although there seems to be little support
for this. The model spec clearly states that the way in which the
administrator sets attributes is out of scope. However, if there were no
independence, there would me no reason to have administrator set, because in
the general case the actual attributes are available from the device.
William A. Wagner (Bill Wagner)
Director of Technology, DPI Imaging Division
NETsilicon, Inc.
wwagner at digprod.com
-----Original Message-----
From: Jay Martin [mailto:jkm at underscore.com]
Sent: Tuesday, January 04, 2000 10:22 AM
To: ipp at pwg.org
Cc: henrik.holst at i-data.com; Shepherd, Michael
Subject: Re: IPP> IIG - Administration issues
> 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