Randy
> -----Original Message-----
> From: Bob Van Andel [SMTP:bva@allegrosoft.com]
> Sent: Friday, April 17, 1998 7:01 AM
> To: ipp@pwg.org
> Cc: Peter.Zehler@usa.xerox.com
> Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking?
>
> All,
>
> Here is my understanding of what we are seeing in testing. (Peter,
> please
> correct me if I'm wrong).
>
> IPP is a request-response protocol that sits on top of HTTP (a
> request-response protocol) that sits on top of TCP (a connection
> protocol).
>
> TCP provides the end-to-end message integrity including packet retries
> for
> lost or mis-ordered transmissions.
>
> HTTP 1.0 uses a single TCP connection for each request-response
> transaction. In many cases, this is because the only way to signal
> the
> end-of-data is by closing the connection. (HTTP 1.0 is described in
> the
> Informational RFC 1945)
>
> HTTP 1.1 provides persistent connections (connections that stay intact
> for
> multiple request-response transactions for the same client-server).
> The
> technique for signalling end-of-data for objects whose length may not
> be
> known at the beginning of the transmission is chunked encoding. In
> HTTP
> 1.1, you may still signal end-of-data by closing the connection, but
> this
> is not recommended, since you will then lose the benefits of the
> persistent
> connection. (HTTP 1.1 is currently described in the Standards Track
> RFC
> 2068, but there will be a new RFC shortly reflecting implementation
> experience)
>
>
> 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.
>
> Yes, but all transactions do not need to use chunked encoding.
>
> >
> >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.
> >
>
> All transactions may use chunked encoding in either direction. The
> requesting client determines whether to use it for POST or PUT
> requests,
> and the responding server determines whether to use it for responses.
>
> >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.
>
> Strictly speaking, this is not a requirement, in that the client could
> close the connection to signal end-of-data.
>
> >
> >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.
>
> This is not correct. Lower layer transmission errors will be handled
> at
> the TCP layer regardless of whether chunked encoding is used.
>
> >
> >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.
> >
>
> Our current implementation of IPP transaction support requires that
> HTTP
> 1.1 support be turned on. In practice, Peter overrode this constraint
> and
> is successfully running IPP over HTTP 1.0 regardless of whether job
> size is
> known at the beginning.
>
> Bob
>
>
>
> ----------------------------------------
> Bob Van Andel
> Allegro Software Development Corporation
> 43 Waite Road
> Boxborough, MA 01719
> (978) 266-1375
> (978) 266-2839 fax
>
> Information on the RomPager embedded web server toolkit is at
> <http://www.allegrosoft.com/>
>