Below you suggest the need for a client to query on "allowed" attributes and
the server fills in the correct supported or capable if they are both
implemented. I have reviewed your email, and still don't get the need for
your suggestion.
My understanding:
A client queries the Printer and gets back some attributes. Since it gets
xxx-supported and xxx-capable, it knows the difference in semantics of the
two and does the right thing. If it sees a value in xxx-capable, it knows
that it must format some PDL string in order to realize the request. If it
sees a xxx-supported attribute it knows that is must supply a corresponding
xxx attribute in the print request or live with the default (the xxx
attribute at the Printer).
Scott
>>> Robert Herriot <Robert.Herriot@Eng.Sun.COM> 05/05 2:21 PM >>>
Scott,
Here is a change, that I propose for the model document.
At the model meeting last Friday, we decided to add a suffix 'capable'
to production attributes in the Printer's JobTemplate group. The
'capable' suffix was to allow a printer to distinguish between features
that it is capable of handling ('capable' suffix) and features that it
supports via IPP attributes ('supported' suffix).
An output device that supports IPP would likely have the same values in
the 'supported' attribute as in the 'capable' attribute, in which case
it would not need to have any 'capable' attributes (according to the
Friday proposed rules). Whereas a print server that has to modify a
PostScript file, might show 'as-is' as the only supported values for
many production attributes, but would show a complete feature list for
each 'capable' attributes.
I think we got the concept right, but we did not get the operation for
the client right. With Friday rule, when a client presents a set of
potential values for an attribute to an end-user, it implements one of the
following two rules:
o Rule 1, the client is embedding production attributes in the PDL:
look for the 'capable' attributes first and then the 'supported'
attributes.
o Rule 2, the client is explicitly including the IPP production
attributes:
look for the 'supported' attributes only.
I think that this complexity, if it is implemented, should be on the
server side, and the client should see one set of allowed values for
each attribute.
A client knows whether it is following rule 1 or 2 (above). So it
would be better for GetAttributes to have an additional parameter
called "allowed" whose value is 'supported' or 'capable' (default
'supported'). This attribute tells the server whether to follow rule 1
or 2 when producing the list of allowed values for each attribute.
An administrator could see the 'supported' and 'capable' attributes,
but not an end-user. The end-user sees only 'allowed' values.
Note: If an attribute on the server has a 'supported' suffix, but no
'capable' suffix, then the 'capable' value is the same as the
'supported' value.
The words 'allowed', 'supported' and 'capable' may not be the right words
for these three concepts, but I haven't thought of any better ones yet.
Comments?
Bob Herriot