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

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

Caruso, Angelo Angelo.Caruso at usa.xerox.com
Fri Apr 17 09:23:10 EDT 1998


My understanding is that chunking offers a major performance =
enhancement.
With chunking, the driver can send the PDL stream directly to the =
device, in
chunks, as it is being generated. Without chunking, the driver needs to
buffer the entire PDL stream on the local HD because it must determine =
the
total size before sending.


Thanks,
Angelo


	-----Original Message-----
	From:	Robert Herriot [SMTP:robert.herriot at Eng.Sun.COM]
	Sent:	Thursday, April 16, 1998 11:27 PM
	To:	Carl-Uno Manros; Turner, Randy; 'ipp at pwg.org'
	Subject:	RE: IPP> IPP, independently of HTTP, Requires
Chunking ? Was: Mi


	Are you sure about #4 below? It doesn't sound right at all.  My=20
	understanding of chunking is that it allows the sender to omit=20
	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=20
	length chunk.




	Bob Herriot


	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".=A0
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 at us.ibm.com]
	>> Sent: Wednesday, April 15, 1998 9:22 AM
	>> To: ipp at 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.=A0 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.=A0 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:=A0 "All HTTP/1.1
	>>applications
	>> MUST be able to receive and decode the "chunked" transfer
	>>coding..."
	>>
	>>
	>> Confused in Boulder,
	>>
	>> =A0 Carl-III
	>>
	>>
	>>
	>> ipp-owner at pwg.org on 04/14/98 05:34:03 PM
	>> Please respond to ipp-owner at pwg.org
	>> To: ipp at 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 at us.ibm.com]
	>> Sent: Tuesday, April 14, 1998 4:25 PM
	>> To: ipp at 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".=A0 In what way is IPP dependent on
	>> HTTP chunking?
	>>
	>> =A0 -Carl
	>>
	>>
	>>=20
	>>
	>>
	>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 at cp10.es.xerox.com
	>=20



More information about the Ipp mailing list