At 04:21 PM 6/3/97 PDT, Steve Zilles wrote:
>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.
>>
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:
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.
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
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: manros at cp10.es.xerox.com