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