---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/06/97 12:50
PM ---------------------------
rturner @ sharplabs.com
01/06/97 12:32 PM
Please respond to rturner@sharplabs.com@internet
To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org@internet
Subject: Re: IPP> What is it we really need?
rdebry@us.ibm.com wrote:
>
> 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???
<<RKD>> Randy, who is "WE" in your note below? I disgree strongly
<<RKD>> with the point of view that we (printer vendors) provide
<<RKD>> the IPP layers for the platforms we are interested in. I'd
<<RKD>> like to see what other's think, but I think it is wrong!
<<RKD>> The IPP support ought to be part of the base OS, NOS, or
<<RKD>> browser.
At least for printing, we ARE the platform vendors, so we would supply
IPP service
layers for the platforms we are interested in supporting. We also have
most (if not
all) of the major commercial computing platform vendors as part of the
committee, so
the people we have to convince would basically be ourselves.
Like Keith said earlier, there is alot existing code out there, but that
doesn't
mean its necessarily the right place to start standardizing a printing
protocol.
Also, the existing code will not function without IPP enhancements, and
the bulk of
the work left to do (with regards to design and implementation) have to
do with
the protocol thats layered on top of TCP or HTTP.
<<RKD>> I agree that there may be lots of implementation issues,
<<RKD>> but I cannot find anyone who can provide real, concrete facts
<<RKD>> regarding them. I wish that we could find someone who could just
<<RKD>> tell us, here's the way it works and here's how it will screw up
<<RKD>> printing. Then we could make judgements based on how it really
<<RKD>> is, not emotion from purists who aren't going to have to implement
<<RKD>> this stuff and make it play in the marketplace. Can someone really
<<RKD>> show how caching, proxies or security as implemented for HTTP will
<<RKD>> mess up printing?
There are also alot of other issues that may come up and bite us when we
start
layering on top of HTTP, like caching, proxies, and security models. It
may end
up that the usage model of how HTTP is used for the majority of the
industry
(Web page browsing) may conflict with how we want to implement printing.
I heard
some very complicated usage models come up at the HTTP working group
meeting in
San Jose, with regards to caching and proxying. These algorithms and
configurations
may conflict with our simple requirements of submitting a print job and
checking
status. There are also authentication and authorization issues with
regards to
HTTP that might not work the way we want them to for printing.
I guess what I'm saying is that if you select HTTP as the transport, you
have to
accept alot of the baggage and disadvantages of using HTTP, along with
the good
aspects. And that extra baggage of issues and dependencies may not
balance out
equally with the advantages of existing code. It may be a very hard pill
for the
committee to swallow.
Randy
>
> ---------------------- 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@sharplabs.com@internet > > To: ipp
@ pwg.org@internet > cc: moore @ cs.utk.edu@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@sharplabs.com
-- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com