RE: RE: IPP> Implementation question re.: chunking

"Larry Masinter" <masinter@parc.xerox.com> Fri, 24 July 1998 21:33 UTC

Delivery-Date: Fri, 24 Jul 1998 17:33:56 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA29220 for <ietf-archive@ietf.org>; Fri, 24 Jul 1998 17:33:54 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA19838 for <ietf-archive@cnri.reston.va.us>; Fri, 24 Jul 1998 17:33:40 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07386 for <ietf-archive@cnri.reston.va.us>; Fri, 24 Jul 1998 17:33:46 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Fri, 24 Jul 1998 17:27:32 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06839 for ipp-outgoing; Fri, 24 Jul 1998 17:24:26 -0400 (EDT)
From: Larry Masinter <masinter@parc.xerox.com>
To: Carl Kugler <kugler@us.ibm.com>, ipp@pwg.org
Subject: RE: RE: IPP> Implementation question re.: chunking
Date: Fri, 24 Jul 1998 14:23:56 -0700
Message-ID: <002001bdb749$5dc180a0$aa66010d@copper.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <19980724190239.9548.qmail@m2.findmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ipp@pwg.org

> Okay, as a practical matter it looks like we need to be able to 
> support HTTP/1.0 in addition to HTTP/1.1, and "Content-Length" in 
> addition to "Transfer-Encoding: chunked" whether sending or receiving.  
> 
> This leads me to my next question: What is the transition sequence 
> for the cases in which an HTTP/1.1 client that normally uses chunking 
> wants to make a request of a server that is HTTP/1.0 and/or doesn't 
> understand chunking?  

There is no 'installed base' of IPP clients and servers which do not
support HTTP/1.1. As a practical matter, it seems unreasonable to
posit one or to create one.