Somebody said this:
> I have not heard anything yet that suggests that defining a new
> protocol on TCP/IP makes the implemetation easier (Angelo's comments
> only say it is no harder -- and once he has written an imbedded
> server, why not reuse it as opposed to yet creating something new
> again?), will get us support on the dominant platforms quicker, or
> solve security or performance problems.
Put it this way:
1. If you use full HTTP to define IPP, you have to go through every
feature of HTTP and specify how it interacts with printing, just to
make sure it doesn't cause any problems. You have to specify how
printers and print clients interact with web cache servers, proxy
servers, and web browsers. You should probably also define how to
keep Lycos, AltaVista, etc. from indexing your printer.
This is *in addition* to defining the commands that talk to the
printer the format of the responses, the set of printer attributes,
etc.
So I claim that the protocol *specification* will be longer and more
difficult to write if you use HTTP.
I also claim that the resulting protocol will be less reliable.
Having all of those HTTP headers in there just creates more
opportunities for different behavior between client and server. More
protocol states means more bugs.
2. On the other hand, if you use HTTP-lite, you can avoid the first
step, and keep the protocol simple.
In my mind, HTTP-lite consists of:
+ a general syntax for commands (or if you prefer, method invocations),
+ a general syntax for responses,
+ a set of security flavors, and
+ a minimal set of error codes
all of which are borrowed from HTTP, but with none of the methods,
and only a couple of the header fields that are used in HTTP.
The point of HTTP-lite is *minimize* the difficulty of defining and
implementing new application layer protocols, by separating the part
of HTTP that you really want to be able to reuse, from the parts that
are (a) crufty from lack of foresight in HTTP's design, and (b)
heavily optimized for the web.
Even for a box that supports both IPP and HTTP (the latter for
configuration), you should be able to implement HTTP/1.1 on top of
HTTP-lite without adding significant complexity to the HTTP
implementation.
Keith