Just to clarify ... my proposal does send back the capabilities of the printer
PLUS adminsitrative defaults filled in
PLUS operational or policy attributes set. However, these may override or void
some printer capabilities. For example, a company may define a policy that only
duplex printing will be supported. If this is the case, simplex may not show
up as an option since operationally it cannot be selected.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/17/96 10:44
AM ---------------------------
hsato @ cse.canon.co.jp
12/09/96 02:05 AM
To: Roger K Debry/Boulder/IBM, ipp @ PWG.ORG@??.ibm.com@internet
cc:
Subject: RE: Random thougts on naming and Job-templates
Roger K Debry wrote:
>3) Given all of the above, what does it mean to do a getAttributes" operation
>on a Printer. What I'd like to propose is the following idea. When I direct a
>getAttributes request to a Printer with no attribute list specified, the
>Printer synthesizes a response which we might in fact now think of as a
>job-template. That is, the Printer takes the characteristics of the output
>device, overlays that with policy attributes and defaults, and sends this back
>to the client. In the simple case the client now only needs to present this to
>the end user to fill in the blanks or change defaults, and send this back to
>the Printer in the print request. An alternative would be to add a
>getJobTemplate operation, but getAttributes seems to work just fine.
At IPP/1.0, Attributes mean current status and capability on a Printer with
a discriminator, e.g. "not-ready".
And IPP/1.0 says on getAttributes that "If no attribute list is supplied, then
all attributes defined for that object are returned."
So client can get the whole capability of the Printer.
To make a printer driver, we need this function.
If getAttributes return only some values, then a printer driver shows
only the values. Is it user-friendly?
Hiroyuki Sato
Canon