No, Alex is entirely correct, IPP should not be concerned with the transport
protocol other than having some requirement such as needing "a reliable stream
orientated protocol" (e.g., TCP) over which it can be sent. Using TCP directly
is far simpler than HTTP and HTTP is sent over a TCP connection anyway (it
doesn't have to be though, it just wants a reliable byte-stream as most appl-
ication level protocols) so you get less work not more. Removing HTTP from the
spec. also removes confusion as to how much of HTTP is required for TCP, e.g.,
which transfer encodings may be assumed by clients sending IPP via HTTP?
IPP's reliable stream connection *could* be implemented using a combination
of HTTP POST methods to a CGI program that understands IPP content contained
within the entity posted but that should be independent of the actual IPP
specification (i.e., if you really want to write it up then have another
draft or an appendix, don't clutter IPP with it). This approach would let
people use IPP without re-configuring their firewalls and send documents
over HTTP to some service that makes its IPP service available in this way
but this should be separated from the base protocol spec.
-- Andy Newman <andy@research.canon.com.au>