> -----Original Message-----
> From: James Walker [SMTP:walker@dazel.com]
> Sent: Wednesday, February 11, 1998 2:41 PM
> To: ipp@pwg.org
> Cc: Jay Martin
> Subject: Re: IPP> Does the world need a robust host-to-device
> network printing protocol?
>
> I have become more
> and more disillusioned with the comprimises that we make to try and
> satisfy both ends of the spectrum (embedded printers all the way up
> to fat print servers). Also, like some, I do not believe that HTTP
> has been the Holy Grail that we all thought it would be.
[Wagner, William]
Yes, there have been compromises (and some degree of excess),
but I suggest that an IPP compatible implementation embedded in a
printer is still quite feasible.
> The first is that most of the prints in the
> world go from a client to a print server, or process of some kind,
> and then to the printing device. There are very few (any?) cases of
> a client application talking directly to a printing device.
[Wagner, William]
This observation is open to interpretation. There is usually
something between the application and the printer, but that something
may be in the same physical device as the application or the printer.
So, from a network protocol point of view, there are quite a few
protocols that transfer a print job between a workstation and a printer.
I say that this implies that there is no requirement
> for a single protocol that solves both the client->server and
> server->printer cases. That was one of the things that we were trying
> to do with IPP.
[Wagner, William]
I think you are mistaken. From what I recall, IPP sought to
define a protocol between a client application and a logical printer.
That logical printer could very well have been an external server, in
which case the server to printer connection was not defined. Or, the
server could be embedded in the printer, in which case there was no
network connection involved.
> The second observation has to do with deployment. How many of us
> really believe that people are going to be hooking up raw printing
> hardware (i.e., printers) directly to the internet for people to
> print to? If an *inter*net printing protocol is going to be deployed,
> ya' gotta' believe that it is going to be on a high-powered print
> server/spooler of some kind. Although only a very small sample, I
> confirmed this with several system administrators (and a marketeer
> or two ;-). Once again, I think that this argues for separate
> requirements for the client->server and server->printer protocols.
[Wagner, William] I do not agree that users will not be hooking
up a printer intended to take jobs via the internet.
And unless you are defining server in a functional rather than
physical sense, I would not agree that a separate sever must always be
present. And, if you prefer to think of IPP as a client to server
protocol, that is just fine, recognizing that a server may not
necessarily be what and where you are accustomed to see it.