Based on my homework assignment from yesterday's call, I have uploaded a file
to the ftp site which provides thoughts on why we want to use http as the
underlying protocol for IPP. I also discussed this with John Dawes at Netscape
(see my previous note) who completely agrees.
I also included in this file a short discussion of my understanding of how CGI
works, and some forms example flows with comments on what I think is good or
bad. I also looked at the multipart MIME standard, considered Bob Herriot's
proposal to use standard MIME types for the document, and other related things.
I would really appreciate everyone who engaged in yeserday's debate to study
the charts in this file and comment. I spent most of the day re-reading all of
the related RFCs to understand them as well as I could. However, I don't claim
to have perfect kowledge so comments from others who have also taken the time
to study the documentation in detail are welcome.
My net is that we can do everything that we want to do without impacting
current servers. However, I am still convinced, after my study today, that we
do not want to use html and forms as the mechanism to generate IPP requests on
the client side. I believe that this is fraught with problems and will
constrain future extendabilty of the standard -- or at best require awkward and
difficult to understand and parse constructs to provide all of the function we
might want in IPP over time.
The use of CGI programs or applications written to web server api's can easily
deal with what I have called an imbedded IPP protocol. This will allow us to
extend in a nicely structured, clean way. I prefer this approach.
I have only uploaded a postscript file. The charts contain graphics so a text
file won't be very meaningful, and I don't have a distiller to generate a PDF
file. Perhaps some kind sole will generate the PDF file for me.
I look forward to lots of healthy, constructive debate on this subject. See you
all in San Jose.
Roger deBry