Subject: Re: IPP> PRO,MOD> User model for clients

From: Don Wright <[email-masked]>
Date: 28 Jan 97 14:51:17 EST

Randy Turner and I have previously said....

>> = FDW
> = RT

>> 
>> 2) Printing to a remote printer from an application on the
>>      client (eg Word, Lotus 123, etc.) requires something
>>      I'll call an IPP driver to be installed on the client.  Perhaps
>>      this is downloaded from the Web or comes as a part of
>>      a new operating system but there's got to be some type
>>      of "redirector" installed.  "Push" and "Pull" printing can be
>>      accomplished from a properly written WEB page and
>>      an unassisted WEB browser, but transparent printing
>>       from an application to a WEB printer requires additional
>>       software.
>
>The above sentence with regards to "properly written WEB page" 
>is not germain to IPP. We don't want content architected to be
>compliant with IPP. WEB authors should feel free to do whatever
>they want and not constrained by having to know how to have their
>content printed.

What I meant here was the WEB page for the print server.  That
page must be written so as to provide a place to type in a URL
if the print server is expected to go out and retrieve the URL and
then print it ("pull model") and if it is written so the user can type in
a local file name and have it "pushed" to the server.  This has
nothing to do with a vanilla page off the WEB.

>> 
>> This is consistant with the directions I have seen from
>> several vendors working on solutions in this area.  I
>> don't think any solution (HTTP, TCP Stream, etc.) can
>> solve the problems you mentioned without a new
>> "IPP Driver" being installed on the client.

>I think this statement is true as well, and if we want to rely
>on HTTP and browsers to deploy IPP, it complicates things 
>dramatically. The user now has to know (or someone has to
>know) what type of browser (and platform the browser is running
>on) in order to properly provide the appropriate "driver" which
>I'm not sure if the term even applies to anything except the
>windows printing environment. 
>
>I think the best technical solution for this would be to ask
>browser vendors to rethink their logic when the "Print" 
>button is selected in their respective user interfaces. We need
>a hook into this process (maybe some sort of java applet) that
>handles printing over IPP. If the applet is loaded, it tries
>IPP, and if not loaded, it defaults to whatever platform
>printing environment is in use. Of course, this would render the
>existing installed base of browsers incapable of doing IPP.

This is all well and good if you can get the Browser developers
to do anything for printing other than call the OS specific print 
APIs.

>The driver solution is going to be complicated and frought with
>issues (possibly licensing), and platform-dependence questions.
>I'm not saying it's impossible, it just severely gets in the
>way with our focus on designing a simple IPP.

It's our job to find a way to make this as painless as possible.

>Some of the issues with driver installation might include:
>
> 1. What browser is the user using?

Available from the browser

> 2. What OS platform is the browser installed on?

Available from the browser

> 3. Where do I get the driver? 

Possible solutions including "Ask the printer?"  "Administrator 
configuration", others

> 4. Who will write the drivers and are there
>    licensing issues involved?

All printer manufacturers love to give away their drivers through
as many sources as possible.  It means they are selling more
hardware and using up supplies.

> 5. Will each IPP server have to have all possible
>    platform/browser combinations of drivers loaded to
>    support the widest possible audience?

All the ones they are interested in supporting.

> 6. Will driver installation require administrator
>    intervention?

Only if administrators set-up the machines that way.  Tough
luck if they do without including some generic drivers.

> 7. Will the user have to restart the OS or browser
>    or both after installation? (and this varies depending
>    upon the OS/print driver environment).

Usually not but if so I suspect the OS vendor will find a 
work around to meet customer requirements.

Don

---

From: JK Martin <[email-masked]>
Date: Wed, 29 Jan 1997 03:21:25 -0500

Randy has posed some compelling questions that should serve to
clarify the IPP direction, and perhaps to some extent, its viability.

Don suggested a few answers to these questions that might raise

> Possible solutions including "Ask the printer?"  "Administrator

Too many times "Administrator configuration" equates to "Sweep it
under the carpet" in systems design.  Let's make sure we don't
find ourselves repeatedly saying things like "That topic is 
implementation-dependent...it's up to the vendor to decide."

Let's be straight here.  If IPP reaches the kind of potential most
folks have been talking about over the last few months, we're about
to propose a major shift in the design of printing systems for the
average Enterprise.  If "Administrator configuration" is the response
to a question, then hopefully we will be willing to delineate how
such configuration should be performed, if not via explicit rules,
then by strong guidelines backed by proven reference implementations.

> hardware and using up supplies.

Perhaps an intermediate mail transfer agent ate up Don's smiley
faces on this response.  ;-)  Seriously, the printer vendors I
have spoken with consistently bemoan the continued give-away of
such printer drivers.

It's going to be tough to write such drivers if it ends up that
the browser vendors must become deeply involved in making the
client side of IPP work in a clean and robust fashion.

Just some thoughts.

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