I think Roger (correct if I'm wrong, Roger) meant that IPP, as currently
defined, is the correct solution for server-to-printer protocol, IF the
printer device already has an embedded web server, like would probably
be used for overall management. And if this is the assertion, then I
tend to agree with it, although it depends on what the exact
*requirements* are for server-to-printer protocol.
Randy
-----Original Message-----
From: don at lexmark.com [SMTP:don at lexmark.com]
Sent: Tuesday, February 17, 1998 7:24 AM
To: ipp at pwg.org
Subject: IPP> Re: Suggested workplan - host to device
protocol
Roger deBry said:
>Assertions:
>
>(1) IPP, as it is currently defined, is the correct protocol
> for client to server, across the Internet.
>
>(2) IPP, as it is currently defined, is the correct protocol
> for client to server, across an Intranet
>
>(3) IPP, as it is currently defined, is the correct protocol
> between a server and a printer which contains an
> imbedded server.
I can easily agree with Roger on #1 and #2. I think where
the problem lies is with #3. I am not sure how broad the
definition of "imbedded server" is? Does that mean imbedded
IPP server or any server? All of my network printers today
have available what we call an Internal Print Server which
supports a wide range of protocols. Is that what you mean
Roger? I don't think so. I think the definition needs to
be "imbedded, spooling print server." And even then, I think
we have lost a huge amount of control and status information
that is available from TIPSI or even SNMP. Maybe we need
to define some kind of passthrough for IPP that allows
the control and status information for the down and dirty
hardware to be retrieved and set through IPP??
Comments?
**********************************************
* Don Wright don at lexmark.com *
* Product Manager, Strategic Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************