IPP> Seperating the IPP protocol from the transport mechanism.

IPP> Seperating the IPP protocol from the transport mechanism.

IPP> Seperating the IPP protocol from the transport mechanism.

Alex Bochannek abochann at cisco.com
Wed Dec 11 02:22:21 EST 1996


After being out sick for a few days I had a chance to catch up on some
of the IPP email and I have to say that I am very happy to see the
discussion moving towards MIME encapsulation.


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.



More information about the Ipp mailing list