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@sharplabs.com