IPP Mail Archive: Re: IPP> review of IPP documents

Re: IPP> review of IPP documents

Keith Moore (moore@cs.utk.edu)
Fri, 05 Jun 1998 17:17:40 -0400

> > Excellent point. So why the heck are we using HTTP for IPP?
>
> Although one could take this as a facetious response, it always seems
> to me be an important question worth asking again. If IPP and others
> are approved as standard application protocols built on top of HTTP,
> then this is a green flag that HTTP is an acceptable transport for
> application protocols. And we will see more.

Yes. There's a lot of interest in layering other things over HTTP,
for reasons including:

mindshare
firewall/proxy/NAT compatibility
leveraging SSL/TLS
ease of prototyping using CGI and/or client libraries

However, several different uses of HTTP tend to pull the protocol in
several different directions, and potentially use it in ways that
conflict with one another. For example, you don't want a request or
response header used slightly differently by X-over-http than by
Y-over-http, because this might confuse proxies, or require slight
tweaks to client libraries. Similarly for use of HTTP error codes by
different protocols. And you want to make sure that firewalls can
distinguish X from Y.

HTTP is already very complex, and having lots of special cases for
different protocols doesn't make it any simpler.

> So, is the IETF supporting (even encouraging ?) application protocols
> to be built using HTTP as a transport? Or are these protocols that
> are currently being developed (IPP, WebDAV, etc) just considered test
> cases to see if the idea will fly?

I see IPP as breaking new ground in this area. Ideally, IETF should
have an RFC with guidelines for how to layer protocols on top of HTTP
(and TLS), so that future groups won't have to suffer as much as IPP.

WebDAV is a special case...because it's basically manipulating web
pages, I see it as an extension to the HTTP service rather than a
separate protocol layered on top of HTTP.

Keith