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
are
ahead of the game if we have the right folks already on the committee.
If
we do a good job with this, the decision on whether or not to include
IPP
on a particular platform will hopefully be moot, since we also have
roughly
98% of the printer vendor market represented within the PWG. The OS
vendors
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
HTTP as
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
Web-based
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
sure
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