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

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

Randy Turner said, in part:

>...unless the user has previously installed some type of 
>Windows networked IPP redirector in the system, but I don't think
>we can require this, at least in the prioritized set of things we
>want to do, the driver loading has been moved down the list.

1) Browsing for printer status, queue status, etc. requires
     nothing additional on the client.

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.

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.

Don

---

From: Randy Turner <[email-masked]>
Date: Tue, 28 Jan 1997 10:54:08 -0800

>From what I've seen, I think this is true, assuming the existence
of a directory service, which is what we are planning on. However,
this may not be true with some existing non-LDAP capable browsers.

>       from an application to a WEB printer requires additional

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.

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

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.

Some of the issues with driver installation might include:

	1. What browser is the user using?
	2. What OS platform is the browser installed on?
	3. Where do I get the driver? 
	4. Who will write the drivers and are there
	   licensing issues involved?
	5. Will each IPP server have to have all possible
	   platform/browser combinations of drivers loaded to
	   support the widest possible audience?
	6. Will driver installation require administrator
	   intervention?
	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).

These are just off the top of my head, maybe someone could
elaborate on these.

Randy

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

---

From: Alex Bochannek <[email-masked]>
Date: Tue, 28 Jan 97 19:15:13 PST

> >      nothing additional on the client.

I believe this to be incorrect. If I recall the protocol specification
correctly, you planned on using POST for everything. I would be
curious to find out how the client will create the IPP command
string that is sent in the POST.

> >      I'll call an IPP driver to be installed on the client.  Perhaps

Exactly! And that was my counterargument against the "we can use
standard Web servers and browsers." You simply cannot.

> >       from an application to a WEB printer requires additional

Again, I am curious how one would implement the Push function. To the
best of my knowledge, the only time a client would send a POST is if
you have a FORM with ACTION="POST" and the user clicks the SUBMIT
button. But even then the returned POST body would be of format:

name=value&name=value&name=value

How would you ever get an IPP message?

And as far as the Pull printing, the security implications and
administrative hassle of each desktop having to run an HTTP server
cannot be overstated.

> > "IPP Driver" being installed on the client.

One more argument why "we can use standard Web servers and browsers"
is simply not true and why using a TCP Stream is no harder.

--
Alex Bochannek                 Phone & Fax : +1 408 526 51 91
Senior Network Analyst         Pager       : +1 408 485 90 92
Engineering Services           Alpha Pager : (800) 225-0256 PIN 104536
Cisco Systems, Inc.            Email       : [email-masked]
170 West Tasman Drive, Bldg. E Pager Email : [email-masked]
San Jose, CA 95134-1706, USA