>>- The reasons why many of us felt that HTTP is a poor choice for printer
> operations are two:
> - HTTP is a badly designed protocol.
> HTTP/1.0 is ill-defined, unreliable and network unfriendly.
> HTTP/1.1 is a lot better, but has to lean over backwards to be
> backwards compatible.
> - Lots of things in the world do special things with HTTP, like caching,
> proxying and so on (the "baggage"). If you do printing through HTTP,
> all those things will happen to printing too, whether they make
> sense or not.
> Our experience wrt the firewall argument is that lying to your security
> staff is unwise - if printing is to be allowed through a firewall, it
> can be turned on; if it is not to be allowed, the security staff will
> get you no matter how you hide it sooner or later.
> Making life easy for a firewall is a *feature*, not a bug.
Why would the security staff want to disallow printing across the
firewall? To protect the intelectual properties of the corporation? In
that case are they going to disallow emailing across the filewall? After
all you can always submit the print job as just plain text via email.