Classification:
Prologue:
Epilogue:
Randy, can you help us all to understand the "cost" issues? I for one do not
know what the cost of implementing HTTP or HTTP-Lite would be. What I do know
is that there is lots of HTTP server code out there that I can re-use, thus
substantially shortening my development time. Furthermore, if a printer
manufacturer puts HTTP in the printer to support configuration (as Tektronics
has and others have said they will do) then it will be there anyway, so why not
use it? And, while I agree that we need to be careful about tying printing
protocols and the web together, I would hate to see us re-inventing (and
reimplementing) everything that already exists in HTTP when we need it.
Finally, I think that the most compelling argument is the one of wanting to see
ubiquitous support across the major industry platforms -- both as clients and
as print servers. HTTP WILL BE supported on all of the interesting clients
and server platforms! How do we convince the platform vendors to build support
for a new protocol???
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97 11:36
AM ---------------------------
ipp-owner @ pwg.org
01/06/97 11:00 AM
Please respond to rturner at sharplabs.com@internet
To: ipp @ pwg.org at internet
cc: moore @ cs.utk.edu at internet
Subject: Re: IPP> What is it we really need?
Keith Moore wrote:
>> ..snip..snip..
>> If nothing else, printing protocols and the web each need to evolve
> separately; we need to be very careful about how we tie them together.
>> Keith
I think we need to decide whether or not we are doing IPP or WPP
(Internet Printing Protocol or Web Printing Protocol)
The statement made by Keith (included in this msg above) I think is
crucial. I haven't thought about the ramifications (and permutations)
of tying a printing protocol to another N-numbered set of technologies
like HTTP, LDAP, CGI, and HTML (if we decide to use forms). It looks
like it might be more than we want to get into, at least from an
interoperability and maintenance standpoint.
At any rate, we need to think about someone that wants to do
printing across the internet, but does not want to be burdened with
the cost of implementing HTTP (or even HTTP-lite).
In this same vein, it would be very difficult to account for IPP
usage if we "hide" the IPP protocol within a set of HTTP accesses,
using the HTTP TCP port number, for example. This echoes the
ideas expressed by Alex earlier, and would also allow net-admins to
create policies that enable/disable HTTP and/or printing as
separate applications, something that sounds desirable IMHO.
Randy
(Good luck sorting this out in New Mexico ;)
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com