Subject: PWG> IPP Protocol

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 3 Jun 1997 15:51:12 PDT

I am sending this for information to the PWG members, rather than to the
IPP list, for obvious reasons.

This is taken out of my internal monthly report:

ISSUES

The main challenge for the coming month is to catch up on the protocol work.
The decision to include the Microsoft/HP solution as a subset of IPP has
lead to some extra reworking of the Model and Protocol documentation, as
well as some additional issues, in particular relating to the IPP operations.

We will need to get into a serious discussion with the IETF management
concerning the recommendation from the San Diego meeting to use HTTP 1.1 as
"carrier" for the IPP. This decision still has to be brought up for final
agreement on the official IPP DL. I am waiting for the Protocol document to
get in better shape, before going into that particular battle. In worst
case, the IETF will not accept the Protocol mapping to go onto the IETF
Standards Track, but it could still become an Informational or Experimental
RFC.  Worst-worst case would be to move the project from the IETF to either
of: IEEE, ECMA or W3C.

Carl-Uno

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: "Steve Zilles" <[email-masked]>
Date: Tue, 03 Jun 1997 16:21:02 PDT

I realize that our area directors have not been ecstatic about HTTP, but
have they ever said that they would refuse and HTTP based protocol. We
have certainly said HTTP based at some point in every meeting to date.

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 3 Jun 1997 17:23:32 PDT

>have certainly said HTTP based at some point in every meeting to date.

Steve,

I am just trying to raise a warning flag.  Here a couple of recent comments
from our Area Directors, which you may not have seen:

>From Harald:

About the HTTP issue:
You got serious pushback in Memphis, and not only from us, that basing
IPP on HTTP was going to get you into trouble that you could avoid by
doing a "core" protocol and a "gateway from HTTP to IPP" rather than
doing straight "IPP over HTTP".
I think you are choosing a course that will seriously hamper the
future deployment and utilization of the IPP protocol, for reasons
that have much to do with marketing/politics and little to do with
sound engineering.
That is Not a Good Thing; you will probably require at least a
document called "Why We Shot Ourselves In The Foot With HTTP" or
equivalent, giving the *engineering* justifications for the choice.

>From Keith:

The problems I have with IPP using HTTP boil down to the following:

a) HTTP/1.1 is "ugly".  Due to a lack of foresight in its design (not
to mention more design cycles after deployment than most Internet
protocols) it has lots of complexity and implementation subtleties
that can cause interoperability problems.  A lot of the HTTP spec has
to do with making HTTP work with caches and proxies, which aren't
needed by IPP (though they may get in the way).  IPP needs to add even
more features to HTTP, which will make it even more complex.

b) When different communities use the same protocol for different
purposes, that protocol tends to evolve on separate evolutionary
paths. I have some examples of this in mind: Different uses of RFC 822
headers in Internet, BITNET, UUCP, and Attmail -- which have crept
into software that is still in use; differences between HTTP's use of
MIME and MIME use in email (some HTTP people insist on changing MIME
multiparts to optimize HTTP even if it breaks email software); SET's
misuse of MIME headers within set-* body parts, etc.)  

I'm sure you can think of plenty of examples of this from your own
experience.

Several groups want to reuse or extend HTTP.  I don't want to see
these groups working at cross purposes by each extending HTTP in a
different direction, and especially not by using the same methods or
headers in different ways.  (If too many groups go down this path we
may need an HTTP protocol review directorate to make sure that all
groups use HTTP consistently, much like the network management
directorate reviews MIBs.)
   
c) I believe the group's interest in using HTTP is at least partially
due to wanting to allow users to submit print jobs from a web browser.
I think this is mixing two or three problems -- human-to-spooler
interface, spooler-to-printer interface, and machine-to-spooler
interface, and trying to solve all of these in one protocol will
produce a protocol which is not very good at any of them -- or one
which is overly complex and doesn't interoperate well.  ("it's a floor
wax and a dessert topping...")  The simpler the framing protocol, the
more likely it is that implementations will interoperate.

But having said all of the above, I won't claim that HTTP/1.1 cannot
be made to do the job, or even that it's a hugely suboptimal choice.
It's just that the decision needs to be made very carefully.

Also, I've dealt with enough text-based protocols that designing a new
one that fits into IPP's requirements looks easy to me -- far easier
than making HTTP work well.  It might not look so easy from the point
of view of the average IPP contributor.  On the other hand, HTTP
experts are a lot more familiar with their protocol, so they know just
how to fit things in to HTTP's framework.  

The relevant question, I think, is: who will be implementing this
protocol?  Will they find it easier to wade through the HTTP/1.1 spec
and figure out which portions are relevant (and will different
implementors get consistent results), or do they need their own spec
that succinctly tells them what to do?

---

In total, none of them have stated that they would find an HTTP solution
totally unacceptable, but they certainly have rather strong opinions..

I my view, I think that we still have a major job of selling HTTP to
these guys, and it will not be easy. They do not accept marketing 
reasons for a start...

Carl-Uno
Carl-Uno Manros

---

From: "Steve Zilles" <[email-masked]>
Date: Tue, 03 Jun 1997 18:17:18 PDT

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