> From SISAACSON at novell.com Tue May 6 13:34:29 1997
>> Bob,
>> 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
Perhaps, I didn't explain the idea clearly. I intended that the client
wouldn't have to do the work of looking for both 'capable' and
'supported' attributes. Instead the server would do the same work and
just send an 'allowed' attribute with the value of the 'capable' or
'supported' according to the two rules I defined (included further down
in this email). With my rule, a client using IPP attributes only uses
'allowed' attributes and can be totally unaware of the 'capable'
parameter to getAttributes. A client that will imbed all production
attributes still uses the 'allowed' attributes, but specifies the
'capable' parameter to the getAttributes operation. Without my
proposed change, such a client would have to look for 'capable' and
'supported' attribute when building a GUI -- perhaps not a big thing
for this legacy support, but I would rather that legacy support be in
a server as much as possible.
>>> >>> Robert Herriot <Robert.Herriot at 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>