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

From: Babak Jahromi <[email-masked]>
Date: Tue, 28 Jan 1997 20:27:08 -0800

No, you are making too many consclusions here. No once said having just
a plain browser and a plain Web server can magically realize IPP! On the
server side, you will obvisouly have to implment a CGI, ISAPI, etc. On
the client side you will have to add a driver. But the argument is that
using the existing "stock" Internet client and server software makes
implementing these components far easier than diving down to TCP
programming.

Babak

>
>> > 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
>
>Exactly! And that was my counterargument against the "we can use
>standard Web servers and browsers." You simply cannot.
>
>> >      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.
>
>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.
>
>> > 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.
>
>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

---

From: Alex Bochannek <[email-masked]>
Date: Tue, 28 Jan 97 22:18:44 PST

> implementing these components far easier than diving down to TCP

OK, so what you are saying then is:

 - A specialized print client is required on the client side
 - A specialized print server is required on the server side

And why do you think again that using HTTP is such a great idea?

Come on people, it should be totally obvious by now that the
modifications necessary to "stock" software is just as much, if not
more than writing the driver to use a socket directly PLUS you have to
consider all the possible corner cases of what happens with special
HTTP handling (like caches) and new versions of HTTP.

I am not sure why Babak keeps arguing that implementing to a socket
API is so much harder than some other, higher level API. If that's the
case for the particular platform he is concerned about, then one must
wonder about the platform he is using. Without diving into the "NT
print servers are going to take over the World"-discussion, I do want
to point out that at least one developer of printer drivers (Hi
Angelo!)  is perfectly happy to write to the socket layer since the
much touted development tools simply are not available in that case.

I would really appreciate it if people could comment on the proposed
TCP socket mapping I sent out earlier this week.

Thanks.