I am sure you don't mind that I copy the list on this reply.
I do not currently have a writeup other than what I outlined in my
email yesterday but I believe it would be absolutely trivial to
restructure the draft to move references to HTTP into a more generic
transport mechanism appendix.
With regards to transport over TCP, the comment I have is basically
that HTTP as a transport in my opinion does not gain you
anything. Encoding in MIME is a different issue since that would also
allow transport over email, but specifying HTTP (or more precisely,
only the HTTP POST command) does require you to track changes in the
protocol, adhere to it's limitations, and you still need to modify
browsers and servers to make use of it.
IPP simply needs clear-channel communication between client and server
and a two-way TCP connection is the easiest way to go (I also think
one should be able to run IPP over serial and parallel ports, but
that's a different story). If you want IPP to fit nicely into the Web
framework (even if it's just for PR reasons), you specify the ipp://
access method which will go to TCP port 380(?).
There really isn't much that you need to specify for the "TCP
transport module" other than port numbers and mapping to a URL method
if you want to, but one thing I personally would really like is to
specify a how long the TCP session sticks around. This way, you do not
have to continuously set up and tear down TCP sessions for every
single command you want to send to the printer (HTTP
syndrom).
Alex.
> Alex, unfortunately, I am not able to make it to the BOF, but I am very
> interested in understanding more about your IPP over TCP proposal. I
> think your recommendation for an appendix is a good one.
>
> Will you be posting your proposal, or is there another way for me to aquire
> your writeup?
>
> We will have an IBM rep at the BOF (Roger DeBry). If all else fails, I will
> ask Roger for a copy of whatever he picks up or his notes.
>
> Good luck at the BOF!
>
> Harry Lewis - IBM Printing Systems