Wagner, William wrote:
>> The arguments suggest that IPP cannot deal with both the intra and
> internet, and with both printers and servers. These apprehensions had
> been addressed over the past year, although perhaps not to your
> satisfaction.
I disagree; I believe that the arguments suggest that IPP will not be
able to deal with all ends of the spectrum effectively. It is one
thing if it is just meant to be a quick-and-dirty protocol to get
print jobs over the internet. It is quite another if it is meant to
be the next end-all-be-all protocol that covers all ends of the
spectrum, from full-blown internet-connected print servers to
departmental intranet-connected print devices.
> ...
>> > 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.
Feasible or desirable? And, as we press on, trying to add more and
more features and capabilities to satisfy the feature-hungry print
servers, will it still be feasible? Or will we continue to make
sacrifices so that we do not leave out the embedded printer market?
You know, what has led me down this path is what I call "the
embedded printer stick" that can be pulled out at any time to
whack us application guys over the head. "No, we can't do that;
it might take an extra 25K!" Well, those people are absolutely
right to defend their turf. But at what cost? Once again, do we
lose by trying to server two masters?
> > 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
Yes, there are "quite a few protocols that transfer a print job between
a workstation and a printer"... and that is the problem! Look at all
of the people that are calling for a host-to-device protocol; they
are all people whose software (or firmware) has to drive print devices
from a number of different manufacturers. Yes, the software people
(DAZEL, Microsoft, Underscore, etc) and hardware bridge people (i-data)
are saying that they would all like one complete robust standard
whatever-to-print-device protocol.
> > 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.
I do not believe that I am mistaken. I believe that you just said
the same thing that I did. You are right when you say that IPP is
a protocol to go from a client to a logical printer. And, you have
described variability at one end of the connection; i.e., the logical
printer can be a print server or the actual print hardware. But,
remember that there is variability at the other end, too; i.e.,
the client that you mention can either be the true client that is
generating the print request, or it can be a print server. So,
we end up with a protocol that people think should be appropriate
for client->printer, client->server, and server->printer.
And, once again, it is the "server to printer connection" that many
of us are talking about. We would like to have an industry standard
way of driving print hardware in an enterprise environment.
> > 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.
Well, as I said it was a small sample. And all are allowed their
subjective opinion. It is the opinion of myself and others that
I talked to that, if *inter*net printing is going to be deployed,
it will be done with a piece of software between the world and
that printer.
> 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.
Huh?
...walker
--
Jim Walker <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX