Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking?

From: Bob Van Andel <[email-masked]>
Date: Fri, 17 Apr 1998 10:01:02 -0400

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/>

---

From: "Zehler, Peter " <[email-masked]>
Date: Fri, 17 Apr 1998 07:45:31 PDT

All,
Regarding IPP testing experience with chunking/IPP.  I have not yet seen
anyone that has tried this.  The tests I have been involved in, up to very
recently, used HTTP 1.0.  This was due to the limitations of JDK.  I have
not yet pursued the added complexity of chunking.  This is a function of
IPP's underlying transport(HTTP 1.1).  I have been concentrating on the IPP
PAD and method invocation.  I would love to hear anyone with some concrete
experience with IPP and chunking.
The interoperability test plans calls for a print submission with and
without the client chunking its request.  I had not thought of the server
chunking its reply.  Should this be added to the "top 25" IPP tests?
I do not see where IPP requires chunking.  I believe it currently is a
requirement of IPP's protocol mapping to handle the situation where the size
of the request/response is not known until the end.  HTTP solved this by
chunking data.  If IPP were mapped to another protocol we would depend on
the new protocol's method to handle this problem or pull the solution for
the problem up into the IPP layer.
Pete
Peter Zehler
XEROX
Networked Products Business Unit
Email: [email-masked]
Voice:    (716) 265-8755
FAX:      (716) 265-8792 
US Mail: Peter Zehler
	        Xerox Corp.
	        800 Phillips Rd.
	        M/S 111-02J
	        Webster NY, 14580-9701

	-----Original Message-----
	From:	Bob Van Andel [SMTP:[email-masked]]
	Sent:	Friday, April 17, 1998 10:01 AM
	To:	[email-masked]
	Cc:	[email-masked]
	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)

	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.

	>the case where the client does not know the document length when it
starts

	Strictly speaking, this is not a requirement, in that the client
could
	close the connection to signal end-of-data.

	>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.

	>actually use HTTP 1.0, which does not support chunking, for most of
your

	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

---

From: Carl Kugler <[email-masked]>
Date: Tue, 21 Apr 1998 12:07:18 -0400

Agreed.  I was confused about that.  100 Continue and Transfer-Encoding:
chunked are independent except that they're both new features of HTTP 1.1.

  -Carl

[email-masked] on 04/21/98 09:21:02 AM
Please respond to [email-masked]
To: [email-masked]
cc:
Subject: Re: IPP> IPP, independently of HTTP, Requires Chunking?

>>>>> "CK" == Carl Kugler <[email-masked]> writes:

CK> it always sends a 100 Continue before that actual response, and I
CK> think that implies chunking

  No, the only indication of chunking is the 'Transfer-Encoding:
  chunked' header field.

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/