Subject: RE: IPP> RE: Printer Instance Creation/Installation -Reply

From: "Scott A. Isaacson" <[email-masked]>
Date: Wed, 18 Dec 1996 11:04:44 -0700

There are some proposed common naming schemes and structures (MS
INF files) but these are very POORLY followed and lead to many errors. 
They are changing over time and have not stablized.

This is an awfully big rat hole (elephant hole?,  black hole?).  We should
not waste our time on this initially, at all.

************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: [email-masked]
W: http://www.novell.com
************************************************************

>>> Carl-Uno Manros <[email-masked]> 12/17/96 08:23pm
>>>
At 06:46 PM 12/17/96 PST, Babak Jahromi wrote:
>>
>>if I recall correctly, one of our user requirements was that we would 
>>like to avoid having a separate print driver to install for every new
network
>>printer that a user may want to use. Compare this to fax today - you
do 
>>not expect the user to download a new piece of software for every
new
>>fax address he/she wants to use. My hope would be that the "IPP print
driver"
>>is a generic piece of software, which can be used for many different
printers
>>in combination with a relatively short list of capabilities and options
for a
>>particular printer. This list could be stored locally or downloaded every
>>time. 
>>Am I too optimistic here? 
>
>"Generic" is synonym to "poor feature list". Why do we want to force
>people who have invested in full feature printers to treat them like
>monochrome fax machines? If people like to use Internet Printing as a
>fax service, then the server can install the printer with a minimal
>driver, and we can arrage that all Internet clients would have that
>minimal driver. But beyond that, the driver would have to be
downloaded
>from the server. 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.
>
>Babak
>

OK. I can probably live with having at least a simple generic IPP driver 
that does not require explicit download in advance, with downloading
and 
automatic installation in other cases. Do we have any expectations about

the time needed to download a print driver over HTTP, using say in worst
case a 14.4 modem? Are there agreed naming conventions for drivers,
so 
that the clients can identify if they already have the right driver 
installed, or do we need to come up with a driver naming scheme?

Carl-Uno

---

From: "Scott A. Isaacson" <[email-masked]>
Date: Wed, 18 Dec 1996 11:07:43 -0700

Don's summary here is better than the one that I just sent out, but I just
got to reading this one.

On terminology:

The language, PDL driver is a Printer Driver.  The underlying IPP/Network
redirector should never be called a Driver.  It is a redirector or provider. 
Is Provider the more common term now?

Scott

>>> Don Wright <[email-masked]> 12/18/96 06:51am >>>
I think we are getting all balled up in terminology.  In my thinking
there are two (at least)  "drivers" used for printing in the PC OS
(read Win95, WinNT, OS/2) world:

1) Printer Language Driver - generates the PostScript, PCL, etc.
     needed by the printer to render the job.

2) IPP/HTTP driver which takes the output from the Printer Language
      driver and transports it across the network to the destination.  Also
       handles responses from the far end.

In my case, the Printer Language Driver is unique for each printer or
printer family.  The IPP/HTTP driver is common across all printers.
This scenario is basically what we have today with print redirectors
which send the job to a Server using IPX/SPX, NetBEUI, etc.  I don't
see any way to have a universal Printer Language driver any more
than we can today.  Sure, everyone can install the Apple LaserWriter
driver and call it a "Universal PostScript" driver or they can install
an HP LaserJet 2 driver and call it a "Universal PCL" driver but
the functionality is of course very low.

I think the choice belongs to the user.  The user could:

1) Install a "Universal" language driver and live with the limitations

--or --

2) Install the printer's driver across the network living with the download
      time depending upon the user's connection method.

--or--

3) Install the printer's driver from the operating system's diskettes
      or CD-ROM if known and available.

Am I missing something?  I know in some cases, a PPD driven PostScript
driver is available.  In that case, the PPD may be all that needs to be
downloaded but even then, all the features of the printer may not be
available without using a custom printer language driver.

Comments?

Don

----------------------------------------------------------------------

To: babakj%microsoft.com @ interlock.lexmark.com (Babak Jahromi) @
SMTP, 
IPP%pwg.org @ interlock.lexmark.com ("[email-masked]'") @ SMTP
cc:  (bcc: Don Wright)
From: cmanros%cp10.es.xerox.com @ interlock.lexmark.com (Carl-Uno
Manros) @ SMTP
Date: 12/17/96 07:23:35 PM
Subject: RE: IPP> RE: Printer Instance Creation/Installation

network
do 
new
driver"
printers
for a
downloaded

Carl-Uno

---

From: "Scott A. Isaacson" <[email-masked]>
Date: Wed, 18 Dec 1996 10:49:08 -0700

Bob,

After reading Peter's document and your email,  I don't feel that there is a
"different understanding".   

In Peter's "Current" scenario,  there are 9 steps. Steps 1-7 are what you
describe as printer browsing, and "some separate application possibly
initiated through a web browser" which selects, installs (including
download), and sets up that printer for printing by any application on the
desktop.  

Steps 8 and 9 are just running any application and printing.  This is what
you suggest as: "When a user wishes to print from an application, I
would expect that the list of available printers might include some IPP
printers, but the application not need be aware of this difference. The
same GDI API's would be supported by the IPP driver"

I don't see a difference between what you describe and what Peter had
under "Current".  However, in order to support the automatic driver
download problem (ie from the net not from a floppy or CD) we need to
have some way of connecting the correct driver with the IPP Printer. 
Some have suggested storing the Driver in the directory.  This would be
OK if there were a new entry type  called a Driver that contained info
about the driver and where the actual software was located, but it
would not be OK if the Driver were stored "as an attribute of the Printer
entry".  It is possible (as Peter suggests) to get by without the extra step
of more objects in the directory, just to point to the correct driver directly.
However, I would suggest one level of indirection.  This is why I
suggested some sort of DEVICE ID in the directory entry.  With this, the
"install wizard" could go out and find the right driver (there might be an
updated version).  This would free up the admin from trying to update all
Printer entries with the correct pointer to the correct driver if there ever
is a change. 

I propose not getting into this mess and just leave enough info in the
Printer object (and its directory  entry) which is the Device ID so that the
correct driver can be found.  I don't think that we should force it to point
to the correct driver or go the the trouble of trying to create a new object
called Driver.  Remember that a Driver can be many files (in windows it
can be a .DRV, some .DLLs, and some config info such as .PPDs).

There IS a difference when you talk about an IPP Aware Driver vs a Non
IPP Aware Driver.  Both could be used to realized IPP functionality with
existing GDI interfaces and applications.

IPP Aware Driver
In an IPP Aware Driver, the driver could implement the IPP protocol
directly (and assuming HTTP) be written to HTTP interfaces and just do
the operations directly.  In this case the Driver has to know the Printer
URL for which it is configured (set at install time or modified sometime
later through a Driver provided interface).  This would require new driver
development obviously.

IPP Non-Aware Driver
This scenario is just like any of the existing drivers today that are able to
format jobs that are "redirected to network printers".  There is some tool
that creates a new "port" which looks to the driver just like any other
hardware port.  The driver is configured to write to that port, but then
uderneath that port is a network redirector or a network provider that
does the right thing.  This redirector or provider can be configured
independently of the driver to point to some other network printer.  In the
IPP model, this scenario would require an IPP redirector or an IPP provider
but it would work (which would be some development) but it would work
for ALL drivers and ALL applications just as redirected printing works
today.

>>> Robert Herriot <[email-masked]> 12/17/96 06:25pm >>>
After reading Peter Zehler's document, I think that we have different
understandings of how IPP will work on a PC.  I have assumed that the
procedure that a user follows for finding a printer is separate from
the print operation.

For printer browsing, I would expect there would be some separate
application possibly initiated through a web browser which would allow
a user to specify printer characteristics and get back a list of
printers.  A user could then add one or more of these printers to the
desktop.  The operation of adding such a printer would install any
necessary drivers to the PC, like any other add printer operation except
that the drivers should come over the network and not request that the
user insert the CD-rom.

When a user wishes to print from an application, I would expect that
the list of available printers might include some IPP printers, but the
application not need be aware of this difference. The same GDI
API's would be supported by the IPP driver.

What do others think?  Do you agree with my understanding or do you
see things the way Peter does?

Bob Herriot

> From [email-masked] Sat Dec 14 17:06:47 1996
> Date: Sat, 14 Dec 1996 20:06:49 -0500
> From: JK Martin <[email-masked]>
> Organization: Underscore, Inc.
> X-Mailer: Mozilla 3.0 (Win95; U)
> MIME-Version: 1.0
> To: IPP redirector <[email-masked]>
> Subject: Re: IPP> RE: Printer Instance Creation/Installation
> References:
<"<E078B13281E2667C>[email-masked]"@-SMF->
> Content-Transfer-Encoding: 7bit
> Sender: [email-masked]
> X-Lines: 22
> 
> Zehler,Peter wrote:
> > 
> > All,
> > I have placed a document that discusses these issues in the
> >  "contributions for discussion directory".   I have an MS Word and
> > a postscript version of the document.   I need to convert the
document
> > to the Acrobat format.  I need help with this since I do not have an
> > Acrobat writer.
> 
> An Adobe PDF file now exists for the file(s) described above:
> 
>
ftp://ftp.pwg.org/pub/pwg/ipp/contributions-for-discussion/IPP-driver-issue.pdf
> 	...jay
> --  JK Martin               |  Email:   [email-masked]          --
> --  Underscore, Inc.        |  Voice:   (603) 889-7000              --
> --  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
> --  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com  
--

---

From: Babak Jahromi <[email-masked]>
Date: Wed, 18 Dec 1996 11:09:09 -0800

>
>This is not to say that easy installation of drivers is not an
>issue, it just shouldn't be OUR issue, at least initially.
>Besides, when you are talking about drivers you are probably
>undoubtedly talking about the Windows/Win95/Winnt environment,
>and I think that IPP should address more than solving the problem
>of internet printing within Microsoft environments.

Correct, the solution should be generic, but one that allows easy
integration to popular platforms that most IPP members would have to
deal with anyway. Win32 is obviously one of these popular platforms.

Babak

---

From: Don Wright <[email-masked]>
Date: 18 Dec 96 14:18:21 EST

I believe this group is interested to taking care of the details
so that this concept will be implemented in a consisted way. 
While the scope of the IETF work may simply be MIME definitions
and the IPP protocol, my suggestion from a couple of weeks 
ago to develop a scenarios document that delt with the details
of a complete implementation still stands.  We can product all
the RFCs we want but if we don't discuss and document the
details, we are doomed to a paper standard and a commercial
flop.

Don

Randy Turner said:
>Concerning the issue of drivers, isn't this outside the scope
>of IPP? We are just trying to architect a transport for delivery
>of print data over a network. Typically a Windows print driver
>will generate Postscript or PCL that includes printer-specific
>features. Once the final form of the PDL is submitted (via
>re-director or other method), that is where we come in with
>IPP.
>
>Like I suggested a week or so ago with the separate document
>scoping, I think the entire driver issue is non-sequitur with
>our efforts at prioritizing our work with the IPP transport
>protocol.
>
>Randy

Scott A. Isaacson wrote:
> 
> I agree with Babak.  We need to be able to support all existing drivers.
> But I doubt that we can be successful with any kind of "minimal driver".
> We already have that with the generic Apple Laserwriter PS driver and
> the HP 3 PCL driver.  These can be used for almost any printer in the
> world.  We don't need to create any new ones.
> 
> Scott
> 
> >>> Babak Jahromi <[email-masked]> 12/17/96 07:46pm >>>
> >
> >printer that a user may want to use. Compare this to fax today - you do
> >in combination with a relatively short list of capabilities and options for a
> minimal driver. But beyond that, the driver would have to be downloaded

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]

---

From: [email-masked]
Date: Thu, 19 Dec 1996 09:16:28 -0500

Classification:
Prologue:
Epilogue:

I don't think we can move to a common driver, but with the printer MIB and/or
IPP, we should be able to move to a model that is more like the postscript
printer definition file where the PDL generation is pretty generic for a given
family of printers (e.g. postscript or pcl), availability of unique printer
features (bins, finishing, paper handling, etc) is communicated via SNMP gets
or IPP getAttributes, and operation or selection of those features is through
IPP attributes provided with teh print job.

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/19/96 06:26
AM ---------------------------

        ipp-owner @ pwg.org
        12/18/96 11:15 AM

To: IPP @ pwg.org@internet, babakj @ microsoft.com@internet, cmanros @
cp10.es.xerox.com@internet
cc:
Subject: RE: IPP> RE: Printer Instance Creation/Installation -Reply

network
do
new
driver"
printers
for a
downloaded

Carl-Uno

---

From: [email-masked]
Date: Thu, 19 Dec 1996 09:16:11 -0500

Classification:
Prologue:
Epilogue:

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/19/96 06:34
AM ---------------------------

        ipp-owner @ pwg.org
        12/18/96 11:15 AM

To: don @ lexmark.com@internet, cmanros @ cp10.es.xerox.com@internet
cc: IPP @ pwg.org@internet, babakj @ microsoft.com@internet
Subject: RE: IPP> RE: Printer Instance Creation/Installation -Reply

On terminology:

Scott

--or --

--or--

<<RKD>> I think this goes back to our discussion in
<<RKD>> New Orleans of getting the PDL owners,
<<RKD>> Primarily Adobe and HP, to move feature
<<RKD>> handling out of the PDL and into IPP
<<RKD>> attributes. If they do this then a generic
<<RKD>> printer language driver for each of the
<<RKD>> major languages is possible isn't it?
Comments?

Don

network
do
new
driver"
printers
for a
downloaded

Carl-Uno

---

From: [email-masked]
Date: Fri, 20 Dec 1996 08:51:24 -0500

Classification:
Prologue:
Epilogue:

Following the thread of mail that has been annotated and re-sent several times
does get confusing.  It appears that different mail readers handle annotations
and line endings differently making it even harder.  I have adopted the
technique of manually keying in my comments on someone elses mail with my
intials <<RKD>> at the front of each line. If this is confusing, I will try
something else.   Perhaps someone has a sugegstion that we could all adopt taht
would help this problem.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/20/96 06:43
AM ---------------------------

        babakj @ MICROSOFT.com
        12/19/96 11:50 AM

To: Roger K Debry/Boulder/IBM, ipp @ PWG.ORG@??.ibm.com@internet
cc:
Subject: RE: IPP> RE: Printer Instance Creation/Installation -Reply

Am I the only one who has difficulty figuring out where the actual
message is (as compared to original message(s) being replied to) in
emails like the following?

Babak