Subject: IPP> RE^4: IPP over TCP

From: Hiroyuki Sato <[email-masked]>
Date: Thu, 12 Dec 1996 13:38:41 +0900

>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. 

Internet Printing requires client sides bundle a print command with some 
attributes, e.g. copy count, finishing, etc. and issue the data package,
also requires server sides receive/analyze the data and respond it.

TCP offers only bi-directional bit stream. So we need a protocol on TCP 
to handle the sequence anyway. Salutation picks ONC/RPC as this 
mechanism, defining calls, Open, Close and DataTransfer. DataTransfer 
carries BER-encoded print commands, attributes and print data.

As the protocol, HTTP is the best choice at this moment because of its 
implementation easiness, IMHO.

>
>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.

If there are many choices, it confuses end users and manufacturers.
Ya, we need only a one protocol spec.

There are maybe some overheads following the separation like ISO-7-layer-based 
G4 protocol, although separation sounds nice theoretically.

Today's BOF sounds exciting. I miss the one.

Hiroyuki Sato
Canon

---

From: Alex Bochannek <[email-masked]>
Date: Wed, 11 Dec 96 22:17:17 PST

> carries BER-encoded print commands, attributes and print data.

I agree. This protocol you describe is called IPP.

> Ya, we need only a one protocol spec.

That is arguable and hopefully can be discussed tomorrow.

> Today's BOF sounds exciting. I miss the one.

Too bad that you'll miss it, but I am sure someone will post notes.

Alex.