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:
>>
>>There is nothing in the existing encoding that allows a particular IPP
>>message to be "fragmented" across multiple transport "packets".=A0 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:kugler@us.ibm.com]
>> Sent: Wednesday, April 15, 1998 9:22 AM
>> To: ipp@pwg.org
>> 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.=A0 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.=A0 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:=A0 "All HTTP/1.1
>>applications
>> MUST be able to receive and decode the "chunked" transfer
>>coding..."
>>
>>
>> Confused in Boulder,
>>
>> =A0 Carl-III
>>
>>
>>
>> ipp-owner@pwg.org on 04/14/98 05:34:03 PM
>> Please respond to ipp-owner@pwg.org
>> To: ipp@pwg.org
>> 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:kugler@us.ibm.com]
>> Sent: Tuesday, April 14, 1998 4:25 PM
>> To: ipp@pwg.org
>> 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".=A0 In what way is IPP dependent on
>> HTTP chunking?
>>
>> =A0 -Carl
>>
>>
>>=20
>>
>>
>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: manros@cp10.es.xerox.com
>=20