attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0"> <TITLE>RE: IPP> Chunking Explanation</TITLE> </HEAD> <BODY> I like Bill's suggestions on Harry's original. 1. I'd like to clarify the last paragraph of the first section to make sure that its HTTP POST chunked requests that we are talking about.  (Some implementations support chunked GET responses, but not chunked POST requests). So change: It is encouraged that all IPP servers utilize HTTP1.1 servers that support chunking. to: It is encouraged that all IPP servers utilize HTTP1.1 servers that support chunking of POST requests. 2. In addition, I'd like to make the last paragraph of the second section to be an encouragement, just like the last paragraph of the first section, rather than just a MAY.  What do you think? So change: To provide compatability with such servers, IPP clients MAY support the ability to determine CONTENT_LENGTH and resubmit the job if error 411 or error 413 is encountered in response to a Chunked request. to: To provide compatability with such servers, it is encouraged that IPP clients support the ability to determine CONTENT_LENGTH and resubmit the job if error 411 or error 413 is encountered in response to a Chunked request. Ok? Tom Hastings Here is Bill's complete text: Paragraph on Problems with the Use of CGI RFC2068 requires HTTP1.1 Servers to support both Content Length and Chunking for all requests.  The use of chunking rather than determining Content Length should facilitate the transmission of large, indeterminate length print jobs. CGI, on the other hand, mandates the presence of  the CONTENT_LENGTH environment variable. Largely due to this HTTP1.1 / CGI conflict, HTTP1.1 server implementations exist that do not support Chunking for the HTTP (IPP) POST. It is encouraged that all IPP servers utilize HTTP1.1 servers that support chunking. Paragraph on IPP Client Handling of Non-Chunking Servers RFC2068 requires HTTP1.1 Servers to support both Content Length and Chunking for all requests.  However, some IPP servers may exist that do not support Chunking. In this case, the IPP server may return error 411(Length Required) in response to the HTTP POST. Further,  some IPP servers may implement a filter-and-buffer approach to determine CONTENT_LENGTH from a chunked encoding before passing the decoded request body to a CGI application.  If the buffered request grows too large, the server may reject the request with status code 413 (Request Entity Too Large). If this occurs, the IPP server may also close the connection to prevent the client from continuing the request. To provide compatability with such servers, IPP clients MAY support the ability to determine CONTENT_LENGTH and resubmit the job if error 411 or error 413 is encountered in response to a Chunked request. </BODY> </HTML>