Subject: Re: IPP>MOD reconsideration of model decision

From: Don Wright <[email-masked]>
Date: 6 May 97 7:23:22 EDT

Jay Martin said:
>If existing print drivers are considered "today's technology", then
>today's technology won't know anything about IPP, correct?
>
>Perhaps I'm missing something, then.  Does anyone think that IPP is
>being designed such that today's print drivers can submit jobs to
>an IPP Printer?
>
>Maybe that's where I'm getting confused.  I'm making the assumption
>that to drive an IPP Printer, you need an IPP-aware print driver.
>Is this assumption incorrect?

I hope we are all balled up in terminology not technology.  From this
printer manufacturer's perspective, a printer driver creates the 
datastream for a printer.  A "redirector" or "port driver" pushes that 
datastream out the desired physical connection (parallel port, serial
port, IPX/SPX ethernet, etc.)

My  assumption is that IPP will work with today's drivers but require 
new "redirector" or "port driver" software.

Don

---

From: Randy Turner <[email-masked]>
Date: Tue, 06 May 1997 09:58:22 -0700

> new "redirector" or "port driver" software.

IPP should work fine with today's drivers, if, as you suggest, an IPP
port driver
is instrumented at a layer beneath the driver. However, existing drivers
will not
be able to take advantage of any IPP-specific attribute specifications
and
capabilities. Existing drivers take user-specified job attributes and
encode them
into whatever PDL is going out; unfortunately, this would all be opaque
to an
IPP port driver beneath the printer driver, so in this model, existing
drivers would just be using IPP as a transport.

In the IPP-aware driver situation, it would be possible for the GUI to
include
IPP, as well as, printer-specific attributes, that could be included in
the
outgoing data stream. It is unlikely in this scenario that a port driver
would be
used underneath the IPP-aware printer driver. But it might be the case
that an
HTTP-aware port driver could sit underneath the IPP-aware driver and
transport the IPP datastream coming from the driver.

I guess what I'm saying is there's going to be alot of ways to deploy
IPP,
and existing print drivers can (and should) be supported.

Randy