Mike, Jay and Bill,
I agree that the logical attributes in an IPP Printer can be somewhat
different then the physical features of the printer. It is up to the IPP
Printer implementation to provide a suitable mapping for anything that the
physical printer can do, and there might be attributes which have no
correspondence in the physical printer, e.g. priority might be handled by
queuing in the IPP Printer, but the physical printer may have no concept of
priority if it can only handle one job at a time. And as already pointed
out, an administrator may disallow use of certain features or values that
the physical printer can do. An example would be a particular IPP Printer
that only allows double sided printing (to save trees), although the
physical printer would support double and single sided. Such an IPP Printer
would obviously also not support transparencies as media!
My general answer to Mike's original questions is that our assumption so far
is that the functionality that you are looking for should be covered by the
emerging Set-Printer-Attributes operation for the administrator to
originally set up or later modify the operations, attributes and values in
the IPP Printer and for an IPP Client to read that information using the
Get-Printer-Attributes operation. This might still leave a slight hole when
it comes to relationships between attributes or values, in which case you
can also use the Verify-Job operation to check if the combination selected
for a particular job is valid before actually submitting the job. It is
expected that the QUALDOCS project will come up with a more comprehensive
proposal for how to verify dependencies between attributes and values.
One last comment, we certainly do not want any company specific version
numbers, that would defeat the whole idea about a standard.
Carl-Uno
> -----Original Message-----
> From: Wagner,William [mailto:bwagner at digprod.com]
> Sent: Tuesday, January 04, 2000 8:08 AM
> To: 'jkm at underscore.com'; ipp at pwg.org> Cc: henrik.holst at i-data.com; Shepherd, Michael
> Subject: RE: IPP> IIG - Administration issues
>>> 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
>