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@novell.com
W: http://www.novell.com
************************************************************
>>> Larry Masinter <masinter@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.