IPP> What is it we really need?

IPP> What is it we really need?

IPP> What is it we really need?

Randy Turner rturner at sharplabs.com
Mon Jan 6 15:59:29 EST 1997

rdebry at us.ibm.com wrote:
> Classification:
> Prologue:
> Epilogue:
> ---------------------- 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 at sharplabs.com@internet
> To: Roger K Debry/Boulder/IBM
> cc: ipp @ pwg.org at internet
> Subject: Re: IPP> What is it we really need?
> rdebry at 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.

Right, and we have base OS, NOS, and browser people on our committee 
(Sun, IBM, Microsoft, Novell, Netscape, etc.). Which is why I think we
ahead of the game if we have the right folks already on the committee.
we do a good job with this, the decision on whether or not to include
on a particular platform will hopefully be moot, since we also have
98% of the printer vendor market represented within the PWG. The OS
might not have much choice.

> 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?

Do we have a current spec. that outlines in detail how IPP would use
a transport for job submission and status? If we do, maybe someone with 
knowledge about how caching/proxying systems work could analyze our spec
with regards to these issues. But I think empirically (in the absence of
specific examples of problems), that we have a long road
to travel with regards to ubiquitous interoperability among various
topologies. It might be quicker just to spin our own environment. I'm
not coming
down on the side of either HTTP or a new protocol, just trying to make
that the committee understands HTTP is not a panacea for acceptance or
deployment of a protocol for internet 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

Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com

More information about the Ipp mailing list