In HTTP a way of resuming an aborted transfer is to use byte
ranges to request the remainder of a resource. This seems like
it would be difficult to use with IPP since you are posting data.
Chunking is just for sending content of unknown length,
not for retransmission stuff.
> -----Original Message-----
> From: Carl-Uno Manros [mailto:cmanros@cp10.es.xerox.com]
> Sent: Friday, April 17, 1998 8:12 AM
> To: Robert Herriot
> Cc: ipp@pwg.org
> Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was:
> Mi
>
>
> At 08:26 PM 4/16/98 PDT, you wrote:
> >Are you sure about #4 below? It doesn't sound right at all. My
> >understanding of chunking is that it allows the sender to omit
> >Content-Length and to instead supply length one chunk at a time. At
> >the HTTP layer, the document is a series of chunks
> terminated by a zero
> >length chunk.
> >
> >
> >Bob Herriot
> >
>
> And how is that in conflict with what I stated in 4)?
>
> Carl-Uno
>
>
> >At 12:31 PM 4/16/98 , Carl-Uno Manros wrote:
> >>Randy et al.,
> >>
> >>Here is my take on the use of chunking for IPP:
> >>
> >>1) Each HTTP 1.1 implementation is mandated to support chunking.
> >>
> >>2) All POSTs are initiated by the client, which I assume
> also means that
> >>the client determines whether to use chunking for a
> particular HTTP request.
> >>
> >>3) The only situation where chunking is absolutely
> necessary for IPP, is
> >>the case where the client does not know the document length
> when it starts
> >>sending the document.
> >>
> >>4) With the exception of the situation in 3) the client can
> always decide
> >>not to use chunking, but send even long documents in one
> request. The
> >>downside of doing that is that if something goes wrong on the lower
> >>protocol layers, the client has to start over and send the
> whole document
> >>again from the beginning. The main advantage of using
> chunking is that if
> >>you get an error on the lower layers, you only have to
> resend the latest
> >>chunk, not the whole document.
> >>
> >>5) Again, with the exception of the case in 3), you can in practise
> >>actually use HTTP 1.0, which does not support chunking, for
> most of your
> >>IPP transfers.
> >>
> >>Did I get this right?
> >>
> >>Carl-Uno
> >>
> >>At 09:08 PM 4/15/98 PDT, Turner, Randy wrote:
> >>>
> >>>There is nothing in the existing encoding that allows a
> particular IPP
> >>>message to be "fragmented" across multiple transport
> "packets". The
> >>>encoding requires that a transport protocol provide some way to
> >>>logically "connect" one message to another contiguously received
> >>>message. In HTTP, this is accomplished with HTTP 1.1 chunking. With
> >>>another transport, there would have to some equivalent
> capability. I'm
> >>>not sure if I've adequately described the situation.
> Anything further I
> >>>think would require me to draw a picture.
> >>>
> >>>Randy
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Carl Kugler [SMTP:kugler@us.ibm.com]
> >>> Sent: Wednesday, April 15, 1998 9:22 AM
> >>> To: ipp@pwg.org
> >>> Subject: IPP> IPP, independently of HTTP, Requires
> >>>Chunking ? Was: Mi
> >>>
> >>> > The concrete transport/encoding IPP protocol document is VERY
> >>>dependent
> >>> > on HTTP chunking.
> >>>
> >>> I still don't get it. Could you please explain?
> >>>
> >>> The original statement is:
> >>> > Encoding is HTTP independent except for chinking.
> >>>
> >>> This sentence, to me, implies that there is some aspect of the
> >>>IPP encoding,
> >>> apart from HTTP, that depends on chunking. This is suprising
> >>>news to me.
> >>>
> >>> The only chunking-related requirements I've found in the
> >>>Protocol document are:
> >>> 1) the Server must support "chunked" Transfer-Encoding of
> >>>Requests
> >>> 2) the Client must support "chunked" Responses.
> >>> These requirements derive directly from RFC 2068: "All HTTP/1.1
> >>>applications
> >>> MUST be able to receive and decode the "chunked" transfer
> >>>coding..."
> >>>
> >>>
> >>> Confused in Boulder,
> >>>
> >>> Carl-III
> >>>
> >>>
> >>>
> >>> ipp-owner@pwg.org on 04/14/98 05:34:03 PM
> >>> Please respond to ipp-owner@pwg.org
> >>> To: ipp@pwg.org
> >>> cc:
> >>> Subject: RE: IPP> Minutes from PWG IPP Meeting in Portland, OR -
> >>>Apri
> >>>
> >>>
> >>>
> >>> The abstract IPP described in the model document is not
> >>>dependent on
> >>> HTTP chunking.
> >>>
> >>> The concrete transport/encoding IPP protocol document is VERY
> >>>dependent
> >>> on HTTP chunking.
> >>>
> >>> Randy
> >>>
> >>> -----Original Message-----
> >>> From: Carl Kugler [SMTP:kugler@us.ibm.com]
> >>> Sent: Tuesday, April 14, 1998 4:25 PM
> >>> To: ipp@pwg.org
> >>> Subject: Re: IPP> Minutes from PWG IPP Meeting in
> >>> Portland, OR - Apri
> >>>
> >>> > IPP is not transport neutral. Encoding is HTTP independent
> >>> except for
> >>> > chinking.
> >>>
> >>> I assume you mean "chunking". In what way is IPP dependent on
> >>> HTTP chunking?
> >>>
> >>> -Carl
> >>>
> >>>
> >>>
> >>>
> >>>
> >>Carl-Uno Manros
> >>Principal Engineer - Advanced Printing Standards - Xerox Corporation
> >>701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> >>Phone +1-310-333 8273, Fax +1-310-333 5514
> >>Email: manros@cp10.es.xerox.com
> >>
> >
> >
> >
> Carl-Uno Manros
> Principal Engineer - Advanced Printing Standards - Xerox Corporation
> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> Phone +1-310-333 8273, Fax +1-310-333 5514
> Email: manros@cp10.es.xerox.com
>