What I would like to see and what I will propose at the Thursday BOF
is to seperate the IPP protocol form the underlying transport. The
reasons are manyfold, but protocol independence is certainly a good
design criterium.
Basically, IPP should be concerned about defining client server
interaction and how to get the data segments (i.e., the actual printed
text) to the printer. The encoding of the protocol sould not affect
the protocol and vice versa. So, I am proposing a seperate document or
an appendix that spells out two possible encodings:
- MIME
- TCP Stream
The first one has been discussed and I like the multipart proposal,
although it doesn't really matter unless you expect to perform some
sort of action on the parts outside of the IPP framework (e.g.,
gatways). I REALLY would like this to be GENERIC MIME since this way
it could be specified to work over HTTP, mail, and news.
The second one is my favorite, simple because it is plain, simple,
elegant, and easy to manage. Not having written software for printers
before, I would imagine that given the choice between TCP+HTTP and
just plain TCP you would opt for the lower overhead of just TCP.
Anyway, this is what I would like to propose and can discuss this
more on Thursday.
Alex.