Subject: Re: IPP>PRO - things that worry me

From: Roger K Debry <[email-masked]>
Date: Fri, 2 May 1997 13:01:07 -0400

Classification:

Scott, thanks for your response. Just a couple of things:

1) Could you provide a short scenario of how using byte ranges would work for
recovery when sending very large files for those of us who are novices in http?
That would be genuinely helpful.

2) I can see in your response to my last question see how shutting down the
connection signals some problem, but I'd like to be able to tell the client
what the problem is!

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/02/97 10:52
AM ---------------------------

        lawrence @ devnix.agranat.com
        04/30/97 11:44 AM

To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org@internet
Subject: Re: IPP>PRO - things that worry me

>>>>> "RKD" == Roger K Debry <[email-masked]> 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
  printed).

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 02 May 1997 13:09:19 -0400

>>>>> "RKD" == Roger K Debry <[email-masked]> writes:

RKD> 1) Could you provide a short scenario of how using byte ranges
RKD> would work for recovery when sending very large files for those
RKD> of us who are novices in http?  That would be genuinely helpful.

  I'd be glad to, but it will have to wait until after Interop - I
  don't want to attempt a hasty answer and don't have time for more
  than that.  (If anyone on the list will be at Interop, stop by and
  say hello at booth #4206 - it would be good to have faces to go with
  the names :-)

RKD> 2) I can see in your response to my last question see how
RKD> shutting down the connection signals some problem, but I'd like
RKD> to be able to tell the client what the problem is!

  I'm afraid there is no easy answer to this one.  There has been some
  (small) discussion of this on the http-wg list, and there just isn't
  a way to do it in the current protocol at the HTTP layer.  If IPP is
  layered _above_ HTTP, then there may well be an answer; as I
  understand the current thinking there would be a status URL
  associated with any job, so a client who say an early close on the
  file transmission could GET the status URL.