> My major goal is that all setup, configuration, status query, etc. can be
> done from a browser with the assistance of plug-ins, CGI code, HTTP
> re-directors, etc. When time comes to print from my application, the
> browser is completely out of the picture (unless of course the browser
> is the application.)
Fair enough. I still don't see why this mandates HTTP. For example,
web browsers are probably the single most used FTP client these days.
> As I said before, creating a new TCP stream starting with a blank
> sheet of paper will take a standards group 2 years to finish. If the
> group is constrained to use what already exists with perhaps minor
> additions, the task stands a good chance of getting done much, much
> sooner. From my experience, never, never, never give a standards
> body a blank sheet of paper. It will be filled with doodles, not a standard
> for years.
Also fair, but you overlook one important aspect: You already have
designed a brand new protocol on a clean sheet of paper! It's called
IPP. All we are arguing about is that you think it should be
transported in another application protocol while I say you should use
a transport protocol with more than 15 years of use behind it. Not
only your favorite, HTTP, uses it, but also a whole range of
others. Look at RFC821, dated August 1982. It describes the mapping of
SMTP onto the TCP transport in about one dozen lines of text. And it
is still working today.
--
Alex Bochannek Phone & Fax : +1 408 526 51 91
Senior Network Analyst Pager : +1 408 485 90 92
Engineering Services Alpha Pager : (800) 225-0256 PIN 104536
Cisco Systems, Inc. Email : abochannek at cisco.com
170 West Tasman Drive, Bldg. E Pager Email : abochannek at beeper.cisco.com
San Jose, CA 95134-1706, USA