IPP>MOD reconsideration of model decision

IPP>MOD reconsideration of model decision

IPP>MOD reconsideration of model decision

Roger K Debry rdebry at us.ibm.com
Tue May 6 18:24:15 EDT 1997

It seems to get more complicated by the minute ...

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/06/97 04:21
PM ---------------------------

        ipp-owner @ pwg.org
        05/06/97 03:29 PM
Please respond to ipp-owner at pwg.org @ internet

To: Robert.Herriot @ Eng.Sun.COM @ internet
cc: ipp @ pwg.org @ internet
Subject: Re: IPP>MOD reconsideration of model decision


Ok, so I'm dense...  I still can't quite come to grips with your
explanation below, and I'm really trying!

> 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.

Perhaps a line drawing or two would serve to clarify these situations?
Something like a set of quick pictures of the scenarios you describe?


More information about the Ipp mailing list