IPP Mail Archive: Re[2]: IPP> PRO,MOD> User model for clients

Re[2]: IPP> PRO,MOD> User model for clients

Bill Wagner (bwagner@digprod.com)
Wed, 29 Jan 1997 11:23:20 -0500


These interchanges show confusion in semantics and word-games that are
misdirecting attention from the main objective.

1. Browsing for status using a standard IP browser is done now, by DPI
(http server in the NIC) as well as Lexmark and others. If the spec
says that "all" interaction is done via POST, I think that is an error
in the spec; that is neither reasonable nor workable.

For general access, it does require that the printer be outside of the
firewall. DPI's is accessible with a URL derived from the IP address
(http://199.93.124.110/)

2. Printing is a different question. It seems particularly cumbersome
to use a browser to submit print jobs (print to file using the
appropriate driver, and then transfer the file using the browser??)
Except for some special cases where the print file is already
available, this mechanism seems unreasonable. Users will expect job
delivery to be seamlessly linked to their application (Indeed they may
also expect printer selection to be done automatically.) I don't think
that there is any argument but that this requires a redirector either
built in or loaded.

I would expect that this redirector could be obtained directly or
indirectly from the printer accessed for status/configuration
information by a standard browser.

I think there is agreement on these points.

Then, the question might be, once you have loaded a redirector, why
continue to use HTTP for job delivery? Why not FTP, or some new custom
built layer? The primary argument for HTTP appears to be to evade the
firewalls. But I suspect that:
a. the vast majority of printing is done locally, so getting past
firewalls is inapplicable for most print jobs
b. if there is some perceived reason to keep print jobs from going
out, then the use of HTTP will not prevent firewalls from being
enhanced to fill this loophole
c. even stating this as an objective is regarded as a challenge to
the keepers of the firewalls

Is there some other compelling functional reason to use HTTP for job
delivery?

Bill Wagner, DPI

______________________________ Reply Separator _________________________________
Subject: Re: IPP> PRO,MOD> User model for clients
Author: Don Wright <don@lexmark.com> at Internet
Date: 1/29/97 7:56 AM

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