>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