Subject: RE: IPP> Re: IPP over TCP

From: Babak Jahromi <[email-masked]>
Date: Wed, 11 Dec 1996 14:19:12 -0800

Doesn't sticking with HTTP give us the advantage that we can use
existing technology (i.e. browser components, internet server products,
etc.) to glue in the printing solution? Going as far as implementing
something like ipp:// would make us write more lower level components
that we otherwise wouldn't need to. Every PC has or will have HTTP
client technology that we can all tap into. Why go any deeper than we
have to?

>Babak

>----------
>From: 	Alex Bochannek[SMTP:[email-masked]]
>Sent: 	Wednesday, December 11, 1996 11:44 AM
>To: 	Harry Lewis <[email-masked]>
>Cc: 	[email-masked]
>Subject: 	IPP> Re: IPP over TCP 
>
>Harry,
>
>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
>
>

---

From: Andy Newman <[email-masked]>
Date: Thu, 12 Dec 1996 10:45:32 +1100 (EST)

> client technology that we can all tap into. Why go any deeper than we

No, Alex is entirely correct, IPP should not be concerned with the transport
protocol other than having some requirement such as needing "a reliable stream
orientated protocol" (e.g., TCP) over which it can be sent. Using TCP directly
is far simpler than HTTP and HTTP is sent over a TCP connection anyway (it
doesn't have to be though, it just wants a reliable byte-stream as most appl-
ication level protocols) so you get less work not more. Removing HTTP from the
spec. also removes confusion as to how much of HTTP is required for TCP, e.g.,
which transfer encodings may be assumed by clients sending IPP via HTTP?

IPP's reliable stream connection *could* be implemented using a combination
of HTTP POST methods to a CGI program that understands IPP content contained
within the entity posted but that should be independent of the actual IPP
specification (i.e., if you really want to write it up then have another
draft or an appendix, don't clutter IPP with it). This approach would let
people use IPP without re-configuring their firewalls and send documents
over HTTP to some service that makes its IPP service available in this way
but this should be separated from the base protocol spec.

--
Andy Newman <[email-masked]>