Thank you Carl-Uno for the very good overview of the nature of the problem.
It is relevant to ask ourselves why HTTP 1.1. Having sat thru several
different discussions I would put forth the following reasons as an
begining outline of why we are proposing HTTP 1.1
#1. It is there! Yes, it is big and ugly, but it is there and many
organizations have already had to implement it. An ugly duckling in the
hand is worth more than two in the bush (excuse the mixed proverb).
#2. We are not extending HTTP. We are using it as it is already
defined. In principle, what we are doing would work with HTTP 1.0, but
that would not be in the spirit that caused HTTP to be "fixed" via
1.1. We are using POST to transmit data that is interpreted by the HTTP
server. All the IPPness is the message not the protocol by which it is
transmitted. (Yes, there are somethings that must be done with HTTP
headers that put some of the message there as well as in the message,
but this is not essential to our use; it is simply required by HTTP.)
#3. Because HTTP is widely deployed, it solves some problems. For
example, it likely to be available on most interesting network print
client platforms. It also has been accomodated by most firewall
software. (It is recognized that this is both a feature and a security
problem.)
#4. The complexity of HTTP 1.1 is real, but there seem to be efforts,
such as the trial checklist floated by Jeff X, to help implementers
determine what they must do to acheive compliance with the spec. Most of
the HTTP 1.1 complexity comes with implementing a proxy and not in the
client or server so this is less an issue than it might otherwise be.
#5. Please add your own suggestion.
I think we need to build this list into a document. We did discuss such
a document at the meeting in Austin and it seems time to complete this
work now that we seem much more committed to HTTP 1.1.
Steve