IPP>PRO - things that worry me

IPP>PRO - things that worry me

IPP>PRO - things that worry me

Scott Lawrence lawrence at agranat.com
Wed Apr 30 13:05:24 EDT 1997

>>>>> "RKD" == Roger K Debry <rdebry at us.ibm.com> writes:

RKD> As we close in on the definition of the protocol, there
RKD> are still some things that worry me.

RKD> 1) Will our proposed use of http handle the transport of
RKD> very very large (many Gbyte) files efficiently and with sufficient
RKD> recovery?  I know you all have tried to convince me that tcp/ip
RKD> provides everything that is necessary to guarantee delivery,
RKD> but I still am concerned that we may have left holes where
RKD> a connection remains open because of some failure, or some
RKD> component times out, the print file does not get delivered and
RKD> no one knows why or how to recover because there is no ipp
RKD> level notification of what has happened.

  I don't understand what you believe is missing.  The file would be
  sent as (part of) the body of an HTTP POST, which only acknowleged
  when the entire body has been received and understood.

  As to sufficient recovery, for files of that size you might want to
  consider the use of multipart/byterange to break up the file so that
  you can avoid resending the entire file following some failures.
  This does not require any HTTP/1.1 change that I can think of.

RKD> 2) Have we sufficiently handled the case where a print driver is
RKD> generating the print ouput and putting it on the wire a piece at
RKD> a time? Does chunking solve this problem?

  If the problem you refer to is not knowing how big the content is at
  the time you are generating the HTTP headers, then yes, chunking
  does solve that problem.

RKD> 3) Have we sufficiently handled the case where ipp is implemented
RKD> in an output device that has no capability to spool the data so must
RKD> start printing while receiving the data? What happens when a printer
RKD> failure occurs during transmission in this case?

  The printer (in its role as HTTP server) will not have sent an
  acknowlegement of the POST yet.  When the failure occurs, it can
  prematurely close the TCP connection.  The client will (correctly)
  interpret this premature close as an error in the server and will
  know that the POST has not occured (ie the file has not been

Scott Lawrence           EmWeb Embedded Server       <lawrence at agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

More information about the Ipp mailing list