The protocol/white paper that Roger published talked about using
the HTTP "POST" method for job submission, and I think that is
what most of us assumed would be used for IPP. The existing
installed base of browsers have designed their printing subsystems
to be platform-independent (i.e, under Sunos/Solaris they default
to lpr/lp, and under Win95/NT, they use the windows print system).
When the user is looking at a particular page (any page from any
content hierarchy) and wants to print a particular page, he/she
will be very tempted (using the currently installed base of
browsers) to print the way they are used to printing pages, via
a "Print" windows control or from the "File" pull-down menu. If
we are using the "POST" method, and utilizing some form of
multipart FORM "POST" through IPP, how do we enable this for any
page the user might be viewing? If I'm looking at a copy of the
online Wall Street Journal and want to print information about
a particular companies earnings report on a remote IPP printer,
using the built-in "Print" facility within the browser will not
work, 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. And
this would not be a cross-platform, open way of handling this.
Maybe I'm missing something very simple, but we are modeling this
type of usage model and I'm having some concerns about not being
able to "tailor" the client environment for IPP printing, which
would all but eliminate alot of the rationale for using HTTP.
Let me know if I've completely forgotten something that we've
already worked on, I have missed a couple of teleconferences.
Randy
-- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com