Re: RE: RE: IPP> Implementation question re.: chunki

"Carl Kugler" <kugler@us.ibm.com> Mon, 27 July 1998 17:13 UTC

Delivery-Date: Mon, 27 Jul 1998 13:14:00 -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 NAA19653 for <ietf-archive@ietf.org>; Mon, 27 Jul 1998 13:13:59 -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 NAA05195 for <ietf-archive@cnri.reston.va.us>; Mon, 27 Jul 1998 13:13:44 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA19958 for <ietf-archive@cnri.reston.va.us>; Mon, 27 Jul 1998 13:13:52 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Mon, 27 Jul 1998 13:08:49 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA18781 for ipp-outgoing; Mon, 27 Jul 1998 13:00:32 -0400 (EDT)
Date: Mon, 27 Jul 1998 16:59:53 -0000
Message-ID: <19980727165953.31545.qmail@m2.findmail.com>
From: Carl Kugler <kugler@us.ibm.com>
Subject: Re: RE: RE: IPP> Implementation question re.: chunki
In-Reply-To: <002001bdb749$5dc180a0$aa66010d@copper.parc.xerox.com>
To: ipp@pwg.org
Sender: owner-ipp@pwg.org

Larry wrote:
> 
> 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.
> 

Maybe this is something we could discuss at the next telecon.  

Here is our situation.  For reasons beyond the scope of this discussion, we need to build a client-side API that supports an open,write,write...close|cancel paradigm for sending the document data.  This is easy to do with chunking.  It may be impossible to do with Content-Length (due to buffering limitations).  So our client will normally use chunking.  We'd really to avoid having to design it to fall-back to Content-Length when it encounters an HTTP/1.0 IPP server, because that would be complicated and expensive, and won't always work.  On the other hand, we don't want to paint ourselves into a corner and build a client that relies heavily on chunking, only to find out that many server implementations can't receive and decode the chunked transfer coding.

Is it safe to assume that all IPP 1.0 products will support HTTP/1.1 (and therefore chunking), even if prototype implementations don't?

    -Carl

-----
Original Message: http://www.findmail.com/list/ipp/?start=4184
Start a FREE email list at http://www.FindMail.com/