> From lawrence at agranat.com 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.