> > 1) Browsing for printer status, queue status, etc. requires
> > 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.
Here you are clearly wrong. Lexmark's MarkVision for
the WEB is able to provide printer and printer Queue status
on unmodified, unassisted browsers today. If our scenarios
and models do not support this mode of operation then a
grave design error has been made.
> > 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.
Again, you are flat wrong in assuming that adding a redirector means
I can't use the existing browser. Once I have users accustomed to an
interface i.e. a browser, then adding a plug-in or a new redirector
(replacing or supplementing their IPX/SPX, NetBEUI, etc. redirector)
why not stick with it?
Call me a fool, but I have no interest in inventing a new TCP stream
and requiring firewall makers to open up that stream for clients
inside a firewall. While "public" printers will need to be outside
the firewall for this HTTP mapping to work. Clients can be anywhere.
Don