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

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 16 Apr 1998 12:31:14 PDT

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:[email-masked]]
>	Sent:	Wednesday, April 15, 1998 9:22 AM
>	To:	[email-masked]
>	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
>
>
>
>	[email-masked] on 04/14/98 05:34:03 PM
>	Please respond to [email-masked]
>	To: [email-masked]
>	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:[email-masked]]
>	 Sent: Tuesday, April 14, 1998 4:25 PM
>	 To: [email-masked]
>	 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: [email-masked]

---

From: Robert Herriot <[email-masked]>
Date: Thu, 16 Apr 1998 20:26:52 -0700

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Apr 1998 15:49:56 +0200

>1) Each HTTP 1.1 implementation is mandated to support chunking.
Right.
>the client determines whether to use chunking for a particular HTTP request.
Right, as far as it goes.
And the server determines whether to use it for the response.
>the case where the client does not know the document length when it starts
For the generation: Right.
For reception: Wrong. You're dependent on what the other guy does.
>chunk, not the whole document.

Wrong.
Since TCP is a reliable transfer protocol, there is basically only one
thing that can go wrong: You lose the connection.
There is no defined mechanism in HTTP that allows you to take advantage
of the chunks you already sent when you retry the operation over a new
connection.

>actually use HTTP 1.0, which does not support chunking, for most of your
True. With one caveat:
If you depend on HTTP/1.0 without the Content-length: field to send
data, you cannot tell the difference between the client crashing in
mid-stream and the client finishing the document - both will show up
as a "connection close".

This can be annoying-but-harmless or relatively harmful, depending on
your context.

                                   Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]