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.
> > 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 : abochannek@cisco.com 170 West Tasman Drive, Bldg. E Pager Email : abochannek@beeper.cisco.com San Jose, CA 95134-1706, USA