Subject: RE: IPP> HTTP vs. HTTP-lite

From: Babak Jahromi <[email-masked]>
Date: Mon, 6 Jan 1997 14:35:24 -0800

I doubt there is a golden document somewhere that specifies how the
browsers exactly deal with the all caches and all flavors of proxy
servers around. It works like everything else in Internet community:
loose consensus and running code. Why does IPP have to be special? If
you want to resolve every caching and proxying scenario before releasing
IPP, you will never manage to do it.

>1. If you use full HTTP to define IPP, you have to go through every
>feature of HTTP and specify how it interacts with printing, just to
>make sure it doesn't cause any problems.  You have to specify how
>printers and print clients interact with web cache servers, proxy
>servers, and web browsers.  You should probably also define how to
>keep Lycos, AltaVista, etc. from indexing your printer.
>
>

---

From: Larry Masinter <[email-masked]>
Date: Mon, 6 Jan 1997 13:56:37 PST

# I doubt there is a golden document somewhere that specifies how the
# browsers exactly deal with the all caches and all flavors of proxy
# servers around.

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.

It more likely a feature that static information returned from
querying a printer about its configuration can be cached.

Larry

---

From: Randy Turner <[email-masked]>
Date: Mon, 06 Jan 1997 14:51:31 -0800

> IPP, you will never manage to do it.
You can't just gloss over all of the issues with regards to
printing over HTTP by using the "standard interfaces". Those
standard interfaces were not designed to transport print jobs,
but were designed around the transient nature and assumptions
that can be made regarding the consumption of data by interactive
web browsers; you've got some very basic design philosophies with
HTTP and proxy/caching algorithms that just might not jive with
print jobs.

A good example of this is how the search engines indexes data,
as stated by Keith below:

If you want to deploy something and let the user community work
out all the details, I think this would be the wrong way to go.

Randy

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 Jan 1997 18:33:39 -0500

> loose consensus and running code. Why does IPP have to be special? 

The problem is that the HTTP people are assuming use of HTTP for
*their* environment, not yours.  Those assumptions are sufficiently
different from printing that they need to be re-examined.  And
re-examining those assumptions is going to be *this* group's problem
if it decides to go down that path.

The question in my mind is not "Why does IPP have to be special?"
but "Why should IPP specify the use of a knife blade when the task 
requires a screwdriver?"  Sure it will work in a pinch, but what
you're left with is neither a good screwdriver nor a good knife.

We've seen this at least twice before in the evolution of Internet
protocols.  FTP was layered on telnet; this caused a conflict between
FTP transfers and telnet NVT processing and option negotiation.  Mail 
delivery was originally layered on FTP, which worked so badly (even 
at the scale of the Arpanet) that SMTP had to be designed to replace it.  

> If you want to resolve every caching and proxying scenario before releasing

That's precisely my point.  Does this group want to get bogged down 
in this or not?

Keith