IPP> RE^4: IPP over TCP

IPP> RE^4: IPP over TCP

IPP> RE^4: IPP over TCP

Hiroyuki Sato hsato at cse.canon.co.jp
Wed Dec 11 23:38:41 EST 1996

>No, Alex is entirely correct, IPP should not be concerned with the transport
>protocol other than having some requirement such as needing "a reliable
>orientated protocol" (e.g., TCP) over which it can be sent. Using TCP
>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

More information about the Ipp mailing list