Subject: IPP> RE: Printer Instance Creation/Installation

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Wed, 18 Dec 96 11:34:56 MST

As captured by Bill Wagner...

>     The objective of using a 'standard' driver for a new printer is often
>     voiced, but seldom realized  if the full capabilities of the printer
>     are to be accessible to the user. ....                             es

there seems to be consensus building that a "standard" IPP driver is
an unrealistic pursuit.

Perhaps I'm naive, but I don't think standard driver necessarily
means standard PDL. Most of what makes drivers unique are printer
features and capabilities like extra trays, higher capacity, paper
sizes etc. Exactly the kind of stuff we represent in the Printer MIB.

I know we haven't addressed finishing, color (to a great degree)
or fonts and resources... but why isn't it at least feasible that
the printer mib (and evolution thereof) support the notion of a
"standard" driver?

Isn't the driver in NT 4.0 rather "standard" as designed today, except
for the above mentioned?

Harry Lewis - IBM Printing Systems

---

From: Babak Jahromi <[email-masked]>
Date: Wed, 18 Dec 1996 20:12:22 -0800

The drivers (assuming defined as components that convert the
applications' output to printer-specific data) don't need to know where
the printer is and how the printer is communicated with. Like today,
most printer drivers don't care whether the printer is attachced locally
or over the net.

IPP does not have to be an exception. The driver generates the data, and
another component (in most operating systems this would be the print
spooler) owns getting the data to the printer, be it over the parallel
port, or across the Internet. It seems to me that the IPP protocol will
have to be implemented in the resident print spooler.

Babak

>----------
>From: 	Harry Lewis <[email-masked]>[SMTP:[email-masked]]
>Sent: 	Wednesday, December 18, 1996 7:57 AM
>To: 	[email-masked]
>Subject: 	RE: IPP> RE: Printer Instance Creation/Installation
>
>Babak, can you elaborate?
>
>>................ And the good thing is that the driver does not have to
>>know anything about the new protocol. i.e. no change is needed in
>>today's drivers.
>