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/07/97 07:35
AM ---------------------------
SISAACSON @ novell.com
05/06/97 04:20 PM
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org at internet
cc:
Subject: Re: IPP>MOD reconsideration of model decision
Roger, my comments are below
>>> Roger K Debry <rdebry at us.ibm.com> 05/06 12:49 PM >>>
> I think that I agree with Jay on this one. I fear that we are burdening
> IPP with complexity in order to to solve a problem on a small set of
> servers. Is the class of servers that changes controls in the Postscript
> file a very large piece of the Universe? I suspect not. Rather than solve
> every conceivable problem in this very large universe, we ought to
> get back on track with the rule I thought we agreed to awhile back --
> to solve the few problems well that represent the largest customer
> value. Over time the rest of the world will catch up and do things
> **right**. Rule (1) below makes no sense to me. Clients (drivers) that
> understand IPP (and therefore know what xxx-capable means)
> ought not to imbed controls in the PDL, period! I think that adding
> xxx-capable is adding undue complexity!!!
An implemented xxx-capable attribute on a Printer means:
This printer is capable of the features implied by the values of this
attribute, however, in order to have a job realize these features, the
instructions must be in the PDL, not in the external attributes.
RKD> This seems a bit of an oxymoron. If a client is capable of
RKD> understanding what an xxx-capable attribute is at all, then
RKD> it must be ipp-aware. If it is ipp-aware, it is a new driver
RKD> which ought to exploit ipp by setting controls as ipp
RKD> attributes, not imbedding them in the PDL.
An implemented xxx-supported attribute on a Printer means:
This printer supports the features implied by the values of this attribute,
however, in order to have a job realize these features, the instructions
must be in the Job attributes (not in the PDL) and if a similar instruction
happens to be in the PDL, this printer can override that with the value in
the Job attribute.
RKD> How do I change attributes on a page-by-page basis then?
xxx-capable allows us to work with existing, non IPP aware printer drivers.
RKD> I'm really lost --- sorry to be dense but I don't understand
RKD> how xxx-capable allows a non-ipp aware driver to do anything
RKD> (since it is non-ipp aware it doesn't understand any ipp
RKD> attributes so how does it know what ipp-capable means?) Are
RKD> we are worried about a client which takes an existing PDL
RKD> file and submits it for printing? If so, what does it care
RKD> about xxx-capable for since it does not build the PDL. If we
RKD> are worried about some clients that take the existing PDL and
RKD> add controls to it, I'd ask once again how many of those are
RKD> there and does that number justify this added complexity.
xxx-supported allows us to move to a better future with Job attribute,
printer capabilities, and control all outside the PDL (the only reason it is
all mumbled up in the PDL is becuase there has never really been a separate
control channel to a printer, just a data channel).
If we go with Jay's suggestion and just let a client "get what they get" if
they submit job attributes as well as PDL encodded instructions, then maybe
xxx-capable is just for the directory entry (the printer is capapable of
some feature, get the right legacy driver, non IPP aware, and you are off
and running with no job attributes). But I think it is useful for the
directory at least, perhaps not for client queries directly at the printer.
RKD> Think about this alternative. Just as we have agreed that
RKD> downloading and installing a print driver is outside the
RKD> scope of IPP, why not declare the way that *legacy* drivers
RKD> get information about the printer, i.e. xxx-capable, to be
RKD> outside the scope of IPP. That's the way that drivers work
RKD> today, they use ppd files or other side files which describe
RKD> capabilities of the device required to generate the correct
RKD> ouput. We have provided an attribute which points to a place
RKD> where drivers and driver installers live. Why not let ppd files
RKD> or other side files live at the same place? Now when I install
RKD> a legacy device as an IPP printer I get the driver *and* the
RKD> ppd (or whatever) files that the driver would normally use anyway.
Scott