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
> IPP, you will never manage to do it.
That's precisely my point. Does this group want to get bogged down
in this or not?
Keith