IPP Mail Archive: RE: IPP> Host to device

RE: IPP> Host to device

Turner, Randy (rturner@sharplabs.com)
Sat, 4 Apr 1998 04:50:39 -0800

Once I get a draft in more or less complete form, I think you will find
the implementation burden to be far less than IPP over HTTP. Once we
start actually doing interop with a variety of HTTP servers or clients,
I think we will see that in order to properly interoperate in the HTTP
world (HTTP 1.1), that we will have to have several iterations of
interop to get things even close to handling the variety of HTTP
client/server environments that exist. I am mainly concerned with issues
like:

1. The fact that Apache is the most widely used and deployed
HTTP server in the market, and it doesn't support chunking through the
CGI interface.
2. Realizing that there will be problems using things like
"chunking" to currently deployed hybrid HTTP 1.0/1.1 servers.
3. Tunneling issues with security, through HTTP proxies.
4. HTTP proxy response caching.

There are other issues with proper handling of HTTP headers and status
codes that I won't go into in this note. None of the above issues are
issues for my transport proposal. In my opinion, the burden of
implementation is quite high with HTTP, much higher than what is implied
by my proposal. I think the burden is high whether you roll your own
HTTP or license the code from an outside vendor. Not that I'm trashing
our decision to use it as a transport. I still think it is viable, but
it is a very non-trivial design issue for both IPP clients and servers.

Randy

-----Original Message-----
From: don@lexmark.com [SMTP:don@lexmark.com]
Sent: Friday, April 03, 1998 1:22 PM
To: rturner@sharplabs.com
Cc: Rdebry@Us.Ibm.Com; Ipp@Pwg.Org
Subject: RE: IPP> Host to device

Randy:

My biggest concern is that your proposal is TCP/IP only. Is
does not solve
the problem for printers connected to servers via:

- Parallel
- Serial
- USB
- 1394
- IPX/SPX
- AppleTalk
- DLC/LLC
- etc., etc., etc.

If I'm going to use TCP/IP then I might as well go ahead with
the HTTP
based implementation. You don't provide more status and control
or
anything else that really buys me anything other than a slightly
lighter
transport. It's just not work the trouble for the return on
investment.

Don

**********************************************
* Don Wright don@lexmark.com *
* Product Manager, Strategic Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************