There were four main problems:
a) no notification
b) if a connection fails, there is no way to know if it because the printer
is down or just busy.
c) if a write times out, there is no way to know if it because the
printer is down or just busy.
d) if a write operation succeeds, there is no way to be 100% sure that
the bytes made it to their final destination The success of a write only
means that the TCP/IP layer succeeded.
The solutions:
a) notification: the IPP group is close to a solution
b) the primary issue is being able to determine the printer status, i.e.
did the connection fail because the printer is down or just busy. One
simple solution is to have a printer read on a UDP port dedicated to
returning a status summary whenever it receives a request on the port. If
the incoming bytes are limited and have simple options, the printer will
never be tied up for long on each transaction and will always be able to let
a client know if it is alive and whether there are any problems. Then if the
connection fails, it is because the printer is down or the IP address is bad.
c) this is essentially the same problem as b) and has the same solution. Namely,
if a write times out, the client can query status and determine the problem.
d) I think that we should rely on TCP/IP to get the bytes to their
destination. The most likely failure between client and paper is the
network. Loss of data inside the printer seems like such a remote problem
that it isn't worth making the protocol more complicated to solve this problem.
I hope that we can discuss these ideas via the DL and next week in DC.
The solution that I suggest with b) is a new IPP operation over a different route from
other IPP operations, so the syntax for request and reponse could be similar or different.
This solution allow IPP for other operations to remain unchanged.
Bob Herriot