Although the message you posted to the IPP is a bit incomplete (ie, it
appears another message from you to Carl is referenced that appeared
to discuss more details), I think I know where you're heading with this
topic. And, despite how you might read my comments below, I actually
favor your type of approach than that currently embraced by most of the
other IPP folks.
Your approach (and the one I believe is worth working on right now) is
more akin to a "traditional" client/server transaction protocol, designed
in much of the same vein as many other common IP protocols (eg, ftp,
smtp, etc).
The IPP is currently embracing a protocol that is 100% leveraged on top
of HTTP, in both semantics and syntax.
Either approach could use MIME encodings, although the HTTP-based approach
benefits from MIME more so. (Not an issue here.)
The thing is, one of the *top-most* goals of the IPP is to preclude the
need for server-side extensions of any kind; that is, "stock" HTTP server
implementations could be used right out of the box, with no requisite
plug-in's or similar software involved.
We have always realized that the IPP could propose a new URI "scheme"
(eg, "ipp://") to effect job protocol interactions, but this would require
changes to stock server implementations. Hence, this approach was not
favored.
While it has never been stated in quite this fashion, the strong disposition
toward using HTTP stems from the desire to use a stock HTTP server as a sort
of "object invocation" vehicle; that is, be able to use CGI-like program
invocations to respond to protocol requests. (In this case, the HTTP server
acts as an extremely lean-n-mean ORB mechanism...well, sort of, anyway ;-)
If a straight-up "traditional" protocol design is used, then many of
the implicit features and benefits of stock HTTP servers will not be
readily available. This, I believe, is the real motivation for using
HTTP as the foundation of the IPP protocol. (If I'm wrong here, then
someone should speak up now, since HTTP is probably the worst approach
one could take for a printing protocol, IMHO.)
If all the world really wants right now is a standard network printing
protocol, then there are plenty of candidates from which to choose. No
need to reinvent the wheel here, at least not from scratch, anyway.
Perhaps the real question is whether that's all the world really wants
right now. At the IETF BOF in San Jose last month, there were many folks
who lobbied for "just the simple printing protocol for now, thank you."
And to that end, I agree 100% (for over three years now...)
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------