Also, isn't some of the baggage in the growth path of HTTP good? When
we first proposed LDPA (Lightweight DPA) we propsed it on top of the
Internet RPC mechanism. RPCs supported MUCH of what would be
required for printing!
- at-most-once and at-least-once operations
- authenticated conntections
- sessions (which some may argue is needed for managers)
- privacy options
- negotiation of QOS
- etc.
I personally agreed to go down the HTTP road assuming that we would
be ON the the main road (the growth path of HTTP) rather than some
detour side path where we are forced to grow everything we need
again.
In HTTP, is is possible for the client to send a job, the printer bogs down
in printing it, it never responds, and the client times out or the HTTP
server stack times out waiting for the CGI script to finish, and then
resends the job and the job is printed twice? This is a nuisance for
some print jobs, and a critical error for others (airline tickets, checks,
etc.) I am not assuming that IPP will solve all of these scenarios, but is
there a path to get there at least? Is HTTP that path? Is HTTP lite that
path? I doubt it. It seems to me that if we roll our own, we will just end
up developing a new kinds of RPC.
A side note:
It seems like caching and proxies is only an issue on GETs. As was
pointed out in the BOF, most of the IPP operations will probably be MIME
encoded requests in a PUT with the response coming back in the
response to the PUT. Most caches and proxies are being optimized for
the "other way round". However, I agree with Keith, that all of the work
being done for HTTP/1.1 and beyond is NOT taking the needs of printing
into account!
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************
>>> Larry Masinter <masinter at parc.xerox.com> 01/06/97 02:56pm >>>
> If a response includes
> Cache-control: no-cache
> then there should not be any difficulty with IPP and caching.
> Print clients shouldn't need to say anything about caching, just print
> servers, and the only thing servers need to say is about cache expiry
> for information that shouldn't be cached.