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

From: Carl Kugler <[email-masked]>
Date: Wed, 15 Apr 1998 12:21:59 -0400

> 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

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 15 Apr 1998 21:08:13 -0700

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

	> 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

	except for

	  -Carl

---

From: "Caruso, Angelo " <[email-masked]>
Date: Fri, 17 Apr 1998 06:23:10 PDT

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:[email-masked]]
	Sent:	Thursday, April 16, 1998 11:27 PM
	To:	Carl-Uno Manros; Turner, Randy; [email-masked]'
	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 
	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

	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:
	>>
	>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: "Turner, Randy" <[email-masked]>
Date: Mon, 20 Apr 1998 07:35:17 -0700

One minor comment below....

Randy

	-----Original Message-----
	From:	Harald Tveit Alvestrand
[SMTP:[email-masked]]
	Sent:	Monday, April 20, 1998 6:50 AM
	To:	Carl-Uno Manros; Turner, Randy; [email-masked]'
	Subject:	RE: IPP> IPP, independently of HTTP, Requires
Chunking ? Was: Mi

	>1) Each HTTP 1.1 implementation is mandated to support
chunking.
	Right.
	>
	>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.
	Right, as far as it goes.
	And the server determines whether to use it for the response.
	>
	>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.
	For the generation: Right.
	For reception: Wrong. You're dependent on what the other guy
does.
	>
	>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
	>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.

	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
	>IPP transfers.
	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".

<RT> This is not true in all cases. I seem to remember that some socket
and TLI API implementations allow you to detect the difference between a
remote endsystem crashing and a normal connection "close". This should
be especially possible if the client had data in transit at the time the
remote endsystem crashed.

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

	                                   Harald A

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 21 Apr 1998 10:14:04 +0200

>remote endsystem crashed.

Actually this depends on the endsystem implementation.
There are 2 kinds of packets that can come across the wire:

- A packet with the RST bit set. This indicates a crash.
- A packet with the FIN bit set. This indicates normal close.

But some endsystems will send FIN when the socket is closed, no matter
why it is closed; this you cannot detect.

Test with an UNIX box: Put a TCPDUMP on your LAN, telnet to some remote
host, and kill the telnet client in various ways (kill -HUP, kill -9,
EOF from client....), and see if the trace shows an R or an F in the
last packet sent. If it's an F, the close is "normal".

                            Harald A

---

From: Josh Cohen <[email-masked]>
Date: 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.

> From: Carl-Uno Manros [mailto:[email-masked]]
> Sent: Friday, April 17, 1998 8:12 AM
> To: Robert Herriot
> Cc: [email-masked]
> Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking ? Was:
> Mi
> 
> 
> At 08:26 PM 4/16/98 PDT, you wrote:
> >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
> 
> 
> >>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
> >>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
> >>Principal Engineer - Advanced Printing Standards - Xerox Corporation
> Principal Engineer - Advanced Printing Standards - Xerox Corporation