IPP Mail Archive: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi

IPP Mail Archive: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi

RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was: Mi

Josh Cohen (joshco@microsoft.com)
Tue, 21 Apr 1998 17:44:15 -0700

the difference is that chunking doesnt really allow for
resending only certain chunks instead of the whole thing.
There is no chunk acknowledgement or chunk sequencing,
which you would need to resume an aborted or failed transfer.

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
>