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

From: [email-masked] (Robert Herriot)
Date: Wed, 30 Apr 1997 12:53:25 -0700

> From [email-masked] Wed Apr 30 12:05:42 1997
> 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.
> 

Your email suggests that a client can use a series of multipart/byterange's
to break up the transmission of a file.  Is that correct?  From my reading
of rfc2068, I have only seen references to a server returning a byterange, 
and none about a client sending them.

Also, even though a client may know that the transmission failed, it does not
know, even with byterange, where the failure occurred within the single POST.
So there would seem to be a need for the client to query the server about the
number of bytes in the job and to be able to concatenate bytes to the end
of that data with a POST operation.