IPP>MOD reconsideration of model decision

IPP>MOD reconsideration of model decision

IPP>MOD reconsideration of model decision

Randy Turner rturner at sharplabs.com
Tue May 6 12:58:22 EDT 1997

Don Wright wrote:

> 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

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
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
IPP, as well as, printer-specific attributes, that could be included in
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
and existing print drivers can (and should) be supported.


More information about the Ipp mailing list